C++

One of the reasons I learned how to program was to make games. Games are a unique form of creative medium, combining art, interactive storytelling, and vibrant worlds. But as a software engineer, it’s easy to lose sight of my goals and get trapped by the technical details. It’s common for software engineers in game dev to roll their own engine, which I believe reduces productivity and is ultimately a distraction to making a game.

Note that I’m not just referring to making reusable or generic game engines; for this article, I consider using low-level technology like OpenGL, SFML, or SDL to make games to include the act of rolling your own game engine, even if the focus is specific. It’s more manageable, but you still end up reinventing the wheel and having to solve many of the same problems.

There are plenty of other articles about whether or not to make your own game engine. This article is personal to me; it’s an exploration of my journey in game dev, a discussion of what motivates me, and a promise for the future.

When implementing controller support in a game, it’s desirable for gamepads to just work without a lot of user configuration. Platform APIs are pretty useless for this, the solution is an API like SDL_GameController that allows you to target a large number of gamepads without much effort.

Each operating system has its own API for gamepad input. Windows has XInput, and Linux has the joystick and evdev APIs. When a gamepad button is pressed, applications will receive a button id. This is a number, there’s no OS way to know which button id corresponds with which button. The ids for a button are not the same on different gamepads and platforms, making it super hard to support more than a couple of devices.

if (SDL_JoystickGetButton(joystick, 8)) {
    std::cerr << "no idea what button 8 is" << std::endl;
}

One thing platforms do give you is the name, model, and manufacturer of the game controller. If you test with a large number of gamepads, you can create a database from gamepad name to layout. Luckily, SDL_GameController has already done this for you. Instead of a random number, you can use a named button that will work no matter the gamepad and platform:

if (SDL_GameControllerGetButton(controller, SDL_GameControllerButton::SDL_CONTROLLER_BUTTON_X)) {
    std::cerr << "X was pressed!" << std::endl;
}

I have a lot of houseplants, but I often forget to water them. I’ve been getting into electronics and thought this would be a great opportunity to make something.

I made a plant monitor, which measures soil moisture, temperature, and humidity, and reports these things to a cloud IoT service called Thinger.io.

Sandboxing can protect the user’s computer from malicious or buggy scripts. But sandboxes are difficult to get right; you need to be very careful with what you expose, and make sure you test for vulnerabilities. The Sandboxes on the Lua wiki is required reading, as it contains very helpful advice.

Many APIs in my game push Vector3s to and from Lua. It’s such a common operation, that most of my functions used to look like this:

sol::table add(sol::table tPos) {
    Vector3f pos = TableToPos(tPos);

    // do something
    return PosToTable(pos);
}

One of the benefits of sol is that it is able to bind Lua arguments to C++ function arguments, converting types implicitly. Having to convert from a table to a vector ourselves is quite annoying. It would be much nicer to have sol do it for us. Luckily, sol allows you to customise how types are retrieved and pushed to Lua using Customisation Points.

When trying to convert a type from Lua to C++, sol will call certain templated functions. We will be customisating sol’s behaviour using a technique called template specialization, which allows us to specialise a specific instance of the templated functions and structs. By the end of this article, we’ll be able to use Vector3 directly when using sol, allowing the above code to be turned into this:

Vector3f add(Vector3f pos) {
    // do something

    return pos;
}

Drop shadows are created using a Gaussian blur drawn underneath the original element. You can do this using either a fixed texture or a post-processing fragment shader.

SFML is an excellent library that can be used to create 2D games and similar applications in C++. It’s an abstraction over OpenGL and various system APIs, presenting a consistent and easy-to-use interface.

Providing a Graphical User Interface (GUI / UI) API is out of scope for SFML. GUIs are complicated, and there’s no single good way to implement them. The S in SFML stands for Simple but GUI code rarely is.

There are many different options to choose from when making GUIs. This article is an in-depth comparison of the options for making GUIs in SFML, discussing their pros and cons.

Ruben’s Virtual World Project is a game I’ve been working on for almost 4 years now. Recently I rewrote the rendering code to support voxel lighting and multiple z-level - heights of the map.

Google’s C++ testing library has a nice syntax for registering tests, without needing to remember to add the tests to some central index. This article will show how to use macros to allow the creation of tests using only the following code:

Test(IntegerComparisonTest) {
    int a = 3;
    assert(a == 3);
}

Recently I had to reinstall Windows to debug a hardware issue. I decided to try to make the most of this by trying to build my game on Windows.

I wrote a raytracer and a rasteriser as part of my university course. The raytracer supported features such as indirect lighting, reflection, refraction, and a photon mapper capable of simulating the final positions of 60,000,000 photons in a few minutes (and quite a few GBs of RAM).

After cross-compiling your project for Windows, you find that it crashes due to missing DLLs. I will show how to identify any required DLLs using objdump, and copy them to your build directory.

During the second year of university, I created a kernel for the ARMv7 instruction set. I went above and beyond what was required on this project, achieving a clean design and features such as a blocked process queue, piping, kill, and a simple filesystem. This was my favourite coursework so far. I found it very interesting to learn about and implement the things that we take for granted as programmers.

I tried to stick to POSIX as much as possible, and stuck to the Linux method of having everything as either a file or process. Because pipes and standard in/out were both “files”, I was able to implement both popen and piping of the output of a process to another process.

For the last two years, I have been working on a very ambitious game. The game is a top-down sandbox with multiplayer support. I’m aiming towards a city-based game, where players can wander around a procedurally generated city. One of the main reasons I started creating this game is to learn about multiplayer networking at a low level - client-side prediction, server-side reconcilliation, cheat preventation, and reducing the visual effect of latency.

I had an issue where CMake was failing on a compiler test with the following error:

error: unrecognized option '-rdynamic'

The problem was that CMake caches settings such as compiler flags in CMakeCache.txt, so you need to clear the cache when changing the platform. Do this by deleting CMakeFiles and CMakeCache.txt

I created a very short C++ snippet to accumulate a series of Mats into a single Mat strip. It works like acc = acc + m - a new mat is added to the accumulator each time, then stored in the accumulator again.

Usecase: shells dropping in sync with firing, fake bullets, etc

You must use a particle emitter to create particles, however this doesn’t mean it’s impossible to create single particles on command. You can create a particle emitter which simply adds particles from a queue to the system

Simply get the SFGUI window size using GetAllocation, the sfml window size using getSize, then do this arithmetic:

auto window = sfg::Window::Create();
auto win_rect = window->GetAllocation();
sf::Vector2f size(win_rect.width, win_rect.height);
window->SetPosition(((sf::Vector2f)rwindow->getSize() - size) / 2.0f);

To get more than 50% on our coursework, you had to submit extensions. Here are some of my favourite ones.

Recently I have been looking at languages and compilation: VMs, parse trees, lexers, and interpreters. Nand to tetris is a pretty awesome guide to how the CPU executes programs - from logic gates to high level languages.