iDevGames

appleii.jpg

‘Choplifter’

When I tried to think of a game I could make that fitted that restraint, something based on an old memory of a 2D scrolling helicopter game came to mind. I later found out that this game was the Apple II classic “Choplifter.” My Dad told me that I played it a lot when I was three or four years old, and it had obviously left a mark in my mind.

With the idea starting to form, I began work. The first step was to make an OpenGL view in a window, and add player control. I used Cocoa and Project Builder, as I was already familiar with them, and within a day or two I had a simple Chopper sprite and basic (but very buggy) player controls, in a spunky metal window.

Then I decided that for this type of game I would need a level editor, so I started working on that. The level editor evolved alongside the game, and was hugely useful in the process.

early.jpg

Early Physics Testing

Continued Development

From there on in, it was a matter of refining and adding to what I had. I started adding collision detection, tanks, and eventually gunfire and explosions. Chopper evolved into something that I had never thought was possible when I had begun.

greyblue.jpg

Gotta Love that trippy grey-on-blue effect!

Graphics were slowly updated as I went. Usually I would put in placeholder graphics for a start, and change them when they annoyed me enough. Most graphics were overhauled at least a couple of times, if not more. Some graphics, such as the Chopper graphic, and the sky and ground, were updated or replaced at least half a dozen times.

An interesting decision I made about a month into development was to give the 3D effect. Chopper has a 2D engine. It’s all done with an orthographic projection so there is no z coordinate. As a graphical enhancement I decided to make it pseudo 3D. I added side walls to buildings, and depth to the grass. This made some of my earlier work redundant, such as angled tiles, and also made some things far more difficult for me later on. It may also have limited some gameplay elements, as it took a lot of my time to make things move properly. I believe it was worth it, though, as it added to the realism element of the graphics, and taught me a great deal.

While making Chopper I used “to-do” lists extensively. I would make a build, play it for a while, and write down any problems I found. I found this to be very useful in many ways. It was a good tool for finding what the player might see as a problem; it ironed out bugs, and there was a great feeling when I had an extensive list with all items crossed off. I also wrote down anything I thought might be added as an improvement to the game. Whenever I completed one task, I would build and run again, and write down anything I found wrong.

This part of the development process was always done on paper, as was any math that I had to do. I think a pencil and paper are invaluable.

What Went Right

I believe the most significant thing that went right was that I was a self-employed artist for the period, and as such was able to spend roughly 10 hours a day for the whole three months working on Chopper. Also, my girlfriend was overseas for six weeks of that time, and I probably worked about 15 hours a day over that period. Time was one of the constraints of the competition, and I had it in my favour.

explosions.jpg

Boom Boom

I was really pleased with how the particle effects turned out. I had played with the NeHe particle engine in the past, and this really helped with what I wanted to do. I found it quite amazing what a few sprites with different color/alpha/blend modes could look like, and saw potential for far greater effects using a similar technique.

Using Cocoa and Project Builder made the task a lot easier than it might otherwise have been. Cocoa is a very stable development library, and is well worth using despite its lack of cross-platform compatibility. Cocoa has taught me how to use classes and how to use them in a way that works well. I would have gotten lost in C++ and would have been more limited in METAL or other such options.

Despite the fact that I will probably never develop on such a limited machine again, I am glad that I used a G3 350MHz iMac to develop on. There were a few entries in uDevGames that as a result of being developed on higher-end machines run very poorly on low-end Macs, and could have been easily optimized to run much better. I was forced to optimize a lot throughout the process, just so I could continue to test it. This brings two benefits: one, I have learnt ways to optimize code, and two, Chopper can run reasonably well on a G3. I think a good way to develop games would be to code and build on a fast machine (aka G5), and test on the lower spec machine you are aiming for. I hope to do this in the future.

The iDevGames community and the uDevGames Contest were a tremendous help along the way. The combination of motivational and technical support has been amazing.

Another thing that went really right is that I got a great job as a result of developing Chopper. The experience and knowledge that I have gained have proved to be invaluable.

‘http://debug.jpg

Play Testing & Debugging

What I Would Do Differently Next Time

Instead of writing what went wrong, I thought it would be easier and more beneficial to say what I would do differently.

Number one on the list would have to be that I would do it all in 3D right from the start. As I mentioned earlier, pretend 3d in orthographic projection is a lot of work, and limits what you can do. This is going to mean that if I were to do Chopper 2 it would have to be a re-write.

hoverbuilding.jpg

Hmmm…. Floating Buildings?

I would plan more. When I started Chopper I had no idea what it was going to be like, only a very vague memory of Choplifter. If I had thought a little further ahead I could have structured better and saved myself a lot of headaches. Now that I have learnt more about my own capabilities and limitations I will be planning my next project a lot more carefully from the start.

Related to this, I would also refactor more. The code got very messy about halfway through when I changed the way map tiles were saved and loaded, and found I had to optimize. Instead of spending the day or three cleaning it all up and making it nicely structured, I just left it in a mess. The code turns into a dodgy DIY add-on spaghetti pile and it then takes a lot longer to add new features. Functions should also be shorter than I have made them, if anything just so it is easier to navigate through the code. The classes work well, but the functions within them need to be broken up into much smaller tasks.

I would write my own music and spend more time on sound effects. I spent about three days searching the net on a 56k modem for suitable music. It was a very frustrating process, and in the end the best I could find was less than satisfactory. A hired musician or music creating software is a must for decent music, and next time I will hopefully have the latter.

I would post less betas. I probably uploaded about 30 beta versions over the three month period, and although I received great support from people, many seemed to tire of it at the end. Fair enough too! Three or four betas would probably be a much better way to find out what needs fixing that I hadn’t already noticed while play-testing.

Conclusion

Chopper has been great fun to make. Most of all, it has been a great learning experience. If I had sat down before I began Chopper, and thought about what the best Choplifter clone I could make would be, I would not have imagined anything near the standard that Chopper turned out to be. I now feel I can do anything, and can’t wait to prove it!

• Genre:
• Developer:
• Url:
• Team size: 1
• Released date:
• Project length:
• Development hardware:

• Critical applications: