iDevGames

I knew at the beginning of the contest that this was a huge project to take on for a three month time frame. I did as much planning as I could ahead of time, and studied all of the technologies I thought I’d need. I wrote up a thorough design document, and showed it around to a bunch of other developers for feedback. When the contest start date finally came around, I felt pretty well prepared for what was ahead.

Development Tools

IDE

I used Project Builder as my IDE. Up until the contest, I’d been using-don’t laugh-MPW. I nearly ended up using MPW for the contest, but recent events convinced me that it was finally time to drop Mac OS 9 support, and move on to Mach-O. I’ve looked at Xcode, and I feel that it is rather bloated and unintuitive. While a bit older and no longer officially supported, Project Builder seemed a better choice to me, and it worked without a hitch.

Text editor

BBEdit was the most essential tool for me. I’ve been using it for code editing for years, and it’s the best text editor I’ve ever used, hands down. Syntax coloring, regular expression find and replace, and many other features make it a fantastic programming tool. In September, I upgraded to the newly released BBEdit 8.0. It had a feature that made my workflow much more efficient: single-window, multi-document editing. I had previously been minimizing each source file’s window to the dock—not a good solution when you have more than a dozen source files!

Graphics

I tried out several different image editing programs early on, and was having trouble finding one that suited my needs. I don’t own a copy of Photoshop, and didn’t have the money to spend on one. Eventually, Daniel Lurie recommended the GIMP (GNU Image Manipulation Program). I was initially turned off by it, as it ran in X11, but after using it for a while, I found that it really worked quite well. It served me well over the course of the contest, and I feel it gives even Photoshop a run for its money.

Audio

I used two programs for audio: Amadeus II and Reason. Amadeus II is a great little shareware audio editing program, and one of the few shareware programs I’ve actually registered. I had a bad experience with Audacity, and there didn’t seem to be anything else usable out there. Some sound effects were recorded, some were artificially created, some were copied from the original Water Tower (a fact of which I’m not proud—I wish I’d had time to redo them), and some were created in Reason. I wanted to write background music for the game, but unfortunately, due to lack of time and lack of musical talent, that didn’t happen.

Models

I looked at a few modeling programs, but they all seemed to have a rather steep learning curve, and I couldn’t be bothered to spend the time choosing one and learning to use it. None of them quite managed to fit my needs anyway. I ended up creating my own model format, and typing in most of the models by hand. For some of the more complex models, such as the deadly block, I wrote a small console application to generate them programatically. While far from an ideal solution, this at least allowed me to get the job done and move on.

What Went Right

Game Concept

Since I was building on a game concept I’d created the previous year, I didn’t have a whole lot of work to do here. Essentially, I just had to figure out how to make the transition from a 2D world to a 3D one. I had some crazy new ideas for game features, but a lot of them didn’t make it. By the end of the contest I had a game that was very similar to the original. While I would have liked to explore new concepts a little bit further, I feel the original gameplay survived the transition to 3D very well.

Code Structure

I had learned a lot about writing better code since the uDevGames Contest from the previous year. Working with another programmer helped me see new and better ways to write things, and after adopting what I feel are better coding practices, my coding has become more efficient. Toward the end of uDevGames 2003, the Water Tower source code had gotten to be such a mess that I could scarcely add a single new feature without causing three new bugs. Water Tower 3D was a completely different experience. The code remained clean and readable throughout the entire project, and was very flexible. Adding new features was almost always painless and easy. Keith Bauer, another programmer, looked over my code toward the end of the contest, and told me it was nicer and more readable than most other code he’d seen.

Animation

When I was planning the game before the start of the contest, I knew that character animation was going to be one of the bigger challenges. I did some research, asked some people who had done this sort of thing before, and came up with a system I thought would suit my needs. I wanted to get as much research as possible done before the contest started, and since animation seemed like such a large unknown, I spent most of the month of July working out how to do it. When the contest started in August, I was pretty satisfied with my animation system. When the time came to implement it in the game, it was up and running in a matter of about two days. The results were quite pleasing. During the course of the contest, I got many compliments on how well-animated my character was.

Asset Management

Managing assets for the game was a pretty smooth process. I had a directory full of human-readable ASCII files that were used for models, animations, and textures, as well as a separate directory for the texture images themselves. I could set up material properties for each texture, and change which texture is used on a model by changing a string in my model file. My model and texture loading code loaded all of the files in the directory at startup, so no additional loading code was needed when I added new models or textures.

What Went Wrong

Water

The biggest trouble I ran into during development came when I tried to implement water. I wanted a system where the water would flow more realistically, as opposed to a flat plane rising at a constant speed, as it was done in Water Tower. I started on the water system in September, thinking I could get it up and running in about a week.

A week passed, and it still wasn’t working, so I figured I’d give it another week, as it was a very important gameplay element. Another week went by, and another… Before I knew it, I had spent more than a month of development time doing almost nothing other than work on the water system. That’s a gigantic loss of time for a three month contest! Eventually, I realized that if I continued on the water system that way I had been, I wouldn’t have anything even close to releasable by the end of the contest. I cut my losses and implemented Water Tower-style water, and was done with it in an evening. To this day, it’s the thing I’m the most disappointed that I wasn’t able to do in the game.

Too Big a Project, Too Little Time

I knew from the start that this project was really asking a lot of myself in such a short time frame. With everything I wanted to do with the game, there was no way I could get completely finished in three months. I tried to prioritize the most important game features so that I could at least have a working, playable game by the end of the contest. I don’t feel that I did a very good job on this. Some fairly essential game features were still missing by the time voting started, and there were some other things I really could have done without that took a lot of time. I do feel that I’ve pushed my limits and done more than I could have imagined in the time given, but the project was still much too large to be appropriate for uDevGames.

The Character Model

Another big unknown was the character model. I had very little experience with any modeling program, and hadn’t ever modeled anything as complex as a human before. For the first half of the contest, I was using a white stick figure for the character. I would have liked to create a more realistic human model, but I didn’t even know where to begin. When I was showing the game around to coworkers one day, someone had a suggestion for at least a start: stick with the model I had, but give it colors to make it look like a character from the Atari 2600 era. The effect wasn’t too bad; a definite improvement. I spend some time proportioning the character to look less like a stick figure, and eventually decided the result was good enough for the contest. While not really satisfied, I was at least able call it “done enough” to move on to other things in the game.

Camera

There were some usability issues that I unfortunately never addressed. One problem, which seems to be inherent in any 3D game, was the camera. I put all of the responsibility of moving the camera on the player. While it’s nice to be able to control the camera, it’s not something most people want to have to worry about in the middle of the action. I had some ideas for how to make this nicer: I was going to have an invisible object that could be placed in the level editor that I called a “camera hint.” When the player walked over a camera hint, the camera would pan to a predetermined angle. Well-placed camera hints in a level could make it unnecessary for the player to adjust the camera at all. Add that to the long list of features that didn’t make it.

Levels

I wanted to have at least four different level sets finished by the end of the contest: Tutorial, Easy, Intermediate, and Advanced. Sadly, the levels you see in the contest version are none of those; they’re still placeholders. The difficulty is about at Intermediate level, which is also a problem…the game has a rather steep learning curve for beginners. I have to wonder how many people stuck with the game long enough to get the hang of it.

Conclusion

While I’m proud of what I’ve done with the game, I have to admit that it was simply too large of an undertaking for a contest of this scope. However, if it hadn’t been for the contest pushing me to finish, I probably would never have gotten anywhere near this far with the game. It would have been just another project on my this-would-be-cool-but-I’ll-never-get-around-to-it list. I’m planning to come up with a somewhat smaller project for the next uDevGames Contest. It would be nice to be finished by the deadline for once!

I was told by many developers that I was crazy for trying to do this alone. Many times when I felt overwhelmed, I considered looking for other team members to take some of the load off, but I stuck it out by myself to the end. The main reason I enter uDevGames is to learn new things; how can I learn if someone else does the work for me? This experience is invaluable. I feel that I’ve furthered my abilities as a programmer, an artist, a designer, and a musician. This is my goal. This is why I do what I do, and why I enjoy working alone.

A big thanks to iDevGames and all of its staff members for organizing this contest. It’s one of the best things in which I’ve ever participated. Thanks to the sponsors, for donating some great prizes to motivate developers to do better. And thanks to Apple, for creating this wonderful computing platform.

• Developer: Alex Diener
• Language: C
• APIs : Carbon, OpenGL, OpenAL, FreeType, Vorbis
• Source files: 71
• Lines of code: 17,110

Further Resources

• Rescue
• Black Shades Postmortem
• Black Cube Postmortem
• GL Fighters
• Rosetta Stone Summer Game Jam