I was recently asked on the Cocos2D iPhone forum some details about Occurro!. People were interested in the game architecture, special effects & touch controls. I could definitely write a book about all the design decisions, architecture, and other aspects of creating the game. Unfortunately, I’m still spending time adding things to the game & making it better – so, there isn’t a book yet.
Occurro! The Game of Stellar Combat was released on July 11, 2009. A week later it was featured by Apple & it quickly rose into the top 50 paid apps in the App Store. Take a minute & check out the trailer:
I shared some thoughts and ideas in a couple threads at the Cocos2D forum about little parts of the game, but never the overall design …or detail on things like explosions. This is some big-picture info on those topics.
I started with one of the Cocos game skeletons in February ’09. I stripped it down to the core and built Occurro! on top of it. Since then, I moved it from Cocos 0.5 to 0.6, then 0.7. A stripped down version of what I use currently is here: http://www.acceleroto.com/share/MultiTest.zip That file includes Cocos2D 0.7.3, so it really should be updated to the latest before you get going on a project with it. Otherwise, feel free to use it how you’d like. (Caveat: if you compile that sample code & try to publish it in the App Store as a game, the entire world will make fun of you.)
Occurro! currently has 15 different Cocos layers that it can switch between, all in their own class. Each new “screen” that the user sees is a layer. The game launches into a layer that does some pre-processing (is there a saved game? what are the default options? etc.). From there it decides to go to the main menu or the resume menu. The main menu has several submenus that allow the user to do all the typical game setup stuff, see credits, and view high scores.
Occurro!’s high scores are handled by Geocade’s service. I display a UIWebView within a Cocos layer (just like in the above sample code). That layer handles all the location services, web requests, and keeps track of scores the user still needs to submit.
The main game is structured much the same as the above sample code – just much more complex. I set up a series of timers to handle various things in the game. My main game loop (called “step” in the code) is fired at 60Hz. I also use a gun firing timer, an enemy spawn generator timer, and a couple other housekeeping timers – all get fired at different rates.
When I start the game layer, all the initialization stuff is done. To speed things up during gameplay, I create a fairly big pile of each enemy, weapon & power up type and keep them around for the entire duration of the game.
After the initialization, I jump into the game loop & do this stuff:
- update the player ship based on player inputs & its physics
- update enemy positions based on each of their AI & physics
- update laser positions
- update and/or remove power ups
- check for collisions (lasers, enemies, power ups, etc)
- handle player death or other status changes if required
- kill enemies if required & generate explosions
- add points
- check for level ups and extra lives
- update the score board (if the player got any points)
- update other HUD indicators (if the player got any power ups or used weapons)
- update control indicators based on user inputs
- position & start sounds as required
- update the camera position
At the end of each game loop step, Cocos updates all the actual pixels on the screen using OpenGL. After that, the game loop starts over again.
I tried to keep everything fairly compartmentalized in their own classes. I subclassed CocosNode to make the player, enemy, power up, and weapon classes.
My explosions are new classes that I made by copying and modifying Cocos2D’s ParticleExplosion class. Each one of my enemy explosions is made up of 2 different classes each with their own custom artwork. The first is the “flash” class – it shows a couple of initial flashes & picks between about 6 different art files for the flashes. The second is the flying particles of the explosion. When an enemy is killed, I start both of these particle systems at the same time. To make them look like I wanted, I just modified individual parameters within each class until they matched what I was thinking.
The touch control system is fairly complicated & would take a couple pages to explain properly. In a nutshell, whenever a new touch is detected in a control zone (for example, one control zone is the area that I designate do control the lasers) it removes any old control on that control zone & sets the center of a new one at the touch location. After that, the touch location is compared to the initial position, some trig is done along with some other input shaping/calculations to determine what actual command is passed to the ship’s motion or laser system. When that touch ends, the corresponding input is stopped & that control indicator is removed from the screen.
This really just scratches the surface, but hopefully it helps get you thinking on the right track (or at least one of the right tracks).
For more information on Cocos2D iPhone, please visit http://www.cocos2d-iphone.org/
Also, please check out Occurro! in the App Store: http://bit.ly/occurro – just $0.99