User's corner: Go Usagi!
Daniel Sperl on November 10, 2010
This blog post is from Daniele Zannotti, one of the creators of “Go Usagi!”, an innovative puzzle game for iOS. A few days ago, I asked him if he had time to write a few words about his experience with Sparrow and iOS in general. Thankfully, he agreed and wrote the article below. I’m sure it will be interesting for all Sparrow developers!
It would be great if we could make the “User’s corner” a regular feature on the Sparrow blog. So if you’ve just released an interesting game or have other things to say that are at least remotely connected to Sparrow, don’t hesitate to contact us!**
Who are you?
Hello everyone! My name is Daniele Zannotti and I’m the coder of “Go usagi!”. I’ve been a professional programmer for about 10 years now, and in my spare time I still do programming for my own little projects. I would like to tell you the story behind “Go usagi!” and Sparrow.
Go Usagi!
Go Usagi! is a puzzle game available on the App Store in two versions (a free version with nine levels and a full version with 36 levels for 1.99 USD). It was developed during weekends and -nights (yes, I do have a day-job that does not involve iPhone programming). The concept is really simple: there’s a grid with obstacles and a strict rule of movement, and a user interface to alter that rule. The main character, the Usagi, is a rabbit. Faced with a wall, he turns right; if he can’t go that way, he turns left; if he can’t go that way either, he turns around. The game itself is not very challenging to code, but it’s very challenging to play! The smooth difficulty curve and a star rating system should keep the users entertained for a while. It is my first game using Sparrow and my first game on App Store in general.
The role that Sparrow played
I am very strict on not needing to reinvent the wheel, which is why before writing my own framework I started looking around if there was one that would match my needs. I was very unexperienced (and still am) on iDevices development - but being a long time programmer, I always approach different and new languages as just a little more than syntax changes.
My requirements where:
- Free for commercial applications
- Easy to use
- Open Source
- Would mask the need to learn the iOS API with a clear wrapper around them
I intended to create commercial as well as free applications, so I wanted a framework that would give me that possibility without paying. It had to be easy to use, because it was my first Objective-C software, and Open Source so I could modify it if some feature was not up to my needs. The last point is self explanatory: I still don’t know and don’t want to know Cocoa APIs. I’m interested into developing the game itself, not battling with an API to get what I want out of it.
After googling a few hours, I was left with 2 alternatives: Cocos2d and Sparrow. I downloaded them both and started browsing the code and the examples. My personal view looking at Cocos2d was and still is that it’s sometimes confusing and over-engineered (some simple things take many lines of code). However, when I started looking at the Sparrow demo I was pleasantly surprised at how clear the source code was. My first thought was like “hey, I’ve never seen this before but I can understand it and use it right away!” The decision was made, Sparrow here I come! As side note, please don’t misunderstand me: I’m aware that Cocos2d is a very solid framework with a lot of successful games under the belt. I’m not dissing it nor trying to put you off it - it just wasn’t right for me!
Obstacles along the way
The biggest obstacle to overcome during development was memory management. I knew nothing about it beforehand, but I eventually got over it. The second biggest obstacle to get over has been that Sparrow provides a hierarchical structure for drawing, while I needed a Y-based drawing to achieve the isometric effect. All of this was fairly easy to do in Sparrow with a little bit of tinkering. In my case this was achieved by creating a number of SPSprite containers added to the stage in a particular order, and then changing the container content based on the y-coordinate in each frame. Works like a charm!
The big feature and the big RAM problem
I only own an iPad as iDevice so it has been my development testbed during the whole development. Whenever I was happy the way it worked on the simulator, I tested my progress on the iPad.
There was one particular feature I wanted to have in the game: HD graphics and “almost full screen” on the iPad. That was something that I had seen in “Trainyard” by Matt Rix. The average iPhone application looks awful on the iPad when you press the 2x zoom-button, because the pixels are just stretched to twice the size. Matt came up with the idea of forcing HD textures on the iPad, so that it runs in full resolution, even though it is a normal iPhone app. This feature was not supported by Sparrow, so I started digging the source code while I made a post on the forum requesting help on the subject.
I managed to load the HD textures myself - but they were not displayed correclty. Here is when I discovered why Sparrow really stands out: its community. Sparrow’s author Daniel and the forum community have been GREAT to help out. Not only did they spend a lot of time just for the sake of it and for a thanks, but I’ve NEVER seen a user addressing the other with the “you are a noob!” tone. Everyone is fantastically friendly and gives you their point of view, suggestions, pieces of code, etc. This experience has been AMAZING for me, and I’m still trying to pay the community back by helping other users on forum where I can. Back to the game: with the help of Daniel the HD support on iPad was done! (That feature is not in the current Sparrow version - visit the forum to find out how to implement it.)
So I was happy that all was working and went on finishing the game and implementing a tutorial mode. Then I ran it on the iPad and … crash! This was very disappointing, and I surely was not ready for what came next. The reason for the crash was that the iPad has only half of the RAM of the iPhone4 - hence, it was struggling to deal with the amount of RAM used by the HD graphics of “Go Usagi!”.
The game loads all content on start-up during a loading screen so that everything runs smoothly, without additional loading times (I hate it when games let players wait). This was a major feature of “Go Usagi!” - I couldn’t cut it out! Once more, I asked the community for help and time on that matter. A “sorry guys i wasted your time” would have been shameful for me. In Italy we say “you wanted to go by bike, now push the pedals”, which means literally “you wanted something so badly, now deal with it”, so I did. I started rewriting most of the code, not only looking for leaks but mostly to limit the RAM usage. Here, Sparrow’s blog was a great help, the texture atlas posts were good enough for me to motivate me to learn more about the matter and to implement one. Unfortunately, it was still not enough. I’m not going into details how I ended up fixing it, because I don’t want to bore you, but feel free to drop me an email if you are stuck in the same situation and require help, be my guest! However, all that matters is that in the end, it was solved and the game is running!
Conclusion
Sparrow has been a great friend for me. It allowed me to develop directly and in a very easy and quick way, while its community has been superior to any other forum communities I’ve ever seen. If you are looking for a framework to develop 2D games on iDevices and you don’t want to bother learning the Cocos or iOS APIs, but focus just on your game instead (which is what everybody should do), I suggest Sparrow as your FIRST choice. My respect goes once more to Daniel and Holger for this amazing product, but mostly for all the effort they put into this project and its community - because if the community is so friendly, it’s entirely based on their driving of it.
