In this post I’ll summarize the primary technology choices for the project
Before we can actually start coding, we need to make a few technology choices for various aspects of the project. Specifically, we have to decide on the following things: deployment targets, development language and environment, physics engine, scripting engine, and graphics and rendering subsystem.
Deployment targets
The deployment target will be iOS 7 and up, and the intention is to support both iPhone and iPad as target devices. I’ve considered giving Android development a shot, but quickly abandoned that idea. The fact that I’d probably end up writing mostly Java code and would have to use the Android emulator since I don’t own any Android devices, it just doesn’t really resonate with me. I don’t have any Windows PC’s or Windows Phone devices, so that’s out as well. An OS X or Linux desktop version could be an interesting option later on, but initially it will be somewhere near the bottom of my list of priorities.
Development language and environment
The development language and environment more or less follows as a corollary of the choice to deploy to iOS targets. Unless you like to make things unnecessarily hard for yourself, iOS development means Objective-C and XCode, so that’s what we’ll be doing. I’m not particularly bothered to be stuck with Objective-C, in fact I quite like it as a development language. I’ve written my fair share of C, Objective-C, C++, Java and Python, and I can honestly say Objective-C and Python rank highest in terms of productivity and fun.
I’ll be using the most recent versions of OS X, XCode and Objective-C, which means I can use all recently added Objective-C language features, including properties, blocks, Automatic Reference Counting, literals and array/dictionary subscripting.
Physics engine
The game physics will be handled by Box2D, a proven, stable and well-documented 2D physics engine used in many games. Box2D is written in C++, which allows relatively straightforward integration in Objective-C projects. Obviously a physics engine with a native Objective-C API would be even nicer, but I’m not aware of one that provides all desired features. Apple included 2D physics simulation capabilities into iOS 7 through SpriteKit, but judging from this analysis it appears to lack a few possibly important features, and trails Box2D in performance and flexibility.
A few other physics engines exist that could be worth considering, but they all have their own downsides. Based on Box2D, there’s Chipmunk which has the benefit of a native Objective-C API, but lacks continuous collision detection, a feature that will likely come in very handy for the game we’re making. Also based on Box2D is Farseer, which looks like a modernized Box2D port with added features and an easier to use API, but unfortunately it’s written in C# and targeted primarily for Windows-based platforms. Similarly, there’s Nape, but it’s for ActionScript (Flash). Then there’s quite a few 3D physics engines such as Bullet, Tokamak and ODE, but since we’re only interested in simulating 2D physics, these are probably unnecessarily complicated and less efficient compared to using a 2D physics engine.
Scripting language
Choosing a scripting language is pretty straightforward: the de facto, lingua-franca, go-to scripting language for almost any kind of project that doesn’t run on top of a Java Virtual Machine is Lua, which isn’t surprising because it ticks all the boxes: it’s fast, lightweight, specifically written to be embeddable in C-style projects, well documented, and battle tested. The list of games using Lua is long, and contains AAA titles such as World of Warcraft and Civilization V, so I guess it should be suitable for our humble game as well ;-)
Rendering subsystem
For the rendering subsystem, we have quite a few choices. The game visuals we want to realize are simple enough to stay completely within the confines of Apple’s Cocoa framework, drawing paths to bitmaps and using CoreGraphics and CoreAnimation to get them to the screen. Apple introduced a sprite API named SpriteKit with iOS 7, which even contains a Box2D-derived physics engine, so practically speaking it should have everything we need.
Another very usable option would be Cocos2D, an excellent sprite-based graphics and animation framework. I used Cocos2D for my previous game Snipes! and found it to be an excellent all-round, complete and extremely accessible framework. Cocos2D also integrates very well with the Chipmunk and Box2D physics engines, provides API’s for animations and various graphical effects, and it allows lower-level rendering using OpenGL ES 2 shaders.
My initial idea was to simply use Cocos2D again, as it provides everything required and I already have first-hand experience using it. I ruled out using just Cocoa and CoreGraphics/CoreAnimation because I expect that the resulting rendering code would end up slower, less flexible and less portable to non-Apple platforms (should this ever become relevant). If development effort and risk were of any concern, going with a framework such as Cocos2D would be a no-brainer. I decided to add a little extra challenge to the project though ;-)
Instead of relying on well-tested, stable and easily accessible third-party frameworks, I have set my mind on writing the rendering engine of the game using (presumably) the lowest-level API available, which means direct OpenGL ES 2 calls and shaders. The only consideration for going this route was fun ;-). I have a knack for graphics programming, and spent a lot of time writing various graphics effects and related rendering code in the past, going back as far as software-based texture mapping and transform & lighting on a 486 without a floating-point processor. Looking at the retro-graphics for the game we’re making, I can imagine spicing up the visuals using fancy shader effects, which seems like too much fun to possibly limit myself before I’ve even started ;-).
Obviously dispensing with third-party graphics frameworks means quite a bit of additional work. Managing the scene graph, setting up and translating between coordinate spaces, loading bitmap assets, writing and setting up shaders, animation, everything needs to be done manually. There’s a few benefits to this approach as well though: portability, flexibility, and last but not least, it’s just more fun to develop and write about, and more instructive for anyone reading this blog.
Next post
The first task on my todo list is to prototype the game physics, which involves setting up an XCode project that integrates Box2D, write an extremely bare-bones visualization of a ‘spaceship and orb’ and try to replicate the physics of the original game. This is what I’ll be working on for at least the coming week, in the next post I will report my progress!