Monthly Archives: December 2005

Post navigation

There is a lot more to making a casual game than most people realize. I learned this first hand recently, as I participated in the 2005 OMG Cup these past two months. I always believed casual games were simple and quick to develop. Compared to the modern enourmous budget A-list first person shooter games, I guess they are — but for a one person development shop it’s still a lot of hard work.

I love when developers allow the outside world to see how their games were built. Sharing knowledge is what the internet is about. In this case, Phil not only shows us the artwork that made it into the game, but also the artwork that was rejected.

Phil also discloses his method for deciding on what theme his word game should use. It’s very interesting to see the numbers behind his survey and what themes people liked or not. I had not thought of surveying blog readers for their opinion on game design directions.

But, why not? Readers would probably be a ready and usually willing participant in the process. After all, readers are already participating by visiting your site. By allowing readers to join the design process, they get a small stake in the success of the game and may be more apt to purchase and spread the word.

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.

Memory management in Cocoa & Objective-C tends to be confusing at times, especially when trapping and handling errors. Chris Hanson has written a nice article describing the basics of memory managment and error handling with @try, @catch, and @finally code blocks.

In Part 3 of this series on the artwork behind Bullfrog, I revealed the revisions leading up to the final version of the Bullfrog application icon.

For Part 4 of the series, I originally planned to begin taking you through step by step as I worked with my artist, Jordan Langille to specify and refine the game artwork while we actually did it. Unfortunately, development time was at a premium during the six week game programming contest, the 2005 OMG Cup. So, instead I’m going to give you a higher level overview of the project in retrospect.

When I first asked Jordan to produce the artwork for the video game, I only had a rough idea of what I was going to need. I didn’t really have the engine to a point that I could give him very many specifics. So as I stated in the first part of this series, I set Jordan on the task of designing the Bullfrog application icon.

While Jordan was working on the icon, I focused my development efforts on getting the sprite rendering code to a stage where I could know how many animation frames I would need and in what sizes.

Thankfully, my code reached this point about the same time that Jordan finished the application icon. So I was able to give him a list of the six bugs that were going to be included in the OMG Cup version of the game. I also requested animation artwork for the main character, a Bullfrog.

Here is a list of the sprites I requested:

Gnat [16×16]

Mosquito [16×16]

Horsefly [32×32]

Bee [32×32]

Dragonfly [64×64]

Butterfly [64×64]

Bullfrog [64×64]

As it turns out, none of these sizes were final and like most things in software development projects, the requirements changed. Thankfully, Jordan was patient enough with me to push through the changes and produce some great animations.

To help me program the rendering and animation engine, I first created temporary animated sprites for the frog and for the gnat. Instead of wasting effort with temporary art for all the bugs, I just reused the gnat artwork in various sizes to distingquish each bug. For reference, here is a single frame from each:

Following my refined specifications, Jordan produced the following animated sprites:

Jordan also convinced me that we shouldn’t settle for the plain black background I had originally planned. He put together the background shown in this in-game screen shot:

That about wraps up the artwork behind Bullfrog. Keep yours eyes peeled for a full postmortem of the entire game development project in the coming weeks.