Unit Testing

This week I decided to take a quick break from the series on building the core Qi library in order to talk about an important part of any code project, testing! Even though this might not be a very interesting part of the project, it's important to get into place earlier rather than later. If you have an easy-to-use unit test system and already have it in place and ready to go, it's fairly painless to add new tests as you add new features to the engine. If you wait until later, it's becomes an impossible task of writing tons of tests to exercise features that you haven't worked on for months.

You could always write your own test system but this is very solved problem with many good options out there. Previously I've made pretty extensive use of UnitTest++ which has a very simple-to-use interface and works pretty well. However, with Qi I've decided to change it up and make use of Google's gtest. This is a pretty lightweight open-source unit test framework that you can easily integrate into any project. Setting it up is pretty easy and you can follow the documentation for your specific platform.

Building your Core library (Part 3) - Math

Games are math. Just about every system you create will have some sort of mathematical component to it. Something as seemingly simple as having a character walk forward can use obstacle avoidance, animation blending, and position transformation just to name a few. That doesn't even touch the mathematics required to actually render the character. Luckily, as complex as the math in a game can get, it all really boils down to just three simple base concepts:

• Vectors
• Matrices
• Quaternions

These different concepts will be so crucial to the rest of the engine that it's important to think about a generic API for ease of use as well as performance. Qi will handle this by abstracting away the complexities of dealing with any underlying math operations as well as exploit SIMD operations to get better use out of the underlying CPU.

Building your Core library (Part 2) - Logging

Developing a game engine is a complex task that will be fraught with many logic bugs. To save time later, it's helpful to develop the engine code with some kind of system that makes it easy for the user to report information about the current state of the engine. This is where a logger comes into play. Imagine that you've recently found a bug in the engine and want to know the flow of events that led up to it. You could add a bunch of print statements all over the code and binary-search your way to the solution hours or even days later. Or, you could just go look at the output log that the engine already generated for you! An example log may look something like this:

Engine Log Output ----------------------------------------
Engine.cpp(277)  : Initializing Rendering System
Renderer.cpp(135): Loaded shader "bloom"
Renderer.cpp(135): Loaded shader "blur"
Renderer.cpp(116): Can't load shader "hdr"
Renderer.cpp(170): Renderer initialized
Engine.cpp(278)  : Initializing Physics System
.....
Engine.cpp(278)  : Physics system failed to initialize!

Obviously you would want much more information that this, but that should give you an idea of what a simple log could look like. It's important to color-code the log because later on when the log has tens of thousands of entries, looking for specific colors can be a very quick way to get the information you need.

Let's make a quick list of features that the Qi logger should support:

• User friendly
• Threadsafe
• Automatically add information to the log about where the message came from
• Logging channels
• Per-channel event registering
• Automatically log all messages to a file in case the engine crashes

I'd like the logger to be able to work as simply as this:

Qi_LogInfo("Initializing screen size (%u x %u)", screen_width, screen_height);

Building your Core library (Part 1)

When you think about a game engine, there are many aspects that probably jump to your mind first: rendering, physics, AI, etc... While these are all of the more "user-facing" parts of an engine, there are many parts which go unseen that are just as (if not more) important. Just to name a few (in no particular order):

• Debugging Facilities
• The engine should log messages about what it's currently doing and output it to a log somewhere. This can be an invaluable tool for a programmer trying to understand the flow of events in the engine.
• Messages are great, but oftentimes to really understand a bug you need to visualize the problem. Debug drawing utilities allow programmers to insert drawing code for simple primitive types into the rendering command stream for easy visualization.

Feature Wishlist

This blog is mostly about the development of a game engine. And, first things first, a game engine needs to have a feature wishlist! This list can be anything that you want your engine to use/achieve really...there's no problem "shooting for the starts" so to speak.  Reality may set in later, it's true. But for now, anything's possible...right? :)

Therefore, without further ado, here is my wishlist for the Qi Game Engine: