Development Notes: Zephyr Touch
Apr 9
2013
My first iPad game, Zephyr Touch, was released on the App Store last week.
I’ve wanted to make a game for the iPad since it was first announced. I’ve been learning bits of Objective-C development here and there for a couple of years. I even have a few small apps under my belt, but making a full-fledged game on iOS has always seemed too intimidating. I finally decided that I needed to just buckle down and make a complete game — no matter how simple — so I could begin to learn the process and build up my skills.
Choosing a Game
Since this would be my first game for iOS, I figured it would be easiest to start with a game that’s already complete and port it to the new platform, rather than try to build something from scratch.
I have quite a few games in my archive to choose from. Luckily, I’ve focused almost exclusively on small casual games that feel well-suited for the iOS platform and are not terribly difficult to develop. That being said, all of my games are designed to be played with a mouse and keyboard, not a touch screen. I identified some games that would work better on a touch screen than others, but one in particular stood out. When completed my Ludum Dare 23 entry, Zephyr, more than one person commented on how well it work on a touch screen. Zephyr had another thing going for it as well: it is a very simple game (it was made over the course of a weekend after all). The perfect game for me to try my hand at iOS game development!
Choosing a Framework
Coming from a Flash background, I was immediately drawn to the Sparrow framework because of its Flash-like API.
I briefly considered trying to build the game using Starling/Adobe AIR for iOS, but then I remembered the wasted afternoon I spent just trying to get a Hello World app to run on my iPad through AIR for iOS. Developing for iOS already involves enough voodoo without adding another layer of hassles to go through.
I also considered Cocos2d. I’ve read a bit about it, and it seems to be a very competent and well-maintained framework. There are a few things about it that seem less than ideal (the coordinate system for example) that made me shy away from it.
So I ultimately chose to go with Sparrow, and I think it was the right choice for me. I figure after I make a few games and get some more experience I can re-evaluate the available frameworks with a more educated eye.
Technical Challenges
Considering I was learning a new framework API, and working in an unfamiliar language, I had surprisingly few major technical problems.
One hangup I ran into was getting the game to launch in the proper orientation. One of the major downsides to working with a framework (any framework) is not knowing if a bug is being caused by my code, or something in the framework. Searching for the problem online led me to many others who had similar problems, but none of the suggested solutions worked for me. I eventually got it to a state where it works most of the time. On iOS 5, the game still sometimes launches upside down for a half second before correcting itself. I think that’s the best I can do. Hopefully the newly-released Sparrow 2.0 has a fix for this issue.
I ran into another issue just when I was thinking I was almost done with the game: I needed to actually save the user’s game state if they quit or were interrupted while a game was in progress. Coming from Flash games, I’d never had to deal with that before. I figured out how to save the game’s object graph using the NSCoding protocol, which is a pretty neat little feature. Ben Scheirman has a nice short introduction to NSCoding on his NSScreencast site that got me started pretty quickly.
Gameplay Challenges
Since Zephyr Touch is based on an existing game, I didn’t have to struggle with very many gameplay issues. I did have to adjust the game for the larger screen. This meant tweaking the speed of the sprites and the power of the fan in order to get the same feeling as the original game.
One issue did come up that I wasn’t expecting. Controlling the fan with a finger ends up being quite a bit different than using the mouse. In the Flash version, the fan follows your mouse wherever you move it, but in the touch version the fan only appears when your finger is actually touching the screen. This means that moving the fan from one side of the screen to the other is quite a bit different in the two versions. In the Flash game, the fan follows your mouse across the screen, blowing around any sprites that might be in that path. In the touch version, the fan simply disappears and reappears on the other side of the screen. It’s not a huge issue, but it’s interesting to note as something that didn’t even occur to me until I started playtesting the touch version.
I wonder how other games might be affected by switching to a touch interface.
Conclusion
Overall, I am happy with the game and I’m glad I went through the process to bring this game to iOS. It was a very valuable experience.
That being said, I know the game itself is not great. It very much has the shallow feeling of a game that was developed in a weekend (go figure). I did consider spending more time to improve the game (adding more visual effects, levels, more depth, etc) but I ultimately decided to keep it the same as the original for now and to focus my efforts on building a new game from scratch.
