Chopper 2 for iPhone Postmortem

David Frampton —
Aug 19, 2010

The beginnings of Chopper 2

'Mac first, iPhone port' - most of what was written here bears little resemblance to the final game

The initial phase of a project is always hugely exciting, and Chopper 2 was no exception. It was supposed to take a mere six months at this point, and I was full of energy and ideas – ready to code like crazy. During this phase my time was mostly split between planning/thinking/writing down ideas, researching the technologies I wanted to use, and beginning the code involved.

While in planning mode, I’d appear catatonic to passers-by. Most of it was visualization: imagining how the worlds might look; how enemies would behave; resolving the conflicts between realism and enjoyment, challenge and accessibility, beauty and performance.

Initially I had ideas of planes dropping paratroopers and artillery from above, wind gusts and mini-tornados to avoid, deformable terrains, luscious jungle environments, and a bunch more. However, things had to be removed due to the numerous constraints: enemies dropped from above could add months to development; wind gusts would be hard to convey and would detract from the environment; deformable terrains offered little utility but huge game engine complexity; and complicated environments would be prohibitively slow on older hardware.

So that side of the planning phase was very important in making a cohesive and enjoyable game, and it never really ended (but certainly was a large focus early on).

From time to time there were a few kinks to iron out

The incessant flying tanks

Another side to the planning phase involved the technologies I would use to create the game. There were plenty of these early decisions that heavily influenced the direction of the game and its development. Perhaps the first was to use the Chipmunk physics library. Chopper 1 had a very simplistic physics engine that I had created. The world was a grid of tiles, and the game objects were simple squares or collections of squares. The enemies didn’t move, and nothing ever fell onto anything else in a realistic way. It was all very rigid.

The incessant flying tanks

In Chopper 2, I wanted enemies to fly off with flailing arms when they were hit by an explosion and I wanted the chopper to feel the impact of explosions. Most importantly I wanted terrains and buildings to be at any angle (to allow for hills and angled roofs) with the game elements responding correctly to these environments. Chipmunk gave me this, and was quick and easy to get up and running. It had a nice support system and docs, was under active development by a friendly guy, and was open source.

So it was great, and provided a much better final result than I could have come up with on my own. However the more complicated/realistic physics system caused its own set of problems – tanks flying off into space being a common one. Initially my tanks were just a few quads sitting on the ground and I’d push them around with forces, but they didn’t behave in anything like a realistic manner. So I changed them to one quad and two wheels, and all hell broke loose. There must have been about fifty unique bugs in the way I implemented it, each one causing the inevitable ‘WTF is that tank doing flying in the air’ bug. From being initialized a little underground and the physics engine over-compensating, to accidentally applying massive torques, to lack of friction and sliding off cliffs, to driving head first into an obstacle and spinning off, I had it all.
The level editor

Another influential early decision was how the levels and terrains were to be constructed. In Chopper 1, I had built the level editor alongside the game, and found that to work quite well, so this was also what I did in Chopper 2. However, creating the Chopper 2 level editor was a much larger task due to the vast number of new features.
The editor ended up having as much code as in the game itself, and added at least four or five months to the development. It was absolutely invaluable, though. I can’t see any way that I could have created all thirty six missions, or had the level of polish I achieved without having this editor.

Very early screenshot of the Level Editor

The editor ran on Mac OS X, and had a full cocoa GUI for all of the configurable parameters of each mission. It also had a keyboard/mouse controlled view that largely ran exactly the same game code as the iPhone/iPad version. So I could make a change, hit reload and the level immediately reflected this change. It also allowed me to set up all the camera fly-throughs and text positions for the mission briefings relatively painlessly. If I had been trying to do this in text files and then building and running on a device or the simulator, I would have given up on the project before it got off the ground… no pun intended.

Editing Text

Creating worlds

The river was placed manually into the mesh using Cinema 4D

The terrains and 3D models were created with a fairly complicated process. I’d decided long before I even began that I would have mesh-based 3D terrains in Chopper 2. Mesh terrains were something I’d had a fair bit of experience with in my day jobs and in various hobby projects, so I had a good idea of what approach I would take.

Firstly, I downloaded freely available height data for real world locations as a base. The canyon level is using elevation data from the Grand Canyon, and the volcano in the background in Misty Valley is Mt. St. Helens.

Terragen 2 being used to create a sky box for the canyon location

From there, I opened up the height data in Photoshop to make small adjustments to make it work better in the game. Then, I ran it through a simple tool I had created to turn that into a mesh, optimized for Chopper 2 with more polygons in the foreground. I also took a slightly wider area of the height image and used that as a base for Terragen 2. And after a lot of playing around, learning how to use it, and many (some times half a day long) renders and re-renders, Terragen 2 would spit out a sky box and a great sunlit texture I could map onto my mesh.

The majority of that work happened over a large trial and error period, which lasted three or four months near the middle of the project. Before this, I had already decided on the number of missions and locations I would have, and so while I was familiar with all of the related tools, I focused on getting every one of the terrains/landscapes done. It was a long hard slog, and though it was very rewarding work, getting all twelve of the landscapes looking nice took much longer than I had anticipated. So long, in fact, that around this time I reluctantly removed the intended ocean based locations from the game (though I hope to add them in some future version).

A procedurally generated city

I also created a city generator application, to allow me to easily generate and modify the meshes for the three city locations in the game. I’d played around with placing large buildings onto meshes by hand using Cinema 4D, but the results were ugly, perhaps largely due to my rather poor 3D modeling ability. This city generator worked out great, and I am really happy with how the city levels ended up looking in game. The reflections in the windows combed with interior lights (all smoke and mirrors, of course) worked really well too, and I have Keith Bauer to thank for guidance on the texture combiner code required to achieve that effect.

The camera zoom math problem. Given A B C and theta, solve for x

During this landscape design phase, I was also working on a lot of the more general game elements, I was fixing issues with the physics and refining the feel of the chopper flight.

I designed some of the menu screens to get more of a feel for how the user interface would look and behave, and added many new enemy types and game features.

I was also working on the behavior of the camera, and ended up creating quite a sophisticated mixture of manual spline placement with automatic camera zoom and tilt. Thanks to Bruce Hoult for helping out with some of the math involved there.