Saving Memory with C# Structs

In C++, there’s little difference between class and struct: a class defaults to “private” access and a struct defaults to “public” access. There are no other technical differences between the two, though structs are often used for small and simple data types.

C# mimics the syntax of C++ to some degree and also provides class and struct. However, in this case, the technical difference is quite large! In this post, I’ll briefly explain that difference and highlight a scenario where using a struct saved a lot of memory on a project I worked on.

[Read More]

G-Engine #4: Basic 3D Rendering

In the last G-Engine post, we got the game loop and frame “delta time” calculations working. We’ve now got a blank, empty game window - yay? Despite the unimpressive result, we’ve got a beating heart under the hood: an update loop being called at roughly 60 frames per second.

Empty windows are no fun, so my next goal is to get something - anything - rendering in the game window. Graphics are a vital and exciting part of any game, and rendering can give us vital visual feedback as we move on to implementing and debugging 3D object placement, cameras, rotations, and data loading for 3D meshes and animations.

This post will focus on rendering a single triangle on screen. Though the result is simple, we’ll cover a lot of ground towards building a 3D rendering system that will be extended and enhanced as we move forward.

[Read More]

G-Engine #3: Game Loop

In my last G-Engine post, I did some setup work and finally got a basic OS window appearing that could be moved around, minimized/maximized, and closed. Good start!

In this post, we’ll do a bit more planning, and then we’ll structure our code into a high-level class (GEngine) that’ll be more conducive to building an engine than just shoving everything into the main function. We’ll also implement our “delta time” calculations, which will be critical for updating the state of our game as we move forward.

[Read More]

G-Engine #2: Project Setup

The previous post introduced the G-Engine project. So here we are, ready to build a 3D game engine! This post walks through some early decisions, starting from absolutely nothing to having just an empty application window that can be moved around and closed.

This is not the most exciting end result, but there are plenty of important decisions to be made before we dig into actually writing game engine code.

[Read More]
G-Engine  SDL  C++ 

G-Engine #1: Introduction

I’ve always wanted to write a game engine. But building a game engine without a game can be difficult to do! The needs of the game drive the engine’s features. Plus, without art assets, how do you show off the engine’s features?

To get around this problem, I thought it’d be cool to build a game engine that’s capable of running a game that I played when I was in my teens: Gabriel Knight 3: Blood of the Sacred, Blood of the Damned. In late 2017, I took the dive and started working on it!

This post (and those following it) document my progress. In this introductory post, I’ll explain what Gabriel Knight is, why I’m excited about it, and what I hope to accomplish.

[Read More]

Insert, Push, and Emplace

Standard C++ containers (or collections) are essential tools. Some, like vector, queue, deque, and stack are list-like: elements are accessed by position. Others, such as map or set, are more associative in nature: elements are accessed by a key.

To add an object to a vector, you can call insert or push_back. Stacks and queues both allow you to add elements using push. Map allows insertions with insert or using the [ ] operator.

In C++11 and beyond, all these containers have new functions that seem to behave similarly to the above methods: emplace, emplace_back, and emplace_front.

Which begs the question: what’s the difference between these different methods of adding items to collections?

[Read More]
C++ 

When to Inherit from MonoBehaviour

When you create a new C# class in Unity, it automatically inherits from the MonoBehaviour class, which is Unity’s base class for components. In Unity, you tend to create a lot of components, but it’s important to keep in mind that you don’t have to.

When I was new to Unity, I thought everything should inherit from MonoBehaviour - that’s just how you work in Unity! Some of my students have also had this misconception. In fact, there are often scenarios where it makes more sense to not inherit at all, or to inherit from another base class. This post explains situations where it makes sense to use MonoBehaviour, and some cases where you’d be better off without it.

[Read More]

Encapsulate Unity Inspector Variables

When writing a Unity component, it’s likely that you’ll want to expose some variables in the Unity Editor’s Inspector, so that either you or a designer can modify those values without having to recompile the script. However, the default method of exposing variables in the inspector can break class encapsulation in an undesirable way. This post explores ways to expose variables in the Inspector without sacrificing your class’s encapsulation.

[Read More]