AstroSquid Postmortem
astrosquid02.gif
Game screen
A few years later the young man had become quite an advanced programmer and had just developed a new sprite engine he called the Lost Minds Sprite Engine, or LMEngine for short. It used OpenGL to draw 2D sprites with full real-time scaling and blending at good speeds, and he was quite proud of it. To test it he had made a small game, a Tetris clone aptly named LMTetris Demo, and released it as freeware, but now he needed something a little bigger to make a first real release with the LMEngine. He found the old source of the side-scroller and thought that maybe, just maybe he could make something out of this.
The Development
Of course, the old source was quite poorly written classic code, using CopyBits for graphics and with more loose ends than working routines. So whipping it up to shape was more than a challenge; it included fixing bugs, Carbonizing it, and replacing all the GWorld code with the new LMEngine graphics routines. However, it all somehow fell into place and everything progressed nicely. Until one day, when all that was left to make were the levels and some additional sprites. As I was now working alone, with mere moral support from Derek, I simply got tired of the game. With every new sprite graphic added and every new level created it felt harder and harder to continue. But I told myself that this game was too good to just give up on now that I had come this far, so I pressed on, and eventually finished it. This resulted in the first release of the game only having eight levels. I knew this was too little, but I just couldn’t bring myself to make any more.
astrosquid03.jpg
Game screen
After the initial release I got quite a lot of positive response, which gave me the energy to add another eight levels to the 1.1 release of AstroSquid.
As for the more technical aspects of the development, there were a couple of different tools and libraries involved. The first and most important was of course the LMEngine, which is a set of routines to handle 2D graphic sprites. It was used for all the graphics in the game, from the menus and text, to the game interface and actual game sprites. The actual drawing part of the engine uses OpenGL calls, but the engine also has a lot of routines to manage the sprites along with a couple of special routines to, for example, go into fullscreen mode. The LMEngine also has routines to save/load entire scenes of sprites from files, something I found very useful as it meant I could store, for example, menus, interfaces, and backgrounds, and then load them in one call instead of hardcoding things like menu graphics.
The other two libraries I used in the project were MIDIWorld by Derek Smith, which uses QuickTime to play music files, and a sound library I had made earlier to play multichannel stereo-panning sound.
What Went Wrong
Using Legacy Code
The first thing that went wrong should be obvious to most people. The fact that I tried to be smart and renovate old, poorly written code. Even though this might make things easier in the beginning, it always lands you in trouble later on.
I think I would have been much better off if I had started an all new project, with better structure and integration of the LMEngine to begin with. At least it would have saved me many hours of going through pages of old code, just to figure out what it was actually doing to my poor sprites.
Poor Planning
The second thing that went wrong was poor planning. As I never intended the project to get this big and serious I started out with very vague plans of what I was going to make. I think this was one of the main reasons for me losing interest and almost giving up on the game at some points. Had I instead carefully planned what levels, features, etc. I wanted in the game it might have been easier to make steady progress, and thereby keep up my interest. Which is, I think, one of the hardest and most important things when making a game alone.
astrosquid04.jpg
Game screen
Leave the Music to Musicians
The third thing I can think that went wrong must have been the music. As I’m not good enough to do the music myself I asked a friend to do it. In doing this I was all too unclear on what I wanted, how much of it, and when I wanted it. This then stalled the progress, as I felt I had to wait for the music to move on and then when I finally got something I just put it in, even though I wasn’t really happy with it, just to get it over with. I should have been much more precise about what I wanted, and what the deadline was. However, it all worked out for the better as new and improved music was later made and included in the 1.1 release of AstroSquid, making me much more content with the game.
Quality Assurance
The fourth thing that went wrong is a real classic—insufficient testing. Happy that I had finally finished the game and removed enough bugs to make it run on my computer, I was itching to release it. This resulted in quite an unstable 1.0 and quite a few bug-fixes and long programming sessions after the release. I won’t go into any details, but there are a lot of things that can go wrong with DrawSprockets and OpenGL.
What Went Right
The Engine
Now for the bright side. The first thing that went right was actually the work before the actual project was started. The LMEngine and the other libraries performed very well and needed very little maintenance during the development, the exception being the fullscreen code in the LMEngine, which caused me some grief. But apart from that the LMEngine worked very well and the pretty graphics that it made possible are one of the keys to the relative success of the game.
Time-saving Editors
The second thing that went right was during development. I decided quite early on to make several editors (for sprite scenes, sprite resources, and of course for the actual levels). Though this was a lot of work, it really made things easier later on. I also kept on adding features and improving these editors along the way.
astrosquid05.jpg
Main menu
A Polished Interface
Third, I think that the menus and interface in the game turned out quite nicely. Not only do they look quite good, but they also give more feeling to the game and make it seem more solid. I don’t think you should underestimate the significance of good looking, easy-to-use menus and interface, even for small games like AstroSquid.
Debugging Procedures
Fourth, during the development I added an extensive set of debugging tools to the code. This is also something I can really recommend: routines to output a debug file or something similar when things go wrong. This is also very good to have when testing an application, instead of getting an e-mail that just says “it won’t launch,” you could instead get detailed information about the things you are interested in at once.
Good Early Community Feedback
Last of the big things that went right I must mention the release of the game. Even though there were bugs and problems with the release I got a lot of coverage on various websites and good ratings by (some) users. This really helped to motivate me into fixing bugs and releasing a 1.1 version.
Summary
The uDevGames 2002 Contest has, to me, mostly been a way to promote this game and of course try to win some of the prizes. As this game is shareware and I’m just a poor student, I’m interested in making money so that I might buy a pizza or a beer once in a while. However, I’m still young and rather idealistic, so I fully agree with the sharing idea of the competition. The development of the game actually started a little before I had heard of the competition, but when I did hear of it I thought it was a great opportunity and registered at once.
As for the near future my studies are taking more and more time from my programming and I doubt I will get much done the next few months. I do, however, have another game in development and ideas for at least two more when I get the time. AstroSquid is, at least for me, a finished chapter and I strongly doubt that I will ever make a sequel to it, but then again, you never know.
- Genre: Space shooter
- Developer: Lost Minds
- Url: http://www.lostminds.com
- Team size: 1
- Released date: August 31, 2002
- Project length: 5 months
- Development hardware: G3 400MHz
- Critical applications: FutureBasic, Adobe Photoshop, Infini-D, ResEdit, Reason, SoundEffects
