University courses

This semester I mentored a lecture on "computer physics and numerical methods" at university. Though one key aspect of the lecture was to allow the students to use whatever tools they wanted to use most of them did their assignments in C++. Topics included numerical root finding, ordinary and partial differential equations as well as monte carlo methods and numerical fourier transforms. I also created the weekly exercise sheets and programmed the sample solution which allowed me to polish my C++ skills again. Please cross your fingers for the students as the lecture's written exam will be tomorrow. Good luck to all of you! I also visited an university seminar on "advanced C++ programming" in which i learned a lot about C++11, C++14 and the cool new feature of concepts to be introduced in C++17.

Writing Games in C++

All this made me want to write a game in C++. Since I began developing games using C++ (but got stuck with barely playable prototypes for various reasons) this was some sort of coming home. You can play the result Quad Triad.

Most of our games have been developed in some (abstract) high level languages like C# or Haxe with some very helpful tools and engines like Unity3D or HaxeFlixel. Going back to a kind of native approach using just vim, plain C++11 and SFML 2.3 felt really clumsy and very unproductive at first. It took me days just to set up a basic game loop and get some sprites rendered as well as some input routines. That's one of the reasons, the graphics for Quad Triad are really simple. Having to think about which data type should be stored in which pointer, when memory has to be allocated and when it can be safely deleted again (although C++11's shared and unique smart pointers are really handy!) was a real pain. Not to speak of the really broken include model (include guards) of C++ or my deep rooted hate for Makefiles.

After the game has been brought to a level where I didn't have to cry myself into sleep I started playtesting. Besides the above-mentioned problems there are of course the usual bugs that sneak into a game. One funny thing that happened: placing a card removes the card from your deck and places it on the table. Bad stuff happens when the slot is already ocupied: The player's deck did not have the possibility to check if the slot was free. Test early, test often!

Compiling for different OS

Somehow I managed to finish the game to a playable state. Bad luck for me, I developed on my Linux laptop. Most gamers still are on Windows. Trying to compile on Windows failed for almost two days for various reasons:

• Visual Studio does not offer most of the C++11 features I use (like the shared pointers, constexpr, auto, ...)

• MinGW can (and will) be a real pain concerning versions and compatibility (DW2, SJLJ).

• You want to use that library (SFML2)? Good for you there is a windows port, bad for you it was built with a different compiler!

• Compile a library on your own? Good for you there is cmake, bad for you you have to do all the windows path tinkering.

Recap, Summary

Nevertheless I finished with a working Linux and Windows build. No, there won't be a Mac version. Though it was a really hard process I must say that it was kind of fun and I really learned some valuable skills. Currently I am totally proud of myself to offer my first real C++ project (though it's ugly, not juicy and probably no one will play it). It is even my first cross compiled project that works on different operating systems.

Though my next project will be definitely done using HaxeFlixel (for the Indies vs Gamers Jam on Gamejolt) I want to keep creating games with C++. Not that I especially like pain that much, but because for a long time I really had the feeling that this project in particular boosted my skills.