You can find the source code on GitHub here.

About this game

This is a demo game I made for my graduation project to learn about engine programming. The game was only meant to display what is usually involved in making a video game without the use of commercial game engines and minimal use of third party libraries, so I ended up implementing things that most games had and decided to focus on demonstrating the various components of the engine. Because there is so much involved in making a game “from scratch”; the takeaway from this project was the various things I will learn along the way.

Tools and libraries

Due to time constraint, I only targeted x64 Windows machines, using OpenGL as rendering API, MSVC C/C++ compiler, and the following libraries:

  1. stb_image.h to load images into memory.
  2. miniaudio.h for simple audio loop.

Neither C Standard Library nor Standard Template Library were used for this project.

Content

Data

Packing was not required for this game, so looking at the data folder should give us an insight into what the game has to load at startup:

3d_demo_game/
|
+--- data/
|    |
|    +--- level_data/
|    |    +--- main.level
|    |
|    +--- mesh_data/
|    |    +--- ghost.mesh
|    |    +--- ghost.meshbv
|    |    +--- skull.mesh
|    |    +--- skull.meshbv
|    |    +--- ...
|    |
|    +--- sounds/
|    |    +--- satie.mp3
|    |
|    +--- texture_data/
|    |    +--- cube_maps/
|    |    +--- heightmap.jpg
|    |    +--- moon.jpg
|    |    +--- ...
|    |
+--- debug_build/
+--- release_build/

Level data

This folder stores the the game’s levels; only one was made for the demo. The .level format is a text format I created to specify things like: what sound file to play during this level? What cube map to use as skybox for this level? How many entities are in this level and what’s their position, orientation, mesh, flags, etc…
Since I avoided the use of standard libraries, I had to write a simple text parser to read the data from disk (deserialization), and a “string builder” to write the data to disk (serialization).

Mesh data

This folder contains all the meshes and their corresponding bounding volumes, which are also meshes that are used for collision detection. The .mesh and .meshbv formats are custom; this time binary files. For this, I had to write a Blender mesh exporter (in python) that talks with the Blender API to retrieve object data and then write that data to disk as a .mesh file. As extension, you can ask the exporter to generate a convex hull for the object model you are exporting, but since the bounding volume data is represented differently in the engine, I wrote a separate exporter for it that writes to disk as a .meshbv file.

Sounds

Audio files are loaded using miniaudio.h and played in a loop. The file to load is specified in the .level format.

Texture data

In this folder we simply store images. These images are loaded into memory using stb_image.h and uploaded to the GPU via OpenGL as textures; we store these textures in a global hash table. Cube maps are usually loaded in together and treated as one texture, so we store them in a separate folder.

Level editor

In order to make levels, it would be hard for us to adjust and edit things manually each time from the .level file; a level editor is therefore required. The editor tools include:

  • Debug camera to freely roam the world.
  • Transformation gizmo system that allows us to move and rotate entities.
  • Ability to focus on objects.
  • Copy objects.
  • Delete objects.
  • Undo-redo actions.

Debugging

Debug view of the box area that mobs are allowed to move in

Debug view of the box area that mobs are allowed to move in

It’s common in games to use visuals for debugging and it’s very helpful to be able to freely and easily draw basic geometry for that purpose. A simple immediate mode renderer is a great way to achieve that; implemented by having a global vertex buffer that we push geometry into, and when we’re ready to draw, we call a function that draws everything in that buffer in one go.

Printing values to console or on screen is also very crucial for debugging. I didn’t implement text rendering and sticked with the console, but since we don’t use the standard library; I had to implement custom string formatting and use Win32 API to print stuff to the console. String formatting is also used for the aforementioned string builder to serialize level data.

Terrain

Terrains are generated by creating a grid of reasonable size and then determining the height of each vertex in that grid by a heightmap, which is essentially an image where each pixel stores a “height” value.

Collision detection

There are three types of collision volumes in the engine, all of which are loaded from .meshbv files:

  • Convex Hull.
  • Bounding Box (treated as Convex Hull).
  • Bounding Sphere.

A different type of bounding box is computed for every entity at mesh load time. That bounding box is not used for collisions, but is nonetheless helpful and used for many things including ray-box intersection test for selecting entities in the level editor.

To detect and resolve collisions between two entities, we need to firstly ask what type of collision volume each entity uses. For each combination, we have a separate routine. Without going into detail, here are the combinations:

  • Sphere vs. sphere: This is the simplest one to detect and resolve. All we need to do is find out whether the distance between the first sphere’s center and the second sphere’s center is more or less than the sum of their radii. If the distance is less; they collide.

  • Sphere vs. convex hull: This is similar to sphere vs. sphere, but we need to find the closest point on the convex hull to the sphere’s center, take the distance between that point and the sphere’s center, and check whether it’s less than the sphere’s radius.

  • convex hull vs. convex hull: for this we use the Separating Axis Theorem (SAT) test. Our bounding boxes also take this route.

  • Entity vs. terrain: we deal with terrain collision specially because the terrain consists of many polygons, which makes ordinary collision tests infeasible to compute. Since we already know the height of each vertex in our terrain and we know the height of the entity we are testing; we can compare the two heights to determine whether a collision ocurred or not.