This was a two person project. Total development time was about 4 months, and included many variations, changes in direction, tweaking and re-tweaking, mid-project breaks (where nothing was done), beta testing, and final rounds of changes based on user feedback.
I did all the Unity iPhone development and my project partner, Peter Hamlin, did the character design, graphics illustrations.
Here are some development notes, off the top of my head, that may be of interest to fellow developers. I’m happy to answer any specific questions, share code, or elaborate on any part of the development process. Ultimately, we hope to have a section on our game’s website, dedicated to Unity iPhone development info and resources, based on our collaborative project experience.
Development Brief:
The app was developed entirely in C#. The text editor used was TextMate, with a C# language bundled developed by one of the forum members here. (Sorry, I can’t remember who’s it is at the moment.)
The main development challenge was dealing with performance on 1G Phones.
This game has a lot of draw calls – the game uses billboarded sprites with the blend mode used by particles - premultiplied alpha blend. By the time development got underway, it was too late to switch to Sprite Manager. I’ll probably look into that for the next game, though.
Sprite sizes range from small – the cars, to large – the backgrounds. Each level has a background comprised of 2 RGBA textures that are 512x512. GUITextures were only used for interface elements – score bar, icons, etc. because the other game elements, i.e., the backgrounds, needed to be rotated. Rotation occurs by shaking the camera when vehicles crash.
Most animation was mostly done in Cinema 4D and played back in game. This type of animation was much easier to work with than anything animated programatically. Some problems arose with animation playback, where the final keyframe was never played, leaving the animation in an unfinished state. This problem was discussed elsewhere on the forum, and the solution was to set the animation playback to clamp the last frame ‘forever.’
Secondary animation occurs when cars crash – Unity’s physics system kicks in. However, it’s only turned on after a bounding box collision occurs between two or more vehicles – until then, it’s dormant and does not take any CPU cycles.
The only physics bounding volumes used by the game, for collision, are around the cars, so the physics parameters were tweaked so that no collision moved any car too far – ensuring no awkward placement of cars over the static background elements like trees or buildings.
All physics rotation was restricted to the Y axis of each vehicle, so there were no 3d rotations in space.
Finally, the physics behavior in the crashes sometimes yielded ‘boring’ collisions – so some code was added that is executed when two cars collide: There is random torque applied to each car, making them spin a bit.
For the art process: All the game elements were illustrated in Adobe Illustrator by Peter and I would work as technical artist to fit them into the game, preparing texture maps in Photoshop, building the 3d billboards in Cinema 4D, adding animations, etc., ‘normalizing’ color palettes/brightness/gamma, etc. For a game of this size (I would think it’s pretty small) there were an amazingly huge number of assets required. Peter generated a lot, and some have not yet been incorporated into the game yet, because I fell-behind on finding time to add them all in. We’re planning to use additional art assets in future updates.