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.

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.

In Part 2 of this series of articles, I presented Jordan Langille‘s initial sketch for the application icon for Bullfrog. His first try was dead on with what I was looking for.

After approving the sketch, Jordan set off to create the initial version of the icon graphic. A week later, Jordan came back with his first attempt at rendering the sketch into actual icon ready art.

I found this version to be a great conversion from his original sketch, but not perfect. I wanted some changes made.

Here are the exact comments I sent back to Jordan.

Looks pretty good. I like the eyes, the back legs and feet very much.

A couple of changes though:

The front two legs look strange to me. They don’t look like they are in the right perspective. They also look like they aren’t quite long enough, like they aren’t really reaching the ground.

The frog’s face and the center point between the front legs don’t quite line up either.

Also his left back leg and left front leg are too close together when the graphic is smaller. They look like they merge together. Maybe some space between them?

Also it looks like he’s resting on his butt instead of squatting on his hind legs. The heel on the right back leg gives me this impression.

Twenty-three hours later, I received an updated version.

Perfect! The front legs and eyes are now lined up. The frog now looks like he’s resting on his legs instead of his backside. Jordan also made the whole frog skinnier, which made the whole image look a bit more balanced.

The next step, creating a Mac .icns file that can be linked with the compiled binary of Bullfrog. Once that is completed, Jordan will attack the artwork for the in-game animated sprites.

This morning, Jordan Langille delivered his sketch for the Bullfrog application icon. He was able to create what I had in mind on his first try. Now, he’s working on turning the sketch into an actual application icon.

I set Jordan to work on the application icon first, because I felt having the icon to display on the product page would be helpful for marketing purposes. You know, first impressions and everything.

Once we have the application icon designed and finalized, we’ll start working on the in game graphics. Ideally, I’d like to have the game artwork match the icon in style and feel.

Ari Feldman has produced a collection of free static and animated graphics (or sprites), called SpriteLib, that can be used freely by anyone in their games as long as they adhere to the Common Public License.

Seems like a good resource for “developer art” during game engine development and prototyping.