Part 5 of Learning how to build a game in C++

This game is handwritten but a line must be drawn at some point: I don’t plan to write the graphics driver in assembly on a computer I built from scratch using electronic components I designed from first principles and put together from raw materials that I refined myself. Instead I will choose certain pre-fabricated parts for the task - computer being one of them.

Aside from the obvious, I will make use of C or C++ libraries that provide functionality that I am not interested in writing myself. The most important criteria that I’m using to choose libraries is that they’re lightweight and single purpose: I don’t want the opinion of a framework to influence how I build this thing.

These choices are based off initial research but may change as the project develops:

Graphics

I want the game to be platform agnostic. It would make sense then, to use OpenGL as the graphics layer. Taking this a step further the game logic should be decoupled from the graphics layer to allow the latter to be switched out, but OpenGL is the immediate target.

GLFW is the lightest weight and least opinionated OpenGL library for C/C++ that I’ve come across and I like writing code with it so I’m just choosing that directly rather than evaluating others.

In addition to GLFW, I’ll be making use of GLEW to perform the tasks around extensions. I don’t know a lot about this aspect of modern OpenGL other than the fact that it’s required for handling shaders.

In previous forays into building C++ games I’ve rolled my own 2d coordinate classes. I imagine there are thousands of stray vec2 and vec3 implementations floating around in the wild. This time I’m electing to use a pre-existing solution - the GL Mathematics library (glm).

While I want to write at a low level for some of the project, reading textures into memory isn’t one of the low level operations I’m really interested in. For this I will use the Simple OpenGL Image Library (SOIL). This library hasn’t been updated for a couple of years, but the image formats I’m planning on using haven’t either. This depends on another library - libpng - being present so I’m including that as a dependency too.

When I implemented clones of Snake and Tetris a couple of years ago I used a bitmap font that Lana created for me. This approach was taken because I didn’t want to do load complex external assets like true type fonts at the time. Times change and the text drawing will be provided by the Freetype2 and FreetypeGL libraries.

Sound

Having never tried to build anything that makes noises I am at a bit of a loss for this one. As far as I can tell playing back audio involves two steps - decoding the sound file format and then actually playing it. I will use the open source libraries libsndfile for the former and PortAudio for the latter.

Utility

My initial thoughts on how to configure the game are to use json, though this may change - I’m quite impressed by yaml’s syntax having been playing with Ansible lately. Anyway, it’s json for now as the problem I’m imagining solving lends itself to the object/key/value model and the library I’ve selected for this purpose is jsoncpp.

Testing

The most widely used and updated testing library I’ve seen for C++ is Google Test. It has an accompanying mocking library - Google Mock which I’ll include on the off chance I need mocks. It’s easier to include at the start and remove if I don’t need it later.

A further library I’ve used on top of these in the past is Bandit which provides a more expressive way of writing tests by making use of lambdas. The unit tests will be written using Bandit.

To recap, the winners are:

Graphics (OpenGL)

Sound

Utility

Testing

Other posts in this series