Please note that I don't update this web site anymore. You can visit my new personal blog at

The Trichromix Code Structure

Sunday, December 19, 2004

As might be inferred from the long time I haven't blogged (not counting this mornings post, obviously), I've been busy programming Trichromix. I've decided not to use the Torque engine and it's been working out so well that I wonder why I even considered it in the first place.

About a year ago I started working on an engine for 2D games which I call Flatland. Its main goals were ease of use and portability. Flatland defines a couple of base classes for the game programmer to work with. The engine programmer can override the virtual functions of these base classes to implement Flatland for a certain system. This way, the game programmer can switch between different implementations of Flatland without having to adjust his code. That's the idea behind the Flatland engine in a nutshell and I'm quite satisfied with it.

My current implementation of Flatland uses the Simple Directmedia Layer which is a cross-platform multimedia library already, so for now I won't even have to implement the Flatland interface again to support the Mac or Linux.

Trichromix is made up of three parts: the game logic, the user interface and the underlying engine, which is - you guessed it - Flatland. I have a seperate Visual Studio-workspace for Flatland to make absolutely sure that there is no Trichromix-specific code in the engine. My Trichromix-workspace contains three projects: one for game logic, one for the user interface and one for unit testing. The game logic-project is built into a static library. The user interface takes the static libraries of the game logic-project and of Flatland and combines it with code of its own into Trichromix.exe.

The unit testing-project contains unit tests for the game logic-project. This has resulted in a nice seperation between the game logic and the interface. The game logic was finished before I even started working on the interface. I'm programming the interface now and it's very nice that I don't have to worry about the game logic. Running the unit tests is part of the build process, and failures get output to the Visual Studio-task list. So when I have to add a unit test because of a bug in the game logic, I don't even need to switch the current start-up project.

Programming the user interface is by far the most time-consuming part. The game logic adhers to very absolute rules which are easy to test automatically, but the correct behaviour of a user interface isn't that easy to define in code. For Trichromix I will just have to live with this, but I hope to find a way to automate at least some of the user interface testing in the near future.

Back to blog index


GBGames says:

I recently looked into CppUnit with the goal of actually learning how to use it rather than just get an idea about it. It actually doesn't seem too bad, except any tutorials I find are badly written or too high level. It's going to take some practice to get used to it, like all things. B-) I just saw your response to my previous comment. What are you actually using for unit testing?

Monday, December 20, 2004 4:41 PM

Joost Ronkes Agerbeek says:

Currently, I am just writing tests manually. In other words, if I want to test my Foo class, I create a FooTester class with a public Run() member function. Run() calls some private member functions that contain the actual unit tests. In main(), I create a FooTester instance and call Run() on it. I have written a couple of macros like AssertEqual, AssertNotEqual, AssertTrue, AssertFalse. These perform the tests. When a test fails, it writes the file name, line number and error message to the cerr-stream. I send this output to the Output Window and this makes the test failures show up in the Task List. It's a bit primitive, but adequate for my needs. The main problem with this approach is that you have to declare and define the tests seperately and that you should not forget to run the test from main(). From what I've seen though, CppUnit doesn't solve these problems. Note that I am not saying that CppUnit is bad or anything; I just feel it's not the right choice for me.

Monday, December 20, 2004 10:31 PM

GBGames says:

Actually I've found a few more alternatives to CppUnit. I wish there was more of a consensus on what is commonly used. It is interesting that everyone who uses Java knows they can just use JUnit whereas C++ programmers are either avoiding CppUnit like the plague or don't do unit testing. Writing your own unit testing code seems good for small programs. It's not like I plan on writing major applications, so I might do the same. Thanks!

Tuesday, December 21, 2004 4:12 PM

GBGames says:

You may want to look into this book: Effective GUI Test Automation: Developing an Automated GUI Testing Tool Amazon doesn't have any reviews of it, but I thought it might be something you would be interested in.

Wednesday, December 22, 2004 2:29 AM

Joost Ronkes Agerbeek says:

Thanks for the tip. Judging by the information on Amazon, the book deals exclusively with .NET. I've been programming on the .NET-platform for a couple of years so that isn't really a problem. My only concern is that the solutions presented in the book might not scale well to non-.NET environments. Still, maybe it will give some ideas on coming up with my own approach. If I decide to buy the book, I'll let you now if it's worthwhile.

Wednesday, December 22, 2004 9:54 AM

Tell me what you think

Since I'm not updating this site anymore, I disabled comments. You can visit me at my new site: