Chopper 2 for iPhone Postmortem
Aug 19, 2010—
The beginnings of Chopper 2
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.
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.
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. 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).
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.
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.