Category Archives: Game Programming

Post navigation

GB does a nice job of summarizing some basic concepts that can be incredibly powerful for simplifying your object model as well as future-proofing your design.

I’ve used these techniques extensively for application development in my day job as a C# developer. As GB mentions, it’s very easy and tempting to fall into the deep class design mode, but if you can resist and take the time to turn your classes sideways, your classes will grow in power and flexibility right before your eyes.

Thanks to GB’s reminder, I’ll now remember to use these techniques in my games.

I’ve been steadily plugging away at my list of bugs and enhancements for the upcoming release and finally tackled one area that I had been avoiding: improving the AI of some of the bugs.

Most of the bugs had a pretty random set of behaviors depending on how close to the edge of the screen they were moving. But other than keeping them from getting stuck in a corner or wandering off screen, their decision trees were pretty simple.

“How long since the last time I turned?”

“Which direction do I turn this time?”

The only bug that had any intelligence to speak of was the feared mosquito. Since the whole purpose of the mosquito’s life is to harass the player and steal valuable time off the ticking clock, it needed to chase the frog and buzz him. So the mosquito’s decision tree looked something like the following:

Unfortunately, I didn’t have time during the contest to really give any of the other bugs any convincing artificial intelligence. I made a crude attempt at making the Horsefly flee the Bullfrog if it ever came too close, but I was unable to get it to work without the fly trapping itself in the extreme corners of the screen.

With this upcoming release, more of the bugs finally have some “intelligence” to them. I revisited the Horsefly code and was able to rewrite the AI code to give the fly some simple evasion behavior, but it’s now smart enough not to get trapped. Well, okay not quite smart, but it falls back on its random behavior if it gets too close to the edge of the screen. This completely eliminates the trapped fly problem.

With this small success, I also attacked the bee’s AI. In this case, I didn’t want to add any intelligence, but to cause the bee to go into a frenzy when approached by the frog. My approach was to simply increase the bee’s movement speed when the frog came near. This gives the illusion that the bee is agitated by the frog’s presence.

Granted, these changes aren’t rocket science but they do break up the repetitious pattern of random movement at constant speeds.

With these changes “in the can”, I’m down to four items left on my list. Hopefully, I’ll have the time to get these coded and tested in the next week.

The only real hurdle left is finding a way to test the Universal Binary so that I can include that as part of the release.

Tonight, I completed the last of my top seven prioritized “cases” for the next release of Bullfrog.

I have twenty total issues assigned to this next release, though a large portion of them are of the nice-to-have type. Depending on time, we’ll see how many of them actually make it into the release.

As part of the development going into this release, I’m putting FogBugz through its paces. So far it’s performing very nicely. I’ve been looking for an easy to use bug tracking tool and everyone seems to rave about FogBugz, so I decided it was time to give it a shot. I’ll be sure to let you know if I decide to stick with it.

There was a short list of bugs and features that I didn’t have time for prior to the OMG Cup deadline. So, while I’m brainstorming on what the next project will be I thought I may as well try and knock some of the items off the list.

One of the top items on my list was to build Bullfrog as a Universal Binary. This turned out to be pretty easy to do, but the hard part is getting my hands on an Intel Mac so I can test the build prior to releasing it.

I’m considering the “big upgrade” from my 800Mhz Titanium PowerBook to the new MacBook Pro. But, the financially prudent approach would be to head over to the local Mac retail store and give Bullfrog a test run on a display model.

I’m also considering making the jump to submitting the game to VersionTracker and similar download sites. I’m very interested in what kind of traffic this would pull in, especially for a simple freeware game. It seems like this would be a good test and learning experience.

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.

It seems that Popcap has an “extremely prototype heavy” development process.

Some of GB’s reader comments focus on this importance of prototypes in game development and feel that all they need is a prototype in order to develop their games. While this approach may work for some, I would follow this approach with caution.

I agree that prototypes are of great value, but I am also a believer of design documents.

Not necessarily designs that specifiy how every little thing is going to be built, software development is much too fluid and organic for that.

I realize that Popcap is a casual game pupblisher; but in the case of a complex RPG, it simply can’t be built without a design document. Well, at least not a good RPG. There are too many story possiblities, event points, and interactions to just make up as you go along.

Outlining the overall story arch and connecting the important events, characters, and items that populate the game is pretty much a requirement or else you run a very high risk of forgetting something, building a non-sensical story, or even a game that can’t be won.

I think where people get caught up is thinking that a design document has to be a detailed technical design. When you are a single developer on a small project, chances are you don’t need to write everything down, because you aren’t communicating it to anyone else.

I can see the advantage of detailed technical designs in a MMOG where you really need to have detailed descriptions of the network layer and protocols, how game state will be persisted, and how game assets will be managed, maintained, and updated.

Additionally, the second you have a development team of more than one person you need some sort of design document. How else do you make sure everyone is on the same page and is developing code that will work with the rest of the system?

Writing a design document doesn’t mean that you can’t be agile or proceed in an iterative manner. It is just a tool to help ensure that you don’t forget things, a tool to help facilitate communication, and a tool to jog your memory when you return to the development of a project that you haven’t touched in months.

Yes prototypes are valuable and in some cases all you may need. But, design documents are equally important. They are both simply tools in a software developer’s tool set. It would be silly to dismiss one of the most useful tools available to you.

After a ton of work over the past month designing and programming my first Mac game, it is finally finished.

All the final artwork and animation is complete. All known bugs have been fixed. The final executable binary has been packaged and zipped.

Bullfrog has been officially entered into the 2005 OMG Cup and public voting opens December 1, 2005 at midnight.

If you’re interested in playing the final complete version of the game, you can find it on the official contest entry download page along with all the other games entered in the competition.

I would love for you to give the game a try and if you like it, please take the time to vote for it.

While you’re trying out games, why not support independent Mac game development and try out some of the other entries. There are some fantastic games waiting to be discovered. Don’t forget to rate each game you try. Who knows, you may discover a new favorite.

I haven’t posted any updates on my development progress on Bullfrog for a while. I’ve been very busy trying to get the game ready for the OMG Cup 2005 deadline of Midnight, November 28.

Once I get through the deadline, I’m planning on writing a postmortem on the development of the game. I’ve learned a ton throughout the game design and development cycle and will try and share as much of it as I can.

For now, here’s a teaser screen capture straight from game play.

Not all the final bug animations are included, but it gives you a much better peek into the final look.