Hostile Worlds Source Code Released

It is done: The source code of Hostile Worlds along with all assets is available now on Github under the UDK EULA. Please note that the content of that repository is subject to the terms of the readme file found there.

Additionally, Daniel has created awesome new concept art for new units and environments for his master thesis, check them out on IndieDB! In case you’ve missed it, take a look at our beta trailer as well, it’s really worth watching.

Finally, Hostile Worlds has gone beyond 10.000 downloads in total! This game has been the biggest software project I’ve been working on in my entire life, and I’m really proud of what our team has achieved. Thank you all for your great support during the course of the development of this game, you guys are really awesome!

You’d be surprised…

This great comic has just come to my mind again. Was sent to me by my supervisor at Kiel University while I was working on my bachelor thesis…

“You’d be surprised how many times the Cook-Levin theorem was used in making the Halo 3 Engine.”

VRAM Jenga

The latest issue of Making Games features an article I wrote about the challenges of adventure game development. It summarizes the lessons learned by Daedalic Entertainment who have been working with the Visionaire Adventure Game Engine for many years now – just check it out!

Guide to Faster, Less Frustrating Debugging

“As important as debugging is, especially in game development, techniques in debugging are rarely taught.” – Mike McShaffry

Luckily, Norman Matloff wrote a nice article about how to properly debug software and find even the nastiest bugs using the gdb. The introduction of the text applies to all programming environments and might be helpful for everyone, so here’s a short summary.

Matloff understands the process of hunting a bug as follows:

“Finding your bug is a process of confirming the many things you believe are true, until you find one which is not true.”

An example might be that you assume a certain variable value at some point of execution. Then, the task of finding the bug boils down to the verification of this variable value. Matloff proposes some kind of binary search strategy: For the sake of simplicity, we assume our program is composed of 100 lines of code without any jumps or function calls. Then, check the value of the variable at line 50 – if it isn’t correct, you just narrowed down your search space to lines 1-49. Next, check the value at line 25, and so on.

This easily extends to most programs which contain jumps and function calls, of course. In the case of a game, you just need to fully understand the nature of your game loop, that is, the order of update and draw calls and the order your game components are ticked.

Things get a little hairy for distributed or multi-threaded applications… If you don’t have a proper debugger at hand, you’ll have to use log output in order to ensure that all variable values are properly sent and received between machines and/or threads, and that all function calls are properly passed along with their parameter values.

Take a look at the original article and let me close with a quote by one of my supervisors at Kiel University that’s been on my mind for years now: “If the bug can’t be found where you expect it to be, you’d better start looking where you don’t.”

Crappy Code 0: Display Resolution

Every programmer knows these moments. You come across those few lines of code that make you think: “Whoops…”. Or better: “Wat.” Most often this code is the result of crazy deadlines or massive refactoring of other parts of the application – or just simple stupidity.

Sometimes this code is your own.

In order to share these great moments with you, I decided to start a series I’d like to call Crappy Code. Should you ever run into any code that you think could fit this category, feel free to send me a mail to crappycode(at)npruehs(dot)de.

Let’s start right away with this little jewel: The first part of this series is about a piece of Python code that is ought to adapt the size of some buttons to the current display resolution.


This is the pure opposite of a resolution-independent UI. In fact this code has been taken from a game that was originally designed to be played with two resolutions, only: 1024×768 and 1280×800. Unfortunately, I got honored by the task to make the game look somehow good on laptops now, which – who’d have thought – includes other resolutions as well.

Second point: Where do all these strange numbers come from? What the frack is 0.352 * 0.95?

Ah. Yes. It’s 0.3344. I see 😉