SuperSoko Screenshot

For my first Game In A Day project I chose to implement a version of Sokoban as I hoped it would be relatively simple to write and would give me a good chance of actually completing something by the end of the day. Using an existing game design also meant I didn’t have to worry about coming up with a sensible design of my own, which gave me time to concentrate on the technical issues at hand.

I wanted to try writing something using the Cocos2D-X library as it seemed like a neat game development library with a lot of features. It also has close connections with the iPhone, so could be a way in to iPhone development for someone like myself who has a PC, rather than Mac background.

This may have been a slightly ambitious choice as my experience of Cocos2D-X was limited to having followed the basic tutorial that it comes with and adding in a few little extra features of my own. However, I’m comfortable with C++ development, so although the library is large and complicated, this helped a lot.

Total development time for this project was just under 12 hours. I had hoped to simply drop in some free graphics to add as placeholders but found that I ended up spending quite a bit of time choosing graphics (from Daniel Cook’s excellent free texture set) and assembling them into spritesheets and a background screen. I also spent time creating the box and arrow graphics myself after giving up on trawling through free online image resources.

Drawing up the level using a tile map in Tiled Map Editor went fairly smoothly. For most of the day I used a very simple test map, which I replaced in the last hour with a real-life level from the original Sokoban game. I would have liked to have added more levels to the game, as I think this is one of the few things that currently make it less viable as a “real” game. The time constraint meant that I didn’t get round to this.

Sound effects were a last-minute addition to the game, as I knew I’d be able to implement them very quickly. I used sfxr to generate them and really should have spent a little more time on getting the sounds right as the current ones are very annoying. There are actually two different sounds - one for walking and a slightly heavier one for pushing.

Logic for the game is very simple, so I didn’t end up spending much time debugging. I already knew some of the pitfalls of Cocos2D-X, especially the fact it puts the origin for its coordinate system in the bottom left corner. However, I did have to do a fair amount of research to work out how to use the Cocos2D-X features that weren’t so well covered in the tutorial, such as using the CCMutableArray and CCStringToStringDictionary. I’d much rather use the existing C++ STL tools which are very well written and that everyone already knows how to use.

Messing about trying to get fonts to display on screen also cost me a lot of time. I even managed to get Cocos to crash when changing the labels on True Type Fonts. I ended up going through all three different font types to get something working on screen. I gave up on creating a clickable menu label for the Restart button and instead made a graphic label in a bitmap editor.

Given time I’m sure I could easily sort these kinds of problems out, but my priority for this project was to produce good enough working code, not perfection. This means that the maintainability of the project wouldn’t be great. I attempted some OO design with my Player class but it ended up hindering more than helping. In a bigger project it would be a benefit, although I’d need to learn how to do it properly with Cocos2D. There is some code duplication, which usually isn’t a good sign. It’s impressive how quickly a simple project can grow into something wild and unruly if you let it.

I was very pleased with the Cocos2D-X coding “model” - being able to create Actions and tell the system to go away and run them is fantastic. Very like something one might write in Flash/ActionScript. For the heck of it I set up an action to scale the game logo once every 10 seconds.

I also used Actions to create player movement. This means there’s no need to keep track of what is moving. When the code needs to move something it sets up all of the actions at once (eg rotate player to face direction, move player and move box) then considers it done. The only per-frame update actions the code does is to check the keyboard to see if the player wants to move. Everything else is done behind the scenes.

Given more time I’d like to explore the Actions further, especially the Easing actions which make movement far more realistic. I’d also like to create some particle effects to see how they come out.

A minor wrinkle is that the finished exe would only run if it was in the same directory as the resources. This makes the installation of the game very messy. For some reason this didn’t happen when running from the compiler. Again, easily fixable, but something I only noticed after my self-imposed deadline was up.

The two project files where I put most of my code add up to exactly 500 lines of code. Over many years of coding and noting my line counts this is about what I expected to see, which is gratifying. I’d expect my Daily Lines of Code stats to be lower on a bigger project where a lot more time would be spent working with existing code, rather than creating from scratch.


I’m very pleased with the way this project turned out. Although it isn’t the most complicated game ever, it has most of the features it needs to be considered a playable game. I learned a lot from writing it and best of all, the whole thing only took a single day to put together.

SuperSoko runs on Windows 7 and you can download it here.

You can download the source code here.