Monstaaa! development summary – part 2

Note: click here to read part 1 of the Monstaaa! development summary.

It’s been over a week since my iOS game Monstaaa! was released on the AppStore. The game was featured in Apple’s New & Noteworthy on the iPhone (Australia and New Zealand only) and got a lot of great reviews including 8/10 by 148Apps4.5/5 by iFanzine or 4/5 by iReviewT as well as heaps of mentions on various gaming sites. But even though it’s getting mostly very positive feedback, the sales, except for Australia, have been rather low so far. That is no surprise however. Without stronger featuring by Apple only few iOS games succeed these days. But I’m far from saying this is the only reason why Monstaaa! didn’t sell in millions 🙂

Anyway, the game’s been already played by a couple of thousands people, so I thought I’d share analysis of some of the most interesting game statistics here. What surprised me initially was that majority of the Monstaaa! players pirated the game. But this doesn’t matter too much… they still provide good source of information for me 😀

Statistics gathering

The game has built-in statistics gathering system that reports pretty much anything that’s happening in the game – from button presses to achievements being unlocked to level progression details. The data is simply sent via HTTP by the game; when received on the server side it gets inserted into one big SQL table using simple PHP code.

Having all this information I was able to quickly extract some of the most interesting data. I was considering using Flurry or other systems for data collection but decided to go with a custom implementation in the end. What I didn’t like about Flurry were its huge delays between data being collected and data being available; with my system everything is real-time. So far everything works well and until the game gets played by an order of magnitude more players bandwidth and SQL efficiency shouldn’t be my worries.

Gameplay statistics

One of the most interesting information for me is how many people get to successfully complete each level (the game currently has got 64 levels). That’s exactly what the chart below shows:

Only 70% of all players completed the first level, 62% completed second level and only 10% completed the 9th level. And just so you know if haven’t played the game – the first and second levels are really easy – you have to really try hard not to complete them and there’s no way you can fail!

So, what are the conclusions here? On one hand this doesn’t look very good because it means most people only play the game for a very short time. But on the other hand we should probably take into account the characteristics of average iOS/Android players – it is very common for them to buy the game, run it once or twice and then stop playing it forever. With massive number of games on the market this is unavoidable. And probably even more so with games being pirated – if you didn’t pay for it, you typically have slightly less interest in playing it.

Also, part of the reason why there’s so many people who only played first few levels is – so I believe – that the game’s been out on the AppStore only for a couple of days. But it still doesn’t mean your game can’t do better. Mine certainly could and part of the reason why it didn’t do well enough is explained in the next chart that shows an average number of attempts while trying to complete each of the levels:

While it looks okay’ish up to level 6th, levels number 7 and 12 clearly seem to be too difficult. With both of these levels you can see spikes which indicate sudden difficulty change with respect to previous level. But there’s more levels that are too difficult or not in the right spot in Monstaaa! – and this certainly is one of the things I’m going to improve on with the next update. Ideally, there should be no spikes at all and the chart should show you bars of the same height throughout all of the levels.

Figuring out which levels are too difficult is in fact really tricky before you actually release the game and collect some statistics from a larger group of users. In any case, having tested the game on a couple of friends it wasn’t obvious that levels 7 and 12 are indeed too difficult. Now I know this for sure!

Monstaaa! is a tilt based game and, while I knew tilt controls can be difficult to master for many, I spent a lot of time trying to make the game easy enough, especially at the start. As it now turns out more work is needed on the difficulty balancing side of game.

Users statistics

I’m not going to give you exact number of copies sold just yet as I’m too shy for that but I’m going to show you how many users played the game every hour and also how many new users started playing every hour (which kind of gives you clue as to what the sales might be):

The reason you can easily see “daily” spikes in there is because the game was featured in New & Noteworthy in Australia – spikes simply correspond with days and nights there. The highest number of players during one hour (blue line) was 93 and the highest number of new players (orange line; most likely ones who just purchased, or pirated, the game) over single hour was 64.

Ideally you’d want both number of the users (blue line) and number of new users (orange line) to rise indefinitely with the first one rising faster than the latter – this would mean you get more and more new users while the “old users” would still keep playing your game.

Device statistics

Finally here is some insight into what were the most popular devices that had Monstaaa! installed on them:

The iPad’s and iPhone’s shares were almost identical at 45% with remaining 10% going to iPod touches. iPad2 was the most popular among iPads and iPhone4 was the most popular among iPhones with iPhone4S being next most popular. Looking at these stats one should take into account the fact that most of the Monstaaa! users are probably from Australia being – that is my impression – a very “iOS friendly” country.

My final word here is, if you’re releasing any game for any platform make sure you implement at least some basic statistics gathering in there. It takes little time but it will give you a lot of priceless information about how your game is played and how you can improve it.

That’s it for now. Check back soon for more development info about Monstaaa!

UPDATE: Check my next blog post in the series covering Android sales and more.

Posted in indie game development, mobile game development | 6 Comments

Monstaaa! development summary – part 1

Today is the day. The game I’ve been working on for the last 6 months gets released on iOS as a universal app. Monstaaa! is finally available on the Apple App Store! Yeah!!!

Now, here is the summary of my indie game development adventures over the past months that led to this moment. If you’re thinking of going indie, especially with mobile game development in mind, you might find here some useful tips.


But first off let me introduce yourself a little bit to the game.

If you haven’t heard of Monstaaa! – it is a unique take on physics based puzzle games in that it uses tilt controls to modify the gravity. The goal is really simple – just feed the Monstaaa with all delicious bugs that you can see on screen. As you tilt your device the bugs fall into, always hungry, Monstaaa’s mouth. Getting any of the bugs killed in any way (and there’s many ways!) makes Monstaaa sad, so you better take good care of them!

I believe the game has got some really original base concept, is fun to play and looks good but the way it usually works is it’s up to everyone else to really prove it 🙂 If you’re still wondering what it is, here’s Monstaaa! in action including footage with the actual device:

Going indie and budget

Before going indie, I had spent 4 years at Blue Tongue working as an engine/technology programmer. It was a great time to be working on big games, I really enjoyed it, but when last year THQ shut down my studio I wasn’t upset at all. In fact I already knew what my next job was going to be. For me, this was perfect opportunity to try indie game development, something I’ve been dreaming of for the last few years. However, being just an engine programmer on console and PC projects for the last 7+ years it was a big challenge for me to switch to managing the whole game production myself – from game design and artwork, through programming, to publishing, marketing and website design.

Developers from big companies becoming indie developers is something we got used to hear about frequently lately. But how many actually succeed? And for me, the most important question was simple – am I going to make living off of that? I guess we’ll see in just few days 😀

I gave myself up to one year to develop and publish one mobile game (though I ended up making two!). From the very beginning I set aside a very limited budget for any, strictly game development related, expenses I might have. Now, Monstaaa! has just been published and to this date I spent just above AU $10k on everything, including company set up, accountant, insurance, developer accounts, software, hardware, art and audio – everything. Does this sound like very little money to make this kind of game? Well, I think it really does!

Having hard limits for time and money I could spend on the project made both myself and my wife feel more secure because if it wouldn’t work it wouldn’t be that big drama – I’d simply start looking for another job. But even in the case of financial failure it would still be, and it was I tell you, a great experience.


Small project first

When you’re working solo on a game no one tells you what or how to do anything. It’s just you who makes all of the decisions on the project – whether it’s an important high level design thing or just a not-so-important button color in some menu screen. Decision making is a critical skill one learns they need to use all the time when working for themselves.

With anything I did on this project I tried to make sure that my precious time wasn’t being wasted. I was totally new to mobile game development at the time and I knew there was a lot to learn for me and a lot of mistakes to be made. Realizing things never work out perfectly the first time I tried to minimize them as much as possible. My way of doing so was by making and publishing some very small game first. For me this was one of the best decisions!

By making simple game one learns a lot. I spent just 1 month developing small puzzle game called Puzzled Rabbit which was then published on a number of platforms including iOS and Android. The game wasn’t financial success at all but I still consider it a big success overall – I learned a lot about mobile development while making it and as a result I was in a much more comfortable situation when starting works on a larger game being Monstaaa!



Figuring out what technology to use took me some time – see my previous post – and I eventually happily decided to use Marmalade SDK. Again, without making a small game first, it would have been much more painful process.

Using Marmalade I was able to develop 95% of Monstaaa!. The remaining 5% went into implementing iOS specific features not present in the SDK like iCloud support. The cool thing about using Marmalade was I could test the game on PC in a simulator and I could make iOS builds right on my PC without even requiring Mac. Also, being able to use Visual Studio was a big thing for me – someone who’s been using it for 10+ years.

Turns out, unless you want to take advantage of some fancy iOS features, iOS game development is perfectly possible on Windows. Good news for many! But the feature that made me love Marmalade is its support for multiple platforms – in fact Android version of Monstaaa! is already mostly working without any extra effort.

I could have gone a different route of developing the game using native iOS or Android SDKs but getting familiar with them would take a lot of my precious development time. With Marmalade I could focus more on the actual game so, overall, I think using it was my second good decision.

To be continued…

My future blog posts on Monstaaa! will include promotion and launch summary, sales analysis, post-mortem of working with artists, iOS & Android technology tips and more cool stuff. Make sure to check back soon or simply subscribe to my blog!

EDIT: Part 2 of the Monstaaa! development summary is here.


Posted in general programming, indie game development, mobile game development, physics | 2 Comments

Monstaaa! for iOS – the first announcement

Just a quick (and big) announcement today!

The game I’ve been working on for the last 6 months is finally going to be released on iOS. It is called Monstaaa! and should be available on the 29th of May 2012 as a universal app on the Apple Store.

Monstaaa! is a truly unique physics based puzzle game with tilt controls and some great painterly graphics done by a friend of mine, Drew Morrow (ex artist at Blue Tongue / THQ) and audio done by guys at Kpow Audio (ex audio guys at Team Bondi / Rockstar Games). If you enjoy puzzle and/or physics based games there’s high chance you simply fall in love with it! But more seriously, we put a lot of heart into making Monstaaa! and we hope people will notice. Let’s see!

Here’s some screenshots from the game running on the iPhone:



Now, make sure to follow Monstaaa! Facebook page and check out the game’s website. More news about the game coming really soon!


Ps. On the more technical side of things, the game was developed using Marmalade SDK and Box 2D physics engine but I’ll talk about that in more detail in my next blog posts.

Posted in general programming, mobile game development | Tagged , , , , , , , | 2 Comments

iOS & Android game development on Windows

UPDATE: Read here about my second game Monstaaa! made on Windows using Marmalade SDK.

When I started indie game development 6 months ago (see my previous post Good bye Blue Tongue (and time for indie game development)) I knew I wanted to experiment with games for iOS and Android. I knew nothing about mobile development at that time but I was kind of hoping there would be ways to develop my apps cross-platform (iOS, Android and possibly other platforms as well). And I wasn’t very keen to invest into a Mac just so I could develop for iOS. That’s when I started my investigation of available solutions.

In this post I’m going to give you a quick run down of my findings when it comes to available software / SDKs for cross-platform mobile development (mostly iOS and Android) under Windows. As part of that I’m also going to compare 3 different SDKs: DragonFire SDK, Marmalade SDK and Unity3D.

DragonFire SDK

The first thing I came across while searching for ways to develop for iOS from Windows was DragonFire SDK. It’s iOS only but it’s cheap. You develop on windows under Visual Studio and test in their simulator. And if you want to test it on the iPhone or iPad you send them (via their website) your full source code and game assets (images, sound and all other data files) and they send you back compiled binary. What I initially liked about DragonFire SDK was that it had extremely simple C-style API – just one header file with a hundred or so functions for graphics, input, files, audio etc. Everything looked pretty straightforward.

I purchased the cheapest, $50 iPhone only, license and started experimenting. I set myself a goal of making simple sokoban game as quickly as possible, just so I could test that the SDK really does the job. The game was ready in about 5 days and run very well in the simulator. There were few problems and some bugs with rendering that I had to make workarounds for but finally all worked. Now I wanted to test it on my iPad and that’s where the problems started piling up (or become more obvious).

Firstly, it turned out that the whole source code has to fit in a single CPP file. Wow. Being curious what other people do I searched their forums and found community project that merges all CPP and H files into single CPP. Worked for me. Checked.

I paid another $50 for “ultimate iPhone” license meaning I could now test the game on the device. I packaged my build and sent to DragonFire, so they would compile the project for me. A day later I got my .app (iOS application) file and tried to install it on my device. No luck. The build wouldn’t install complaining about some incompatible configuration. I could investigate more, send question to DragonFire support or ask on the forums but there were also few other problems and all that together already made me quite uncomfortable about using DragonFire SDK. That’s when I slowly started looking around in search for other solutions out there…

In the end I haven’t even gotten to the point of getting my game to run on the iPad via DragonFire SDK. I quickly realized DragonFire SDK was not the right choice for me, and it wasn’t so for just one reason. Below my quick summary of mentioned SDK:

Cons (cons first because more important):

  • extremely limited API (e.g. can only draw rectangles, no polygons; no support for “fancy” stuff like iOS GameCenter)
  • buggy rendering code (at least in the simulator)
  • all apps are fixed to 30 frames per second
  • the whole source code has to be in a single CPP file
  • assets once loaded stay in memory forever (sure, why would you ever want to free up some memory?)
  • can’t make iOS build on Windows + terrible turnaround times (need to send them your source code + assets, then wait for reply; took 1 day in my case)
  • terribly slow PC simulator (couldn’t even get 30 fps for my sokoban game; and I do have reasonably fast laptop)
  • iOS only
  • no debugging on the device (this one is pretty obvious but just wanted to make things clear)


  • cheap ($100 for iPhone or iPad license; $150 for both)
  • compiles to native ARM code (meaning no emulation -> fast)
  • extremely simple API
  • can develop on PC under Visual Studio
  • can submit to Apple Store without Mac

My final word is: even if you’re not serious about iOS development, you better stay away from it.

Marmalade SDK

The next thing I started looking at was Marmalade SDK. They had completely free 90 day trial, their API seemed way more complete than the one from DragonFire SDK yet simple and very clean. And they seemed to have pretty large and lively community. Also, knowing that games such as To-Fu (one of my favorites on the Apple Store) have been made using Marmalade SDK was very encouraging.

The next day my game was already running in the Marmalade simulator on Windows. And after one more day it was running on my iPad too. One great thing about Marmalade building process is that you don’t need Mac to make iOS build, you can do it right on your PC (Windows), locally. They do however also support building from Mac.

Few more days and I also had my game running on Android and Blackberry PlayBook. Since Marmalade is based on C++, it does support wide range of devices including ones supporting ARM (e.g. iOS, Android), MIPS (e.g. LG Smart TV) and X86 (e.g. Windows) architectures. Depending on the target architecture they just use different C++ compilers. The good thing about this is that the code you write runs natively on the device which means it’s as fast as possible.

I still plan to make a short post-mortem of the development of my game in a separate post, so I won’t go into too much detail here but I wanted to say that Marmalade was really a great choice for me. And the proof for that was that my sokoban game has been successfully released on iOS, Android and Blackberry PlayBook (check out Puzzled Rabbit).


Now, here’s my full summary of Marmalade SDK:


  • still pretty cheap: standard license (without Marmalade logo at startup) is $500 which gives you access to all SDK features
  • great (mostly) C style API: simple, clean & flexible (e.g. if you want, you can use OpenGL ES directly; or, if you prefer, you can use their higher level IwGx rendering API)
  • powerful: built-in support for so many different things (e.g. Game Center, camera, photo gallery, HTTP)
  • compiles to native ARM / MIPS / X86 code (meaning no emulation -> fast)
  • supports mixing with native code (e.g. Objective-C on iOS or Java on Android) to create custom extensions that do whatever you want
  • great open-source community projects: lots of goodness there including ports of very many popular C/C++ libraries (see full list here)
  • can develop on PC under Visual Studio or on Mac under XCode
  • can build iOS apps on Windows
  • very good PC/Mac simulator
  • support for native iOS builds on Mac (so, it’s possible to debug the code!)
  • support for many platforms (including iOS, Android and less popular ones such as Blackberry PlayBook, Bada, WebOS or Symbian)
  • support for asset pipelines: fonts, compressed textures, materials, models, animations


  • occasional bugs in the SDK (fortunately they do try to help you via support or forums – though sometimes it does takes a while)
  • some issues haven’t been fixed for surprisingly long periods of time, e.g. correct splashscreen handling on various devices has been broken for months!
  • not all new features get added quickly (for example iCloud support isn’t good at the time of writing this, e.g. has no support for conflict resolution)
  • can’t submit to Apple Store without Mac (not a big deal though; took 5 mins on my friend’s Mac)

My final word is: Marmalade SDK is truly great piece of software. It is very well designed and it does the job even though it has some (minor) issues.

I should also mention that for the last 5 months I’ve been developing my next, much larger and more sophisticated Marmalade based, game for iOS and Android and it’s been going really great. I was able to integrate lots of (3rd party) libraries and technologies including Game Center, Open Feint, Facebook, Box2D, camera, photo gallery or jpeglib. I wasn’t able to add support for iCloud yet because of limited support for that in Marmalade but thanks to support for native extensions I still plan to implement it (though, yes, I’ll need a Mac/XCode for that).

Unity 3D

I have no experience with Unity3D, so I can’t say too much here. It definitely seems to be a solid piece of software and there’s been tons of projects released on iOS and Android that were using it which is a good thing. In fact 90% of my indie dev friends are using it, so I do very often get a chance to learn about it from what they tell me.

But there’s few things which, when compared to Marmalade, I didn’t really like. These also were my reasons for choosing Marmalade rather than Unity3D:

  • emulation from (managed) C# via mono (meaning higher memory usage and worse performance; also garbage collection seems to be causing performance issues / frame rate spikes for some developers)
  • more expensive: license for iOS and Android without Unity3D logo at startup costs $2300 ($1500 for Unity Pro + $400 for iOS + $400 for Android); more advanced features cost you additional $1500-$400 for iOS and $1500-$400 for Android
  • additional functionality (via plugins) might cost you another couple $$$ (e.g. audio recording, Game Center, GPS – see here)
  • high level & complex object oriented code you have to deal with
  • need to have Mac to deploy to iOS device

The only advantage of Unity3D over Marmalade that I know of is that it has nice 3D scene editors and other tools. Depending on what kind of game you’re making this might be a bonus.

If I missed something important while comparing Marmalade with Unity3D then simply let me know and I’ll try to fix that.

Now going back to finishing up my upcoming, still unannounced, game. Expect some news about it really soon!

Posted in general programming, mobile game development | 17 Comments

Packet encryption in multiplayer games – part 2

The following is continuation of my recent Packet encryption in multiplayer games – part 1 article.

In this article I’m going to present sample implementation of the encryption helper that might be used to establish connection using Diffie-Helman algorithm and then send and receive messages using Blowfish algorithm. All based on OpenSSL implementation.

Please note that this code is written for educational purposes only and that it is probably far from quality acceptable for exchanging data that needs to be really secure. Also, it is worth reminding that in general the algorithms used here, i.e. Blowfish and Diffie-Helman are considered relatively easy to hack (far from RSA). Using them is more of a “no trespassing” sign to the hackers than the actual protection.

Below is how you’re supposed to use the code.

Step 1
First off, let’s declare some buffer and initialize OpenSSL library.

Note: We’re going to test sending messages of both 8-byte aligned and non-8-byte aligned sizes below. This is particularly interesting due to Blowfish algorithm operating on chunks of 8 bytes.

#include "EncryptionHelper.h"

void EncryptionHelper_UnitTest()

const int UNIT_TEST_BUFFER_SIZE = 256;

// Make it 8-byte aligned


// Make it non 8-byte aligned


int length;
unsigned char buffer[UNIT_TEST_BUFFER_SIZE];

// Initialize OpenSSL


Step 2
Next initialize encryption helper for Alice and Bob (why Alice and Bob?). If used for multiplayer game, Alice would only be created on one machine whereas Bob would only be created on another machine. It’s up to user to decide who is Alice and who is Bob but in order to get things working with this library it is necessary that one of them is Alice and the other one is Bob.

Note: the ‘check’ is similar to an assertion macro; the difference is that it evaluates expression regardless of whether assertions are enabled or not.

// Initialize Alice and Bob

EncryptionHelper* alice = EncryptionHelper_Create(true);
EncryptionHelper* bob = EncryptionHelper_Create(false);
assert(alice && bob);

Step 3
We’re now going to generate “exchange data” on Alice side. This “exchange data” contains Alice’s public key as well as 2 parameters, P and G, as needed by Diffi-Helman algorithm. Once message is successfully sent (from Alice to Bob), we can mark it as sent.

// Alice generates exchange data and sends it to Bob

check(EncryptionHelper_GetExchangeData(alice, buffer, UNIT_TEST_BUFFER_SIZE, &length));

// [ sending… ]


Step 4
Once Bob receives “exchange data” from Alice and verifies its correctness, he can then generate his own “exchange data” (containing Bob’s public key) and send it to Alice. Once sent, Bob marks message as sent.

// Bob receives exchange data and sends another exchange data to Alice

check(EncryptionHelper_ReceiveExchangeData(bob, buffer, length));
check(EncryptionHelper_GetExchangeData(bob, buffer, UNIT_TEST_BUFFER_SIZE, &length));

// [ sending… ]


Step 5
Once Alice receives “exchange data” from Bob, the communication starts. We’re now ready to send and receive messages between Alice and Bob.

// Alice receives exchange data from Bob

check(EncryptionHelper_ReceiveExchangeData(alice, buffer, length));

// Authentication done! // Communication begins…

Step 6
Below Bob sends test message to Alice, Alice receives it and verifies that the message is correct.

// Bob encrypts data for Alice; Alice decrypts the data

for (int i = 0; i < UNIT_TEST_MSG0_SIZE; i++)
	buffer[i] = i;
check(EncryptionHelper_Encrypt(bob, buffer, UNIT_TEST_BUFFER_SIZE, UNIT_TEST_MSG0_SIZE, &length));
check(EncryptionHelper_Decrypt(alice, buffer, length, &length));
for (int i = 0; i < length; i++)
	check(buffer[i] == i);

Step 7
And now communication going the other way – Alice sends message to Bob.

// Alice encrypts data for Bob; Bob decrypts the data

for (int i = 0; i < UNIT_TEST_MSG1_SIZE; i++)
	buffer[i] = i;
check(EncryptionHelper_Encrypt(alice, buffer, UNIT_TEST_BUFFER_SIZE, UNIT_TEST_MSG1_SIZE, &length));
check(EncryptionHelper_Decrypt(bob, buffer, length, &length));
for (int i = 0; i < length; i++)
	check(buffer[i] == i);

Step 8
When done, deinitialize encryption helpers for both Alice and Bob.

// Shut down Alice and Bob



Get the source code from here EncryptionHelper.cpp and here EncryptionHelper.h and have fun!

Note: The code has only been tested on windows. Obviously, you’ll need to download OpenSSL library to compile it.

Posted in network programming | Leave a comment

Packet encryption in multiplayer games – part 1

Sending unencrypted data between peers in multiplayer game can make your game vulnerable to many kinds of hacker attacks.

However, as surprising as it may sound not all multiplayer games require data encryption to stay secure. In some cases only part of the data transmitted requires it and sometimes encryption isn’t needed at all. Instead of encrypting, it’s often enough to verify that the packet received from remote peer isn’t “hacked”. Now, what that means is a very game specific thing. For example, in terms of FPP shooter games like Quake or Unreal such packet verification might, for example, include checking whether the player’s velocity is within reasonable range. If the player was attempting to move faster than the game allows, we could simply consider his/her game being hacked.

It’s great if you’re able to validate data packet in this way and, if possible, it’s probably the best way of detecting if your multiplayer game gets hacked. However, in the case where full packet validation can’t easily be done for some reason or when you not want packet content to be easily readable by anyone (e.g. contains secret text chat), your next option is to encrypt the data using one of the popular encryption algorithms.

There’s large number of methods available but you could probably split them into 2 groups: symmetric key based and asymmetric key based methods. The first group uses one key to encrypt and decrypt the data while the second requires 2 keys – one (public) key for encryption and one (private) key for decryption. For more explanation see this article on Tech-FAQ.

Since asymmetric key based methods are more secure, ideally we’d just be using full-blown asymmetric key based RSA algorithm for all of our communication. It certainly is very safe method given that:
(a) the keys are large enough (e.g. 2048+ bits)
(b) we are able to verify the public key of remote peer.

While (a) might only create performance challenge, the (b) is difficult to solve in general. The question one shall ask here is: how can I verify that the public key I have received from remote peer hasn’t been hacked halfway through? This problem is well known as MITM (“Man In The Middle” attack) and the way modern world deals with it is via Public Key Infrastructure (PKI). The key element of PKI are Certificate Authorities which issue reliable certificates to others. The whole PKI is organized in a tree like structure. Some Certification Authorities issue root certificates to other Certification Authorities, and then Certification Authorities issue certificates to anyone else. To be able to make use of PKI one needs root certificate that would let them get certificate of any other entity. Such root certificates are typically stored hidden in hardware and/or software (e.g. in your web browser).

One might say all this isn’t very good solution because it is based on assumption that we have some non-hacked root certificate. But in the very darkest scenario you could imagine your hardware and software could be totally hacked and so all your root certificates could be modified! That is true but no matter how much you complain about this solution, it seems this is the best one that humanity came up with so far when it comes to reliable encrypted communication over the internet.

So… ideally what you might want to do when making very secure multiplayer game (that is one that encrypts all of its data) is you should first get certificate issued by CA. Then you should use it to get individual peers to exchange public keys via your certified “master server”. Once that’s done you can start secure communication directly between peers.

Getting certificate from CA sounds scary if you’re a small developer that wants to release multiplayer PC game (assuming you’re not using any 3rd party services offering secure authentication). So, instead of going hardcore you can stick with just using some asymmetric key based method and assume (somewhat naively) that the public key won’t be hacked while exchanging them between peers. Additionally, to somewhat improve security, you could at least do some cheap and simple encryption when exchanging public keys just so they’re not plain readable. However, no matter what, keep in mind that the most common MITM attack is done on a game running locally. And honestly, when the game is running locally there’s no way of preventing it from being hacked – this is simply because the hacker can see your application process’ memory and so he or she can do whatever they want with messages you send or receive. There is general solution to these problems which is: running your game on dedicated servers but that is beyond the topic of this post.

Note also that an asymmetric key based encryption might be an overkill for your game due to unacceptable performance. For this reason some multiplayer games, in particular fast paced “real real-time” games, decide to use different approach – a combination of symmetric and asymmetric key based methods. An asymmetric one is typically only used to initially exchange (or establish) symmetric key that is then used for regular data encryption using symmetric key based encryption. Note: while it might be okay for computer games it is most likely not okay for businesses where money is involved.

A common combination of asymmetric and symmetric key based methods used in multiplayer games is, for example, Diffie-Helman and Blowfish algorithms. Fortunately implementations of both of them are freely available, for example in OpenSSL library.

In the next part of the article I’m going to present a small C++ library that could be used to facilitate both key-exchange and encryption of the data using mentioned algorithms.

Update: part 2 available here.

Posted in network programming | Leave a comment

Good bye Blue Tongue (and time for indie game development)

It was a big news in game development industry when 3 days ago two Australian studios, Blue Tongue and Studio Oz, and one studio from US (Pheonix) were shut down by THQ. As part of these events around 200 people were made redundant. Me and my wife happened to be two of them.

I’ve been working for Melbourne based studio Blue Tongue for the last 4 years. Relocated from Poland in 2007, started working as an engine programmer. A year later my wife joined Blue Tongue as a gameplay programmer. Yes, if you’re wondering, we had a lot of common topics 😉

Now that Blue Tongue is gone let me just say few words about time spent there. It was wonderful time. I happened to be be part of “shared technology” team primarily working on a brand new tech for PS3, XBox360 and PC. I learned a lot of new tech stuff during this time which isn’t surprise given I spent 4 years there. But the main thing for me there was to learn that it’s actually possible for game development studio to be extremely employee friendly. Something which based on many articles on the internet you might think can’t be real.

Blue Tongue, from my point of view, was unbelievably motivated bunch of people. Excited about what they’re doing, always friendly and willing to help – whether they were your co-worker or boss it didn’t make any difference. It is just my guess, but I think morale level at Blue Tongue studio was much higher than in majority of other studios around the world. Also, from the programmer point of view, I loved the fact that major architectural decisions were always result of thorough research and discussion of the whole team where everyone had their say. In short, studio culture was great and I’m sure I’ll be missing it wherever is going to be my next place.

The last thing I want to say here is I hope many of the ex-BTE people are going to create their own small game development businesses and be successful there. As for myself, I definitely want to take this “opportunity” (if you can call it that way) and try and do some indie game development for a while. Let’s see how “easy” indie game dev really is in terms of getting enough money for your bills and some food. Whether it works out you never know but surely this is going to be exciting times… at least for the next couple of months 🙂

Now, again, good luck to all ex-Blue Tongue people and I hope our ways cross again in some future!

Posted in Uncategorized | 5 Comments

Simple 2D soft bodies in Box2D

Box2D is an excellent, widely used and completely free 2D physics engine. It has support for variety of 2D shapes and joints but there’s no out of the box support for soft bodies and so if you want one you have to do it yourself.

I’ve made an experiment and implemented simple round soft bodies using a couple of circles linked using distance joints, then thought why not to share it. Here’s how you use the code:

b2ExSoftCircleBodyDef def;
def.numParts = 10; // Number of linked internal circles
def.radius = 10.0f; = b2Vec2(0.0f, 15.0f);
def.softness = 0.5f; // Softness within 0..1 range
b2ExSoftCircleBody* body = b2ExSoftCircleBody_Create(world, &def);

And this is the result:

This slideshow requires JavaScript.

Get the demo and source code from GitHub and use it freely 🙂

Posted in physics | Leave a comment

C-like singletons

It is my impression that template based singleton patterns for C++ like this one are very popular and widely used. Why? I believe it’s mostly because OOP design patterns in people’s minds often take precedence over code simplicity and prevent them from thinking even for a while of what approach is best as a whole.

Having read this post on yesterday I decided to quickly present my preferred way of implementing singletons in C/C++.

For a start let me say that I’m a big fan of simple and minimalistic coding style which when I’m coding in C++ often results in code that looks almost like pure C i.e. mostly just functions and C structures. This is funny by the way because if you asked me a couple of years ago I’d probably say something different. Well, people change and I did change too in that matter (largely thanks to great coworkers at BlueTongue). Having experienced variety of approaches, from heavy object oriented designs to pure C-like data oriented designs, I now choose the latter whenever possible. It’s just a lot simpler and easier to maintain and it pays off when implementing large systems. And there’s added bonus that it’s often significantly more efficient approach, especially on consoles.

Now, back to main topic. Let’s assume we need some text localization manager. Here’s my way of doing it:


//! Starts up localization manager

void LocalizationMgr_Startup(const char* language = "EN");

//! Shuts down localization manager

void LocalizationMgr_Shutdown();

//! Loads translation set

bool LocalizationMgr_LoadTranslationSet(const char* setName);

//! Localizes ‘sourceText’ phrase; returns NULL on failure

const char* LocalizationMgr_Translate(const char* sourceText);


As you can see the header file only contains the very minimum interface. As a user of that system you don’t even get to see the internals of the manager – it’s all hidden in a source file as can be seen below.


struct LocalizationMgrData
  bool m_isInitialized;
  char m_language[16];

  LocalizationMgrData() : m_isInitialized(false) {}

static LocalizationMgrData s_data;

void LocalizationMgr_Startup(const char* language)
  strcpy(s_data.m_language, language);
  s_data.m_isInitialized = true;

void LocalizationMgr_Shutdown()

// TODO: Unload all translation sets – irrelevant for this sample

  s_data.m_isInitialized = false;

bool LocalizationMgr_LoadTranslationSet(const char* setName)

// TODO: Load translation set – irrelevant for this sample


const char* LocalizationMgr_Translate(const char* sourceText)

// TODO: Return translation of the ‘sourceText’ phrase – irrelevant for this sample


As you can see the source file contains data structure of type LocalizationMgrData declared as a static variable. This way it’s only visible from that single cpp. If it was to be visible from multiple source or header files, I’d simply put it into LocalizationMgr_Private.h. An important thing is that this data does not have to be parsed by the compiler when you #include LocalizationMgr.h – hence the compilation process is much faster. This really pays off when you design all of your game engine systems like that.

[Update] As per Arseny‘s comment, it’s worth pointing out that there’s slightly safer approach to declaring your data than what’s presented above. By making your s_data a pointer (i.e. static LocalizationMgrData* s_data) you benefit in 2 ways:
(a) you avoid static initialization order problems
(b) your code will most likely just crash if you use a function while system isn’t initialized; that is especially useful in Release builds where asserts won’t hit but it’s also useful if you simply forget to put an assert
The downside to that is that you need to dynamically allocate / deallocate memory in your Startup and Shutdown functions but this is a must anyway if you’re dealing with more complex data. In my example I was only using primitive types (char, bool etc.) which is why it was “okay”.

Now, here’s summary of my approach:


  • Header file contains the very minimum code from the user’s point of view
    • easy to read for a programmer
    • fast to compile for a compiler
  • Explicit rather than implicit singleton initialization (must call Startup / Shutdown “manually”)


  • All singleton “attributes” must be accessed via s_data
  • Have to put assert(s_data.m_isInitialized) in each singleton function in order to make sure it’s initialized when used
  • No easy way to support singleton polymorphism (in my opinion not a problem in 99% cases)
  • Code documentation generation tools like Doxygen won’t be able to figure out that all functions with LocalizationMgr_ prefix belong to same logical module; my solution to that is to use grouping feature using /defgroup around my header file but this isn’t perfect obviously; now, I’m also a big fan of self-documenting code, so ideally one wouldn’t need the docs at all, just looking at the header file should be enough 🙂
  • Similar problem as above with Intellisense; you won’t be able to type in “module” (e.g. LocalizationMgr) name’s prefix, press enter, and then start typing in remainder of the function name (e.g. Translate)

[Update] The 2 issues above can be solved in C++ by putting all of your functions into namespaces (e.g. namespace being LocalizationMgr and function being Translate) as suggested by Arseny in the comments.

As you can see there’s still some disadvantages to my approach but the (a) and (b) on the pros list are still more important to me than all of the cons. Which approach you choose is up to you, but before you make that decision ask yourself what your requirements are and which solution meets them best. For me, as with majority of programming related topics, KISS principle is a major one!

Posted in game engine, general programming | 2 Comments

Light Pre-Pass vs Deferred Renderer – Part 1

My questions

I have recently decided I want to spend some time experimenting with various approaches to renderers being used across PC and console games these days. In particular I wanted to look more closely at pros and cons of “traditional” Deferred with respect to Light Pre-Pass renderer which is slowly becoming more and more popular.

(1) What are the differences between the 2 approaches?
(2) What are the main limitations of each approach and what tricks do people do to workaround these?

These were my key questions which I can hopefully answer now, at least to some extent. If you just want to learn more about both techniques you may still find some useful information here.

Quick intro

Before I start I want to do a quick reminder on how each method works in a nutshell:

“Standard” deferred shading is a 2-stage process:
(1) draw (opaque) geometry storing its attributes (i.e. position as depth, normals, albedo color, specular color and other material properties) in a number of full screen buffers (typically 3 or 4)
(2) for each light source, draw its volume and accumulate lit surface color into final render target

I recommend you take a look at these great Killzone 2 slides for more detailed overview of sample deferred renderer implementation.

Light pre-pass is a 3-stage process:
(1) draw (opaque) geometry storing its attributes necessary for lighting (i.e. position as depth, normals and specular power)
(2) for each light source, draw its volume and accumulate just the lighting into an additional render target
(3) draw (opaque) geometry again; evaluate full material shader and apply lighting sampled from a buffer generated in step 2; this step is de facto forward shading

Read more on light pre-pass on Wolfgang Engel’s blog or in his presentation. Also, take a look at this highly informative presentation by Insomniac from GDC’09.

My answers

Now that we know the basics, let’s go over each of my initial questions and try to give answers to each:

(1) What is the key difference between the 2 approaches?

Number and cost of drawing stages
The first obvious difference is that light pre-pass requires 3, not 2 stages. On one hand this sounds like more expensive because you have 2 geometry passes in light pre-pass instead of 1 in deferred shading but on the other hand both of these geometry passes are cheaper. In light pre-pass, the first geometry pass only outputs what’s necessary for lighting phase: depth, normals and optionally specular power. The second geometry pass (3rd stage) doesn’t typically need normals and it may take advantage of early z cull, including hierarchical z cull on some hardware – hence the depth has already been written. Unfortunately the first geometry pass isn’t going to be as fast as just a depth pre-pass, especially on hardware with support for double speed depth pass – this is because we also output normals and specular power. For this reason, with light pre-pass, it might even be worthwhile to use custom CPU/SPU based geometry occlusion system.

On the other hand light pre-pass has considerably lower bandwidth and memory requirements – no heavyweight 4-render-target output and sampling needed any more. In fact, light pre-pass might even be doable without MRT (only if you can read depth straight from depth buffer i.e. X360, PS3 or DX10/11).

There’s an interesting post mortem by one guy who implemented both light pre-pass and deferred renderers in their engine on 3 platforms: X360, PS3 and PC. He says he got better performance with deferred renderer mostly due to having single geometry pass.

Material variety
One of the benefits of light pre-pass is it gives you a bit more freedom in terms of material variety (compared to deferred shading). It means you can run different shader for each geometry and so, you can calculate final lit surface color differently. Instead of having single pass per light as in deferred shading, here we’re having single pass per mesh. Having said that, you’re still quite limited in terms of variety in lighting models because available lighting attributes have already been calculated (during 2nd pass) – these typically only include accumulated Phong shading factors being N dot L and (R dot V) ^ SpecularPower (typically with light color and attenuation factors applied).

Another nice feature of light pre-pass is that it works much better (again, compared to deferred shading) with MSAA. It’s still not going to be 100% correct MSAA (unless DX10/11 level features are used) because lighting buffer used in the last drawing pass won’t be sampled at MSAA’ed resolution (talking about light buffer sampler here). However, it’s fairly trivial to get MSAA’ed geometry with non-MSAA lighting which may yield pretty good results.

(2) What are the main limitations of each approach and what tricks do people do to workaround these?

With both deferred shading and light pre-pass transparency is still typically done using old school forward shading after opaque geometry. There’s no efficient way around this, at least none that I know of.

With deferred shading it’s become standard to use some kind of post-processing to smooth the edges. This can be as simple as finding edges based on depth and normals and blurring these – see GPU Gems 2 chapter on how they did it in STALKER. Another popular, purely color based, approach to antialiasing is called Morphological Antialiasing (or just MLAA) – see Realtime Rendering blog for more info. It’s even been added as an on/off feature to Radeon HD 6000-series cards and it’s also widely used on PS3 via its SPU processors. Other interesting color based antialiasing methods include FXAA or SRAA. Now, as mentioned before, with light pre-pass we may just be able to stick with geometry-only-MSAA. Otherwise any of mentioned post-processing AA techniques still apply.

Specular color in light pre-pass
If you’re aiming at just using single light buffer, that means you have 4 attributes 3 of which are used for RGB components of the dot(N, L) * LightColor * LightAttenuation and so, you only have 1 left for specular lighting. Having 1 instead of 3 attributes we choose to just store single specular lighting luminance value (for example, luminance = 0.3 * R + 0.59 * G + 0.11 * B). But that means we loose specular lighting color which, if there’s non-white lights in the scene, may result in highly undesirable looks. Fortunately there’s this cool “trick” that let’s you reconstruct light color from diffuse lighting components. It’s not perfect as it only works correctly for a single light but it’s definitely better than nothing – see Max’s Programming Blog for a nice explanation of it.

Materials / lighting models variety
Both approaches are very limited in terms of material / lighting models variety. In a traditional forward renderer the shader had access to both light and material properties and so it could implement any kind of fancy material. In deferred renderer material properties are accessed first, then what the lighting pass gets is just fixed set of generic attributes (e.g. albedo color, specular color). Now, with light pre-pass, we have a bit different situation. One could say it’s even less flexible because we’re pretty much locked with Phong diffuse / specular shading model. Unfortunately, implementing something more complex like Oren-Nayar isn’t easily doable with light pre-pass as is the case with any other “non-standard” material / lighting models.

The only way I can think of one could support multiple material / lighting models in their deferred renderer (doesn’t apply to light pre-pass) is by storing material id during the first pass in a G-buffer and then branching in a shader code based on its value. It may not be too bad performance wise due to coherency among samples but this means your shader code gets more complex (messy!) too. Neverthless, I think this could be quite a good approach to multiple material / lighting models.

That’s it for now. I feel like the more you investigate the topic the more difficult it is to choose the best approach for specific needs. I plan to discuss such choice dilemmas too in Part 2, stay tuned!

Posted in deferred shading, light pre-pass, rendering | 9 Comments