If you search on the internet there’s heaps of libraries that make the process of binding of various scripting languages with C++ easier – check out this for lua or this for Squirrel binding options.

So, why I did I make another one? The first reason was I wanted to learn more about scripting languages and the second one was I wanted the same interface for use with all languages to be able to easily switch between them.

C++ library

The result of all that is my MultiScript library that:

• allows script code to access C++ classes and functions and
• allows C++ code to access script functions

The library has a very simple C++ interface with 4 different implementations for the following languages:

• Lua
• Squirrel
• Game Monkey
• Ocaml (no binding of classes as this isn’t easily doable with Ocaml vm)

The interface itself consists of:

• ScriptContext – responsible for maintaining script execution context; registers classes and functions
• ScriptStack – used to handle function calls including pushing and popping values on stack
• ScriptObject – base C++ class for objects to be visible from script
• ClassDesc, FunctionDesc etc. – helper structs used to describe classes and functions to be registered

The library comes with a simple test project that runs test programs for all languages and prints out their output along with some statistics. The source code of all these languages is included.

Ocaml

Ocaml binding implementation deserves separate paragraph or two as it wasn’t as straightforward as I had hoped originally and I ended up modifying source code of the Ocaml VM (virtual machine) so I could easily load-from-string and run multiple times a chunk of Ocaml code as well as dynamically register C++ functions with Ocaml runtime. Apparently Ocaml VM wasn’t meant to be used as an embedded scripting language the way Lua is.

Binding C++ classes would most likely require a lot more work to get done, so I gave up on that. All of the modifications are clearly marked with “msawitus” in the comments.

In order to be able to run Ocaml tests you have to install Ocaml binary distribution from Inria download site. It is necessary to compile (not execute) Ocaml code.

Summary

Implementation for both Lua and Squirrel are very similar – after all Squirrel is heavily based on Lua. Getting my head around Lua concepts required a little bit of effort at first but it was straightforward after all. Game Monkey binding was straightforward to do from the very beginning, even without docs and Ocaml was a bit of trial and error experimentation.

I should also point out that this was just an experimental project and it’s nowhere near production quality code. But it’s probably worth looking at if you’re wondering which scripting language to choose for your next project.

Project source code is hosted here.

Download: Source and Binary

Example usage:

NaiveIncludeOptimizer.exe “C:/Program Files (x86)/Microsoft Visual Studio 11.0/Common7/IDE/devenv.exe” “C:/my_project/my_project.sln” “Debug” “C:/my_project/src”

Example output:

Optimizing Main.cpp...
    Redundant #include External.h
    Redundant #include Misc.h
Optimizing Misc.cpp...
    Redundant #include Common.h
    Redundant #include API.h
    Redundant #include Defines.h
DONE!

The way it works is very brute force (hence the “Naive” in the name) meaning it tests every #include individually to see if the solution would still build if it was removed. So, yes, that means larger projects may even take days to process! But in the end it does work (mostly – see below when it doesn’t).

Be careful because it does modify the source code. But while doing so, it always creates a backup copy. Bonus feature is that it is capable of resuming from where it stopped last time.

Also, please note that it only optimizes .cpp files. Optimizing .h files would obviously take a lot longer!

I should also point out that the proper way of doing this would be implementing full blown C++ preprocessor that would include:

* removing redundant #includes

* adding forward declares where possible

* making sure that the actual code generated does not change (my solution may result in some undesired program “optimizations” – e.g. by removing #include “my_new_operators.h” the definition of your new/delete operators might change but the project would still build successfully)

It’s obviously a lot more work but fortunately that’s exactly how Google’s Include-What-You-Use is meant to work. I haven’t tried it but it looks neat.

But fortunately they’re not totally gone as I decided to put a link to Monstaaa! for Android on my site. All you have to do is download and install it on your android device. And if you don’t know how you can do it, read this article: 3 ways to install applications on android without market. The game has in-app purchase to unlock second part of the game but that is obviously not working now that the game is not on Google Play anymore. Anyway, have fun

Download: Monstaaa! Android

Meanwhile, Puzzled Rabbit for Android, Blackberry PlayBook, XBLIG and PC is still available.

iOS versions of both games are gone for good now that I removed my developer account on iOS. And unlike with Android version, self-distributing iOS executable does not even make sense (assuming one would like to install and play it legally).

Apparently indie game development, in particular on mobile platforms, is really tough these days. The way I see things is that iOS / Android gold rush is gone and it’s now incredibly difficult to compete when you’re a small developer because in order to succeed you not only need an exceptionally good, original and polished game but you also need to be visible on the market. And that takes a lot of hard work, talent and some luck too.

Finally I have to say that I am really glad I tried indie game development as I would otherwise not fully understand why it is so difficult and would probably regret not having tried it. I have also learned a lot and had a really good time while it lasted. If you want to learn more about my 10 month long indie adventure have a look at my past blog posts and try to learn something from it.

iOS and Android game development on Windows

Monstaaa! for iOS – the first announcement

Monstaaa! development summary – part 1

Monstaaa! development summary – part 2

How I sold 22 copies of my game in 3 weeks on Android

But before that let’s have a look at some of the most common uses of RTTI in games. In fact they are not much, if at all, different from any other, non-game related, project.

(a) Run-time type checking and instancing.

Being able to check what’s the actual class of an object is often useful functionality for gameplay programmers:

bool Object::InstanceOf(Class* _class) const;

Another useful feature is ability to instantiate an object knowing its class name:

Class* ClassManager::FindClassByName(const char* className);

Object* Class::CreateInstance();

To implement above basic RTTI functionality, we’re usually required to derive all of our game classes from some base Object class. Supporting multi-inheritance is possible but typically avoided because in most cases it’s just not needed but would make things a lot more complex otherwise.

Reality Prime’s dev blog shows basic implementation of such RTTI system.

(b) Automatic serialization of objects and their attributes.

Instead of implementing custom Read() / Write() methods for each class where every property is manually processed, we can now (with RTTI system in place) implement generic Read() and Write() methods that will work for all classes. Alternatively we can write single Serialize(Serializer&) method that would either read or write (or do other things) depending on implementation of Serializer.

But while this feature sounds great it has one serious downside – very limited support for data versioning. Imagine one day you decide to change some ‘int m_Name‘ attribute into ‘String m_Name‘ attribute. How would you want your game to load the old data and convert into new format? Would you want to perform some kind of ‘offline’ conversion by running hacked version of the game over all of the data? If so, you’d have to do so for all of the relevant game data files at once. In a big team working on a game that is obviously a challenge because the person performing conversion must assure no one else has got any important local changes on their PC.

Or even worse, suppose your game has already been released and there’s tons of content (e.g. levels, quests, puzzles) created by the community. Simply changing the format of the data expected by an updated game executable would break all of that content unless you provide way to convert from the old format into new one.

To some extent this upgrade process can be automated as demonstrated by Insomniacs (unfortunately, to my knowledge, the actual explanation of that can only be found in GDC slides or articles in paid magazines). Their system of lazy upgrade script evaluation assures that every asset you get from asset database is always in latest format.

Having said all that I should point out that some projects don’t need robust data versioning at all and therefore may well benefit from automatic serialization. This is especially true for small projects without support for community created content.

(c) Game editor integration

Another great benefit of RTTI is that it allows class attributes to be automatically exposed for editing within some kind of visual editor. This feature may require additional editor specific attributes to control how each particular type shall be edited. For example you may want to have nice color selection control instead of having to manually type in individual RGB values; or you may want to limit min and max values of fog intensity by 0..1 range, etc.

This best works with WYSIWYG game editors which for the purpose of editing use the same C++ classes as the ones used in the game. There’s no need for intermediate communication layer and every editing action changes the game object directly. As with anything, this has some advantages (mainly easier and cleaner implementation) as well as disadvantages (less efficient and editor-polluted run-time code).

Manual serialization

A well known example of an engine that supports features listed in all above points is Unreal Engine 3. As for the automatic serialization, it only does so for Unreal Script classes. For their C++ classes they use more “manual” method which does make a lot of sense because it allows for a flexible data format versioning. Here’s sample code that demonstrates mentioned “manual” method:

// Deserializes instance of Dog class
void Dog::Read(Reader& reader)
{
    // Deserializes all base class attributes
    Super::Read(reader);

    // Read name value
    reader >> m_Name;

    // Read color value; only if data has it (old version didn't)
    if (reader.GetDataVersion() >= ENGINE_VER_DOG_ADDED_COLOR)
        reader >> m_Color;

    // Read height value; only if data has it (old version didn't)
    if (reader.GetDataVersion() >= ENGINE_VER_DOG_ADDED_HEIGHT)
        reader >> m_Height;
}

Implementing automatic serialization that would handle all kinds of data versioning correctly is not possible simply because it’s only programmers who know how data changes between versions. The major limitations of the automatic serialization are as follows:

• only simple type conversion handled correctly (e.g. int into float)
• name changes cause new property to be added and the old one to be removed (thus losing the data)

On the other hand, by manually handling data upgrades, one has full control over data conversion.

Type information generation methods.

We now know why RTTI might be useful. But how do we create it? Again, there’s at least a couple of ways – from manual intrusive macro/template based ones to automatic offline ones.

(a) Manual intrusive macro/template based method.

One very popular way of creating RTTI in C++ is by adding a couple of special macros and functions to every class. This may look something like this:

Header file:

// Sample Dog class
class Dog : public Animal
{
         // Tells RTTI that Dog inherits from Animal
         // Also defines some helper functions
    RTTI_DECLARE_CLASS(Dog, Animal)
private:
    int m_Height;    // Dog height
    String m_Name;   // Dog name
};

Source file:

// Function declared in RTTI_DECLARE_CLASS macro
// Adds all attributes to class RTTI
void Dog::RTTI_InitAttributes()
{
    // Initializes m_Height attribute; figures out type using templates
    RTTI_INIT_ATTRIBUTE(m_Height);

    // Initializes m_Name attribute; figures out type using templates
    RTTI_INIT_ATTRIBUTE(m_Name);
}

The actual initialization of each class is best done manually – something like this:

void InitMyClasses()
{
    Object::RTTI_Init();
        Animal::RTTI_Init();
            Dog::RTTI_Init();
            Cat::RTTI_Init();
    [...]
}

To keep things short I’m going to skip implementation of RTTI_DECLARE_CLASS and RTTI_INIT_ATTRIBUTE macros. The nice thing about attribute registration is that using C++ template specialization it’s totally possible to automatically deduce type from a variable – this is useful because it means you can initialize all attributes with call to the same RTTI_INIT_ATTRIBUTE macro.

The major downside of this approach is that the programmer needs to maintain an up-to-date RTTI initialization code. With the help of automatic attribute type deduction and some C++ macro magic, this can be made safe and less inconvenient but it’s still not perfect.

(b) Automatic – parser based.

One totally different approach to building RTTI information is by generating it offline and storing it in a file which is then loaded by run-time. There’s plenty of C++ code parsers available (e.g. Wave or GCCXML) available which you could use but there’s still some coding required in order to extract selected types for RTTI purposes. You’d also need to integrate C++ parsing step with your project building, so it wouldn’t need to be done manually.

One issue with this approach is that the RTTI data generated during preprocessing step might potentially differ between project configurations / platforms. But since gameplay code is typically platform and configuration independent this is probably a very minor issue.

The nice thing about this approach is that, provided parser can extract comments attached to particular class or attribute, it’s possible to use comment based custom annotation language on a per class or attribute basis. This can be useful in a couple of different scenarios including when you want to mark some attributes as serializable or when you’d like RTTI for a specific C++ class not to be generated at all. Annotation technique is something that is widely used in other languages such as Java or C#.

(c) Automatic – debug info based.

Yet another approach to building RTTI information is by extracting it straight from debugging information files such PDB on Windows as described on Maciej Sinilo’s dev blog. It is a very similar method to the one presented before but one small advantage of it is one doesn’t need to implement an additional parsing step themself which, depending on how easy parses integration is, might save a lot of work.

Summary

As it often happens, there’s no best solution that would fit all projects. Every game is different and there’s games that don’t need RTTI at all.

For larger game projects with heaps of gameplay editing involved I’m leaning towards Unreal Engine 3 approach i.e. manual RTTI including manual serialization on the C++ side and automatic RTTI with automatic serialization on the scripting side (assuming there is one). Many popular scripting languages already have full reflection support in place which makes things easier there.

For projects where WYSIWYG editing isn’t priority, full blown RTTI system with attribute level information may not be necessary at all. Even more so with projects where in-place serialization (one block of memory used for multiple objects) is being done making it mostly redundant to maintain any kind of attribute information at run-time.

Free on Android, paid on iOS

It’s been 3 weeks since Monstaaa! release on Android via Google Play, so I thought it’s high time I share some more statistics. In fact they’ve been rather shocking – in a negative way, unfortunately – when it comes to the actual revenues given great reviews (average around 4/5), very positive general feedback, high ratings from users (average around 4.5/5) and higher than with iOS number of downloads (over 10k). Apparently, Android turned out to be a very tough market for Monstaaa!

Keep in mind though that unlike iOS version which is paid at $0.99, Android version is Free with $0.99 in-app purchase that unlocks full game. According to my statistics, Android version has been played on more devices than iOS version and yet the sales have been roughly 50 times lower! Part of the reason for that surely was the fact that iOS version has been featured for one week by Apple themselves in New & Noteworthy (only Australia and New Zealand though!) whereas Android version hasn’t been mentioned anywhere at Google Play. Besides iOS version had a lot more reviews on gaming portals – probably result of me pushing a bit more with marketing when iOS version came out.

The thinking behind making the game free on Android was that Android users are, supposedly, less likely to pay up front without trying an app first. That was my guess at least. With Android release I also wanted to experiment with a different than pure paid app model.

Android statistics

Okay, so, let’s have a look at some actual Android numbers now.

Total number of installations/devices: 11135 (1599 installations via Google Play)
Total number of users who finished all 8 levels in free version: 2281 (20.5% of all users – not too bad!)

Total number of different device types: 1133 (seems a lot to me!)
And here’s more detailed breakdown of the device types:

Quite a fragmented market, isn’t it? As you can see, the most popular Android device so far has been Samsung Galaxy II (791 devices), then MI-One Plus (410 devices; popular in China), then Samsung Galaxy Ace (347 devices).

Here I shall also point out that even though the game is officially only available via Google Play, over 80% of all downloads have been made through other portals – this is quite common in the world of Android. Since the game is free, this doesn’t hurt at all (as opposed to paid apps which are just being pirated this way). That’s all based on the stats I get to see from within Google Play admin panel itself compared with my own stats collected from the game directly.

Let’s now have a look at the number of users and new users per hour over last 3 weeks:

Clearly, the game had its popularity peak at the end of the first week. Since then there’s been gradual decrease in both, users and new users counts. The peak in downloads most likely corresponds with some, very positive, reviews from iDroidPlay and AndroidZoom as well as “App of the Day” featuring by the latter.

Android and iOS sales

If you read the title of this post you already know – the full game has been purchased exactly 22 times! That’s right! With over 10k downloads, there have only been 22 purchases made on Google Play.

And with iOS, even though things look much better there, sales are still far from satisfying. Over first 2 months the game still hasn’t even reached $1k in net revenues with no more than $5 a day being made nowadays. With 7 months worth of development, even for a single developer, this obviously won’t pay the bills. Well, it won’t even cover basic out of pocket development costs!

Confusion

What’s the reasons for such poor Android sales? Too many levels in free versions? Too high difficulty level? Lack of additional in-app purchases / items in game? Oversaturated market when it comes to physics based puzzle games? Should it be made paid like on iOS? Or is it just lack of luck? I really wish I knew and I’d be really glad to hear others’ opinions!

Sometimes I feel like the more I try to understand things, the worse the actual results are. At least with Android that is the case. And probably the most confusing for me is the fact that the game had many really good reviews and has been mentioned but a number of prominent gaming portals or blogs. No review to this date (except for one) points out any significant flaws with Monstaaa! which I think suggests there isn’t any obvious issue there. In fact most of reviews highlight the good things about the game – things like good graphics and audio, fun game-play or well done tilt controls.

Here’s few game reviews if you want to check them yourself:
148 Apps
iFanzine
GigaOm
AppsOnTapp
PadVance
AusGamers

Ironically, if the reviews were bad it would have been much easier for me to understand the problem!

And it’s even more confusing when you realize that over 20% of all users complete the whole demo version – this I believe is quite a large percentage. And yet, only less than 1.0% of these users unlock the full game.

Summary

But let’s not be too pessimistic! How many game devs succeed with their first or second game? Of course it’s a dream of every developer that their first game is success big enough so they can comfortably work on another one but one has to be realistic and the reality is that only very few succeed straight away.

My experiment with indie game development hasn’t worked out financially so far but I didn’t even spend a year on it and, fortunately, I also didn’t spend too much money on it. By making and releasing two games I learned a lot about mobile game development and I do plan to try again in some future! In the “meantime” I’m going back to more stable life joining one Electronic Arts studio in Melbourne which I’m sure will be another exciting chapter on my game development adventure!

The best resource I found was the following series of tutorials: Beginning iCloud in iOS 5. It is does explain well the basics of iCloud usage but unfortunately it doesn’t go as far as implementing iCloud conflict resolution – something that is strictly required if you’re seriously considering using iCloud for your game. Besides, Apple doesn’t make it easy for you either to understand how one is supposed to implement it.

The small library that I implemented handles all that is needed for a simple game savegame i.e. creation & writing to iCloud file, reading from iCloud file and, very importantly, iCloud file conflict resolution. The library has been implemented as an extension for Marmalade SDK (cross platform mobile development SDK) but if you don’t use it, don’t worry, it is fairly trivial to make it stand-alone library.

The library has C++ interface but the majority of the code is in Objective-C. You can get it from github: https://github.com/macieks/s3eIOSiCloud If you just want to see the _code_ or don’t use Marmalade SDK check these source and header files.

The basic idea behind the library is you store your savegame both locally (on the device) and remotely (in iCloud). The reason we always store local savegame version is quite obvious – if an app fails to connect to iCloud for any reason, you won’t just lose the progress. Once iCloud becomes available again, we then connect back to it and, optionally, resolve conflicts that occurred in the meantime due to savegames done on other devices.

The library notifies the app whenever it has successfully read the file or whenever conflict has been detected. It’s then up to the app to resolve the conflicts and merge remote with local savegame. The callback in both cases is exactly the same – the app is given the data (i.e. void* data and int size) to merge with and that’s it. The actual merging operation is application specific – every game will merge differently. And just to make sure everything is well explained here, what I mean by merging is making one out of two different savegames. Let’s say the player has completed levels 1,2,3 on their iPhone and levels 2,4,5 on their iPad – the resulting merged savegame should contain information about levels 1,2,3,4,5 being completed.

Here’s quick intro on how to use the code. MySaveGame struct represents sample savegame with boolean values indicating which levels have been completed and MyMergeFunc is the merge callback registered with the library.

#include "s3eIOSiCloud.h"

#define NUM_LEVELS 100

struct MySaveGame
{
	bool m_completedLevels[NUM_LEVELS];
};

MySaveGame localSaveGame;

int MyMergeFunc(void* systemData, void*)
{
	s3eIOSiCloudDataToMergeWith* data =
            (s3eIOSiCloudDataToMergeWith*) systemData;
        MySaveGame* remoteSaveGame = (MySaveGame*) data->m_data;

	// Merge remote and local savegames

        for (int i = 0; i < NUM_LEVELS; i++)
             if (remoteSaveGame->m_completedLevels[i])
                localSaveGame.m_completedLevels[i] = true;

	// Store savegame locally (fopen / fwrite / fclose)

	bool savedLocally = [...]

	// Return success or failure to iCloud library

	return savedLocally ? 0 : 1;
}

The callback gets the data to merge with, performs app specific merging operation and then stores the savegame locally.

Let’s now initialize iCloud for “my_save_game.txt” file:

s3eIOSiCloudRegister(S3E_IOSICLOUD_CALLBACK_MERGE, MyMergeFunc,0);
s3eIOSiCloudStart("my_save_game.txt", S3E_TRUE);

The code above registers merge callback, then starts iCloud service for a specific file.

To make sure read and write operations are being retried internally, simply do this every frame:

s3eIOSiCloudTick();

And finally, to store savegame in iCloud do this:

s3eIOSiCloudWrite(&localSaveGame, sizeof(MySaveGame));

Now, as I said, if you want to use the code but you don’t use Marmalade you should easily be able to get rid of Marmalade specific code – mostly message logging and callback handling. There’s no heavy Marmalade dependencies anywhere.

Finally, to make you feel better about the library I’m just going to say that it’s been already successfully used by two of my iOS games – Monstaaa! and Puzzled Rabbit.

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 148Apps, 4.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.

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!

Technology

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.

Cheers!

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:

And here’s preview trailer:

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

Cheers!

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.

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)

Pros:

• 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:

Pros:

• 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

Cons:

• 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
• iOS and Android only (well, this isn’t that big limitation but still)
• 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!