Gaichu Postmortem
What Went Right
Early Planning, or “The List”
By choosing an update to a classic game, a lot of the hardest work was already done. Since Ladybug was a maze game, I had a genre that was proven to work. In addition, I had already worked on an unreleased maze game, so I knew most of the programming challenges that would confront me. With that in mind I grabbed a fresh yellow legal pad and started planning. I wrote down every game play feature I thought I would need. I planned out the interface. I wrote out several classes and how they would work. Whenever I would think of something new, I would add it to the to-do list. If I knew I wouldn’t have time to do the programming or art for a feature (such as terrain multi-texturing, or multiple level designs), then it didn’t even get written down.
As the three months went on, the list grew and shrank, but it always remained a roadmap for what I had done and what I still had to do. I could see which features would need to be implemented next, and which could wait until the end in case they needed to be cut. It wasn’t a strict schedule or design document, but it did its job. I was kept sane as the list kept the project organized. My brain could focus on the task at hand instead of the overall picture. In the end the vast majority of features made it into the final game, leaving a few to serve as the basis for a post-uDevGames update.
Cocoa or OpenGL
Apple has done their homework — ;Mac OS X is a dream to use and to program for. I knew before I even started work on Gaichu that I would be using Cocoa and OpenGL to realize it. OpenGL was a no-brainer, as there is no other alternative on Mac OS X for 3D. However, I had never done anything more than a few simple tests with it. Cocoa worried me as well. I had programmed several full projects using Carbon for both classic Mac OS as well as Mac OS X, but my only Cocoa programs had been those same OpenGL tests.
After the three months I can say that I shouldn’t have been worried at all. Obj-C is a beautiful language and Cocoa is a beautiful API. The Cocoa development docs are a great resource, and what can’t be found there can easily be found on-line (CocoaDev is a favorite). OpenGL is very easy to use and puts the old QuickDraw API to shame. And needless to say, the on-line resources for OpenGL are vast. Anybody who still isn’t using Cocoa or OpenGL needs to get with the times and discover the greatness of these two APIs.
Listening to Early Feedback
I knew from the beginning that since I was working alone I was going to need feedback from as many outside sources as possible. I tried hanging out in the iDevGames chat room as often as I could, and I had a Gaichu feedback thread in the forum within the first three weeks of the contest.
The early feedback was invaluable as my “testers” caught several bugs that I wouldn’t have caught otherwise. I thought that my first attempt at player movement code was more than adequate, but because of feedback I ended up re-writing that piece of code more than three times. And I must conclude that player movement in the final version is vastly superior to the earlier versions.
Listen to your testers. When you’re playing your game four hours a day, every day for months, you start to lose perspective. Just because you think a certain feature is adequate, or that the difficulty is right on, that doesn’t mean that the rest of the gaming public will as well.
What Went Wrong
Inconsistent Art Focus
If there’s one thing that I hate more than anything else in shareware games it’s amateurish artwork. I used to believe that artwork wasn’t what made a game great, but it’s hard to have fun playing a game when the artwork makes your eyes bleed. In the not-making-your-eyes-bleed category, I think Gaichu does pretty well, however I still wasn’t satisfied with its artwork.
Gaichu lacks a consistent art focus. Since I was doing all the artwork myself, I thought that I wouldn’t need to do extensive sketches and tests for each piece of art. I thought that I could just make each piece as necessary and in the end it would work out since they would all be made by the same person. It didn’t turn out that way. Most of the artwork was redone not once, but multiple times. Some pieces like the title-screen were slapped together at the last minute.
Gaichu badly needed an art director with a unified vision for what the game should have looked like. Gaichu’s final artwork isn’t bad. In fact, there’s a lot I like about it. However, it’s not as good as it could have been, and that’s something I will be striving to fix in the near future.
The One-Man-Band
When you’re making a game by yourself, you have to wear a lot of hats. Sometimes you’re the producer, sometimes you’re the programmer, sometimes you’re the sound guy. Unfortunately, at times certain hats get more of a preference than others. For Gaichu it was definitely the programmer hat that took up most of the time. When presented with both a programming and an art task, the programming often took precedence. Art and sound assets took a back seat and didn’t receive as much attention as they deserved.
Regrettably, there’s not much that can be done to remedy this. There are really only three possibilities. You can extend the deadline to give you more time, you can hire one or more persons to assist you, or you can overextend yourself and work even harder for longer hours. For the uDevGames Contest, number two is the only real choice; unfortunately I have a phobia of letting other people help me on projects such as this. A partner or two on a later project might be something I want to explore.
Not Enough Early Feedback
Above I said that early feedback was one of the things that went right, however it’s also something that went wrong. Browsing the forums shows that a few of the games seemed to monopolize most of the forum members’ time. Some games reached multi-page threads almost immediately, while others died out without constant developer bumping. When you’re a developer starved for feedback, you start begging for comments and suggestions.
As the voting was winding down I received several comments that the game was too hard, that the enemies were too fast. That’s a great comment that can be used to improve the game, but it came too late in the contest to work on it. Next year I’m going to lock several testers in my basement and force them to give comments and suggestions.
Conclusion
In the end, Gaichu did pretty well; 5th place in Polish, and 10th Overall, is nothing to sneeze at in a competition involving 43 games. Of course, the best prize is that after years of programming and attempting to make games, I’ve actually made one. When someone asks me what I do and I respond, “I make games,” I no longer secretly think, “Liar!” In that regard, uDevGames 2003 was huge success.
Project Details
- Number of Developers: 1
- Length of Development: 3 months
- Development Hardware: 867MHz G4 (1.1GB RAM/GeForce2MX 32MB), 350MHz G3 (448MB RAM/Rage128 16MB)
- Critical Applications: ProjectBuilder, InterfaceBuilder, Photoshop, Hash Animation Master, UVMapper, Peak DV, Melody Assistant, OpenGL Profiler, Shark
- Project Size: 48 code files, 9,833 lines of code, 100MB of art and sound assets
Further Resources
Since 1998, iDevGames has been educating, supporting and enhancing the community of game developers that develop video games for Mac OS X & iPhone. Subscribe to our