GnomeSpy Postmortem

James DessartMay 13, 2009

Taking Advice From a Veteran Programmer

When I read that uDevGames was happening again this year, I got excited. I had just read an interview with a successful casual games developer about how he achieved his success. It gave me some ideas, and one of them blossomed into GnomeSpy.

Following the advice in Justin Ficarrotta’s article on A uDevGames 2008 Survival Guide , I wrote up a prototype using Cocoa through Xcode. I play-tested GnomeSpy internally until the gameplay reached a certain level of fun, then released the prototype to iDevGames’ forum members. Along with play-testing by friends and family, this provided an invaluable resource for determining reasonable completion times for the basic six-color game.

The entire project was my own work, and used no code written prior to the contest. It felt like the best way to adhere to the spirit of the contest, and besides, it gave me a nice challenge.

I spent a lot of time thinking about the game and how to make it enjoyable. Some of that time was spent drawing up character sketches, and some was spent hashing out the game play. I spent very little time on sound design, since it’s not one of my strong suits.

Writing a Game in Xcode

Since I planned to write the entire game in Objective-C using Cocoa, my main development tool was Xcode. I’ve been working in OOP languages for years now, and professionally for the past decade or so. It seemed like the best choice to me for rapid development, especially since I was already familiar with the toolset.

Art creation with an old standby

One of my primary design tools was one of the oldest: pencil and paper. I’ve always found it works well for me, and it feels comfortable. Despite having used computers for the past 20 years, it’s always a pad of paper and pencil I reach for when an idea strikes me. Being more familiar with producing pixel art than more complex computer art, I used GraphicConverter to put together my graphics. With its highest magnification setting, it serves me well when pushing around individual pixels.

Retro audio with SFXR

I wanted a kind of retro sound effects feel, and so I pulled out a fun little tool I found when poking about one day. Called cfxr, it’s a Mac port of another tool named sfxr. It lets you create sounds using the old attack-sustain-decay envelope parameters, along with various modulation parameters and a choice of the good old basic waveforms.

I used GarageBand to toss together a couple of small ditties for winning, losing and an intro. I’ve got an M-Audio keyboard so it made it relatively easy to key up the songs, and then fix some of the timing in GarageBand — my piano playing is rusty, at best.

What Went Right

Good design process

Doing everything myself meant I didn’t have to wait on others for project components — it can be stressful when a contributor isn’t working to schedule. One of the most helpful aspects of development for me was starting early with the ideas and design. I love designing all sorts of things, and I find it’s one of the things I do best. This is where the pencil and paper came in handy. It allowed me to work out ideas ahead of time rather than implementing them first and regretting them later.

The design process helped me identify features that would work well to improve the overall enjoyment of the game. While I didn’t implement all my design ideas, keeping those ideas in mind helped keep my code as reusable as possible. In the future, when I continue work on GnomeSpy, I’ll be able to leverage that reusability to keep development times short.

Prototype to the rescue

Having a prototype early on helped spur me on as the contest progressed. It also allowed me to receive valuable feedback from a variety of potential players, and hash out the gameplay mechanics — some early bugs were eliminated due to user testing, which helped immensely.

The code from the prototype was reused in the final product, as well, which helped simplify the development process even more. In application development it’s important to realize that any code you write may end up being used in the shipping software, even if it was in the prototype. I usually code clean to begin with, and it helped me keep as much of the prototype as possible. Having a solid base to work from is always good!

Despite receiving some negative reviews, I felt the graphics worked well. It helped to have sketches on paper, since that made it easier to translate into pixels than it would have been to start fresh. My art skills work best on paper, and so using that strength was definitely the right way to go.

Objective-C makes an impact

Using Objective-C and Cocoa allowed me to complete my project as quickly as possible. While not typically a game engine development toolset, they still helped reduce UI code, as I made extensive use of Cocoa bindings for the UI elements. I’m not particularly fond of writing boiler-plate code, although I imagine frameworks specific to game development might have similar features for a more game-like UI.

K.I.S.S.

Keeping the game concept simple allowed me to budget my time and manage the game’s schedule. There was plenty of time to implement all the design elements I had come up with, if not the drive to see them through to completion. Overall, I never let feature creep set in, since I had a concrete, specific design in mind. The simplicity of the game helped to prevent a ballooning of features and extra material to develop.

What Went Wrong

Motivation

My biggest problem was pushing myself to work on the game. I let other concerns distract me from the actual act of sitting down to put my nose to the grind-stone — it’s something I have to work on. When I did spend time on my project, I let graphics development overshadow coding. I much prefer fiddling with a pencil and paper than writing features I’m feeling overwhelmed thinking about.

These two problems led to me leaving out some key features that would have given the game a better chance at winning, as well as improving the game’s enjoyability. Specifically I had planned to have different scenarios, such as a training mode and a story mode, each with its own levels. Some of the code I started on is still in the source package, mostly limited to header files.

Eye candy wanted

While working on my own allowed me the freedom to set my own schedule, it also left me carrying the whole burden. The graphics could have been better if a more skilled artist had worked on them, and I have no doubt that there are better sound designers than me out there. It would have kept me focused on core development, rather than giving me an excuse to do work on some more enjoyable aspect of the game.

Last minute sound

The sound components were thrown together at the last minute, a day or two before the entry deadline. This left me scrambling to find a decent API for playing those sounds, and I eventually went with NSSound. So not only were my sounds and music rather primitive and jarring, they could not properly overlap. One sound starting to play would cut out another that was already playing, sometimes dropping certain game sounds almost entirely.

Conclusion

In the future, I think working with other team members would be beneficial. It would allow contributions by people with more skill in certain areas, while freeing up my time for coding the game. Most likely having other team members would give me more drive to produce a better, more polished game. Sitting all alone on your own makes it hard to stay motivated.

Spending time putting together a solid design, and a clean prototype will always help reduce the amount of time spent actually implementing software. Combine those with rapid development tools and you have some of the key components to producing the right software the first time, on time. My design ideas would have been great, had they been implemented. Trusting my design instincts has never been a problem for me, and they tend to serve me well.

It would be great if I could find a way to push myself when I’m feeling unmotivated. So far I’ve had a lot of trouble with that, and it’s been one of my biggest issues in all sorts of projects. What kind of solutions can I find? I don’t really know. I’ve been asking myself that question for years. A deadline helps, and someone else excited about the project can definitely give me a bit of a push. Ideally that motivation needs to come from within, so that’s definitely something I should look at cultivating.

All in all, I’ve found the experience positive. I pulled together a game within an alloted period of time, and while it has some rough edges, it’s something I can be proud of. If another uDevGames appears on the horizon, I’d be happy to enter again

  • Developer: James Dessart
  • Game Title: GnomeSpy
  • Genre: Arcade
  • Team Size: 1
  • Development Hardware: iMac Core Duo, M-Audio MIDI Keyboard
  • API: Cocoa
  • Critical Software: Xcode, GraphicConverter, GarageBand