When iDevGames.com announced the 2005 OMG Cup in October I immediately considered entering. A contest was just the right motivation for me to actually start and hopefully finish a game project.
Aside from needing an idea, there were a few hurdles to tackle. Not only was this my first game project in almost fifteen years, it was also to be my first Mac project, written in Objective-C and Cocoa. I was also aware that most games for the platform are written in OpenGL because of the sub-optimal performance of CoreGraphics and Quartz Extreme. Though I have been a professional software developer for twelve years, I felt that learning OpenGL in addition to Cocoa was too much to tackle in such a short time frame. So I had to make do with what Apple’s API would provide.
Budget was the next hurdle to tackle. Money was limited, I had to operate on a very small budget. I would either need to create all my own artwork and sound or acquire what I needed for free or very cheap. To help limit the amount of artwork I would need, the game would have to take place entirely in one location.
Once I decided upon the basic game idea, I put together a very rough prototype to get a feel of how the game would play and whether it was something I could finish inside the six week deadline. Armed with my prototype and a rough project plan, I dove in.
Here is what went right and what went wrong:
The Good
Cocoa
Apple’s Cocoa framework is amazing. It does have a steep learning curve, but once I got a feel for how things fit together work became a pleasure. CoreGraphics may be slow, but it has some great functionality built in. There were many times where I feared having to write a very complicated set of routines to get something done, but a quick search through documentation lead me to a class or method that did exactly what I needed. While I did have performance issues to work around, especially on older machines, I wouldn’t hesitate to use CoreGraphics for simple games that don’t have intense animation requirements.
Collaboration
I’ve written extensively about my experience working with my graphic designer. While I was very happy with the quality of work and the timeliness of delivery, the best part of working with someone else is the additional input an objective observer can provide. My designer provided many ideas and suggestions that had very real and positive impacts on the game’s design.
Bullfrog was originally going to have a simple black background. Jordan would have nothing of it. Before I knew it he’d sent me a very nice background image with some ideas on how to use it. Ultimately, the background changed a bit and ended up being a simple window dressing for the game; but, I ended up with some very cool ideas for the next version.
The Bad
Sound
There were two significant disappointments on the sound front for Bullfrog. First and most significant was my decision to go cheap (read free) for all my sounds. When selecting the sounds, each one sounded adequate. When put together and repeated many times during game play they became annoying rather quickly. Even if they don’t annoy, the overall sound mix does not meet my standards. Next time, I pay for quality tracks. In hindsight, I would have been better off with no sound than bad sound.
The second issue was technical. While Cocoa’s sound support is adequate for playing simple audio, performance and functionality is the pits for game development. I would consistently see significant frame-rate drops when more than a couple of sounds were played concurrently and the API provides very limited access for controlling how the audio tracks are played. There is no support for fading or panning. Next time I’ll definitely look into alternatives for my audio needs.
Tiger Only
Unfortunately, somewhere along the line I boxed myself into only being able to support the latest version of Mac OS X (Tiger). The game would execute just fine on 10.3.9 (Panther), but something with my handling of images caused graphics to disappear when animated. Since I don’t have a long history with Mac development, I have no frame of reference for what could have changed from 10.3.9 to 10.4 in the graphics handling. I suspect it was the png support changes I read about somewhere, but I didn’t have the time or the experience to hunt down the problem within the contest timeframe. Thankfully, the OMG Cup only required Tiger (10.4) so I settled for having to fix the problem after the contest. Since the game was targeting simple game play for casual and young players, I need to target older OS X versions since this audience is more likely to fall behind in operating system versions.
General Observations and Lessons Learned
Play Testing
Play testing is critical. I don’t mean testing for bugs, that goes with out saying. I mean testing game play. Is the game fun? Is it easy to learn? Do the controls work as designed? Is your game “user friendly”?
It was fascinating to watch someone play my game for the first time. Especially people who are not hard-core game players. One of the first things that jumped out was my choice of control keys. I had gone with the first-person-shooter standard of ADWS for left, right, forward, back. Bad choice. Simply choosing the more obvious arrow keys made a world of difference. Get as many people to play test your game as you can. Do this early. Do this often.
Everyone found the game more difficult to play than I do. What I thought would be challenging, others found frustrating. What I designed to be easy, was often just right. This probably varies between games, genres, and target audience to some extent, but I would bet that there is some of this for all games.
Polish is Important
Games that are not polished aren’t done. Developer graphics and sound won’t cut it. No matter how “fun” the game is, if the presentation isn’t professional and polished then the game will disappoint. Cutting corners will only serve to pull the overall feel or value down. See my experience on using free sounds above for reference.
Deadlines are Good
One of the things that excited me about working on my own development projects was the lack of artificial deadlines. I was looking forward to the ideal of only releasing my software when it was done. The reality was indecision and procrastination. Before the OMG Cup announcement, I spent months flailing about without choosing a game idea or creating a final design. I started and abandoned several prototypes and never committed to moving forward.
The OMG deadline motivated me and got me moving. It also kept me working through to completion. It forced me to decide on a game design even if it wasn’t my “ideal” or favorite idea. A finished game is better than a great idea that isn’t even started.
Conclusion
Bullfrog was an incredible experience. I gained confidence in both game development and Mac programming and I learned a lot about myself in the process. Six weeks seemed like a very short time to write a complete game, but I surprised myself with what I was able to accomplish starting from scratch.
The OMG Cup was a ton of fun to participate in and the people at iDevGames.com were an inspiration and invaluable support network. I look forward to trying again next year.
Technorati Tags: game design, game programming, outer level, bullfrog, mac games
is on the way! 
