iDevGames

BugThug is the first game I have completed since nine years ago. In that time frame I had gotten very close to completing a game for Mac OS 9, but got caught up in the transition to Mac OS X and had a lot of dead technologies with which I was very familiar. Fast forward to 2004, and I was working on my uDevGames 2003 entry privately. Seeing the entries so far, and reading the rules for this year’s uDevGames, I decided I should enter in the hopes of providing a simple SpriteWorld demo for people to learn from. I dropped what I was doing in the game I was working on before and during the first half of the contest, and dove right into BugThug. In hindsight, it was a very good decision for me.

What Went Right

Keeping It Simple

At last I have learned my lesson! It may not be the best or most elaborate game I’ve done, but it is a completed game. In retrospect, BugThug suffered from feature bloat and relentless rewrites in the hope of perfection in my eyes as much as any other game I’ve tackled. The key difference here is that it started almost painfully simple, where my other games were ambitious from the start. Also, the strict deadline played an important role in limiting what features I’d allow myself to pursue.

Keeping Fluid

BugThug has always had a brief design document; however, it changed a lot and I didn’t hold myself to it. While this normally would be a fatal mistake, it actually turned out to be wonderful in my circumstances.

It started off as a simple game where you had to hold the button for as long as you could. This evolved into a moving button that moved more quickly each level. In fact, the only reason that happened is because I wasn’t very clear on the rules of the contest, and thought the game needed to have three playable levels. If it hadn’t been for that, BugThug would have been a weekend project like it was originally intended to be.

From there, I just kept tinkering with the way the bugs would move and react to being pinched. Even though I have been referring to the game as BugThug, at this point it was still called Stamina 2004, my original title for it. Jennifer and I arrived at the final title by means of a large brainstorming session. After that point, I also had a more complete idea of the gameplay in mind. There would be large antagonist bugs that would act against your prized cute little bugs, and you would guide the bugs into power-ups of different effects. Already this was a far cry from “Hold The Button.”

Listening to Selected Advice

After I had a decent playable uploaded, I contacted Daniel Labriet of DanLabGames fame. I don’t think I can thank him enough for sparking BugThug into an entirely new direction! Basically, he introduced two big things into BugThug.

The first thing he introduced was the world of “cute.” The bugs that I had haphazardly drawn in Illustrator lacked personality and spark.

Before

After “The DanLab Effect”

Luckily, Dan said it was okay for me to use the bug he made in BugThug! The second main thing he said brought to my attention the importance of colors in a game. Different colors should represent different “zones.” There were two zones in the game of BugThug: the safe inner circle, and the danger zone outside of it.

These two key comments sent me on a creative rampage that eventually led me to redo practically all of the graphics to what you see now. As time was running short, I contacted my good friend Matt Gravelle to make some power-up graphics and a new pincher for the ideas I had. He came up with some great stuff and fitted them into my existing style very well.

Testing!

Throughout the entire development of BugThug, I made time to test on as many different configurations of Macs as I could. This even involved stress testing the “engine” on my laptop. The results were very good, and slightly frightening at times, as you can see.

Testing proved to be very beneficial as it helped me keep the system requirements for BugThug very low. Additionally, it helped me have a firmer idea of what those system requirements were. I am glad that I took away from time that I could have spent adding bells and whistles to BugThug. I believe it resulted in a more professional finished product.

What Went Wrong

Polish Before Gameplay

While I was spending time developing and tweaking the graphics and sound, the gameplay still remained very primitive. There are two ways I could look at this. In one respect, it prevented me from playing the game more than developing it! On the other hand, BugThug didn’t become what I would call “fun” until very late in the contest. I think a greater focus on making the game fun would have been more beneficial than tinkering with graphics, some of which never even made it to the final version.

Audio

I have had a lot of formal musical training, and consider it an important part of my life. This meant that overlooking music and audio in BugThug was not an option for me. A lot of work went into contriving a music style for the game and recording loads of sound effects with Jennifer. Although I think the end auditory experience was satisfactory, I believe it could be improved a lot. My budget for this game was practically zero besides the things I already had prior to the start of the contest, but I think I could have benefited from purchasing a decent microphone and USB audio interface. I ran into more limitations in this field than anywhere else. The sound effects are audibly dead solely due to the manner in which they were recorded. Better equipment would have done the sound effects artist, Jennifer, a lot more justice. I thank her for putting up with inferior equipment!

In addition to limitations in the sound effects department, I had to severely limit myself when composing BugThug’s music. I would have much preferred to have written some sheet music and gone out and recorded with some friendly musicians playing my music. This wasn’t an option. Instead I wrote music that I felt I could make sound decent using the tools I had available. I had purchased GarageBand and a SoundFont Synth plug-in for it that would allow me to use freely available SoundFonts more easily with GarageBand. That gets me by, but is limiting due in large part to performance problems with GarageBand. A budget that would allow recording of professional musicians, or at least better software tools that would not be so restrictive, would have allowed me to unleash my full creativity in the audio department. I feel that the audio of BugThug is not nearly the best I can do, and look forward to giving it another shot in future games.

Communication

I think there is a lot more communication in a game than people realize and amateur developers should pay attention to it. I took every comment about BugThug that I received into consideration. If someone didn’t understand the rules to play the game, I took that as my fault for not communicating them well enough. I would not blame the user for choosing not to decipher my arcane ReadMe file. This resulted in many revisions of the in-game help section, and also in confronting the player with the help screen the first time a game was played. I believe my considerable efforts were successful. The vast majority of people seemed to be able to figure out how to play the game. I feel that is very impressive considering how original of a game BugThug is. However, I would like to emphasize that this was a very long road. I learned the hard way many things not to do. Words are easy to skip over, but a quick picture or diagram can convey a message sometimes whether you want to skip over it or not. If I make another game, I feel that now I will be better equipped in this area to convey some basic knowledge requirements about the game to the players.

Download Format

After the voting started, I started hearing a few complaints that BugThug wasn’t downloading properly. It turns out both of the servers I was using didn’t recognize .dmg.gz and would call it “text/html.” On some people’s web browsers this made the download open up in a browser window instead of saving to disk. To help, I had to quickly provide a workaround to people. This wasn’t a very good solution. I should probably have switched it to .dmg.tar.gz. Even though it is redundant, it would have worked around the problem. This also could have been solved by having more control over the systems the file was hosted on.

Starting Late

Six weeks is not a lot of time to make a complete game. I have a lot of ideas for things to add on to BugThug. These are some of the more obvious ones: highscores, Internet highscores, difficulty levels, more power-ups, “bonus” levels, and different game modes. I think that with six more weeks of development time, those could have all been implemented. In retrospect, some sound like large headaches and I’m glad that I didn’t have time to try! However, I feel that I would have been able to add another level of professionalism and quality to BugThug had I given myself more time.

Notes From Other Team Members

Jennifer Stavseth: Game Play Design and Sound Design

Jon wanted to make a game in a weekend. It started as a “hold the button” style game and slowly progressed from there. He was worried that he needed three levels of gameplay, which is hard to do with just holding a button (originally for as long as possible: hours, days, weeks, whatever). Having three levels of that would be silly. With discussion it progressed to a moving button that would change direction and speed. A button is strange to be holding down, so from there I suggested a bug. Jon wanted to go all out on the bug design, but I reminded him that it could be simple and still get the same effect across. (I wanted to prevent another runaway game.) After a quick sketch on the white board, we came up with the original ladybug. From there it changed from holding the bug and trying to slow it down to controlling the bug and preventing it from escaping.

The next challenge was coming up with the appropriate sounds that a bug should make. Jon would ask for a certain sound he would like (e.g. scared bug) and I would be required to come up with the sound. Usually one recording was made of several possible sounds, slowly progressing and changing (pitch, tone, etc). From this main recording the most ideal sound was picked and modified as needed. Hence I became the voice of BugThug, from the smallest scared bug to the roaring monster ones.

Conclusion

Now that the contest is over, I can see that I learned a great deal in entering uDevGames. I feel that above all things, I have become more confident about knowing what exactly it takes to finish a game. I now have more of an idea of what things on paper are “extras” for a game, and what should be focused on. I congratulate all who entered uDevGames, and look forward to seeing everyone’s uDevGames 2005 entry!

• Genre: Arcade
• Developer: Jonathan Czeck
• Url:
• Team size: 1
• Released date: Fall 2004
• Project length: 6 weeks
• Development hardware: iBook G4
• Critical applications: Xcode, GarageBand, SoundFont Synth, SubEthaEdit, Sound Studio, Adobe Photoshop, Adobe Illustrator

• Main APIs: Carbon, SpriteWorld