Student Postmortem: Gesundheit!

By Matt Hammill [05.14.09]

 [Matt Hammill's graphically adorable 2D overhead action-puzzle game Gesundheit! was an IGF Student Showcase finalist in 2008, and in this postmortem, he discusses its creation in-depth.]

In my final term of Sheridan College's illustration program in Ontario, Canada, I took a class in which each student had to propose and develop his or her own project. While this assignment obviously had to include some illustration, the form of the final product was up to the individual.

Suggested projects included books, posters, and advertisements, but for some reason I had become obsessed with the idea of making a computer game. At first, my goal wasn't very sophisticated -- the gameplay would just be an excuse for me to animate little monsters eating each other.

A year or two earlier, I had created a few little point-and-click adventure games using Adventure Game Studio (a free engine for creating 2D King's Quest-type games), and in the summer before my final four-month term, I had been testing some action game concepts with the same engine.

When classes started, I was able to show my illustration teacher Harvey Chan, a rough prototype of the game I wanted to make, and he encouraged me to follow through with it on the condition that I give it some decent artwork. "Make it look like your drawings," he said.

With that advice, I jumped fully into production on Gesundheit!, a 2D overhead action-puzzle game with single-screen levels, hand-drawn graphics, snot-eating monsters, and a sneezing pig.

What Went Right

1. Having a one-man team.

Obviously, making a game with a team of one meant that there would be severe limits to the scope of my project. But seeing what other soloists had done with the AGS engine -- Ben "Yahtzee" Croshaw's games are a great example -- was very encouraging. Besides, I knew that Cave Story was a one-man show, and if Pixel could do it, then so could I!

In fact, there were indeed a lot of nice things about me being the entire team. I didn't have to worry about any conflicts of vision, and nobody felt like their views were being ignored. There was no miscommunication, either -- if some animation took longer than expected, I wouldn't have to explain it to a programmer.

I was lucky in that I already had a bit of experience in some useful areas. I'd lately been making pixel animations for fun. I had done some Quake mod animation back in high school, and I'd been playing and recording music with amateur rock bands for years. Also, in the making of my last point-and-click game, I began to learn the AGS scripting language.

I hadn't a clue how to make an action game, and I'd never done any real programming before, but with the help of the AGS forums, I felt I could figure it out. Besides, I didn't really have the option of working with a team. The assignment was an independent project, and my artist classmates weren't too inclined to venture into the technical sludge of making a game.

It was only after I had posted my first release of Gesundheit! -- and again later at the Independent Games Festival -- that I thought how nice it would have been to have somebody to share the process with. Knowing a programmer would have been convenient, too, but really, it never once occurred to me that my project required another person.

2. Finalizing the game mechanic first.

Because I was working alone, I couldn't afford to spend too much time on things that didn't directly serve the end product. I needed to have a simple and easy-to-make game mechanic that could provide a reasonable amount of gameplay on limited assets, because I could only generate so much artwork. Even though I originally only wanted an excuse to make graphics, I knew the gameplay had to be settled first so that I could focus on assets that would actually be needed.

I had a pretty good idea from the start about the kind of game I wanted to make. I had loved Lemmings for its cleverness, cuteness, and goriness, and I liked figuring out some of the overhead puzzles in the 2D Zelda games and God of Thunder. I was mostly thinking of those kinds of spatial puzzles when I did my first prototype, but I guess a little bit of Metal Gear Solid snuck in subconsciously.

My original build featured a sneezing character (at the time it was an old pixel drawing of my girlfriend) that shot boogers to lure snot-eating enemies through maze-like levels. The puzzles were based on line-of-sight, and the challenge was to lead the monsters through the maze into traps while keeping yourself hidden. If there were no boogers to eat, the monsters attacked.


Gameplay concepts were sketched out before coding.

I had this whole concept drawn out in my sketchbook before I began my first line of code, and although it needed to go through several iterations before I started finding the fun in it, the final gameplay is pretty faithful to my original sketches. (It no longer stars my girlfriend, though; the main character became a green pig with prominent snot-launching nostrils.)

Not being a programmer, it's hard for me to toss off gameplay tests, so I was lucky that I liked my original concept for Gesundheit! well enough to see it through production. And tweaking the gameplay, far from being a chore, was actually quite interesting and enjoyable.

3. Using the AGS engine.

Chris Jones' AGS engine was an enormous boon to my development process. Without it, there's absolutely no way Gesundheit! would exist. In fact, the only reason I began making games in the first place was because of how quickly I could pull some animation frames into the engine and see my own characters walking through crudely drawn backgrounds. It's wonderful that, thanks to engines like this, an art student like me with no technical background can put together a game.

Of course, there are limits to what AGS can do, but when I was starting Gesundheit! I had no problem with that. The low res (640x480) 2D graphics didn't bother me because it kept the sprites manageable and the download size small. The single-screen backgrounds worked fine for the line-of-sight gameplay, too, because I didn't want to worry about monsters being able to spot the player from beyond the edge of the screen. Also, AGS has a great pathfinder for point-and-click adventure games (so your hero can find his way around a table, say) and I used this extensively for both the player control and the movement of the pursuing monsters. I barely had to think about pathfinding at all when I was designing the levels.


4. Roughs, roughs, roughs!

One thing that was stressed throughout the illustration program was the importance of rough work. The idea of using quick little thumbnail sketches for problem solving was drilled into my head for over four years, so I approached the game with the same method.

My sketchbooks are full of level design drawings. The slow-paced, strategic nature of my game meant that I could roughly play through my maps, with the help of scribbling monster paths and lines-of-sight overtop of my drawings, without ever needing to turn on my computer.

Drawing on blank white paper was much faster and more fun than trying to figure out the levels pixel by pixel on the screen. There was also no pressure to hang on to bad designs because there was hardly any work invested in them in the first place! An additional bonus was that working in my sketchbook meant I could be productive even during the long bus rides to school.

As for the character graphics, using quick and dirty Microsoft Paint sprites as placeholder art early on saved loads of time in the long run. This helped me determine the size of my characters, the required list of animations and their durations, the necessary level assets, and the technical feasibility of my game, all without too much invested in art. Inevitably, there were some changes to be made even after the final assets were created, but I never had to throw out a painstakingly animated loop because it was no longer needed.


Screenshots of early builds of Gesundheit!

One more important step I took before doing my final artwork was to create a mock screenshot in Photoshop. Here I could see how the sprites and background art would look together, and I could tweak things quickly, without worrying about technical stuff. That fake screenshot became a standard for me to work toward.

I've gone through a few abandoned AGS projects where I've invested weeks into elaborate artwork only to realize that I didn't have a game to hang it on, and I wanted to avoid that this time.

5. An achievable aesthetic.

As an illustrator, making the graphics and animation was what had driven me to make the game in the first place, and after that first talk with my illustration teacher -- "Make it look like your drawings!" -- I was even more determined to keep the aesthetic at the forefront of development.


Level art was created on scratchboard and then scanned into Photoshop.

However, I was aware of the technical limits of both myself and the AGS engine, and I didn't want to aim for something I wouldn't be able to achieve. By starting with hand-drawn artwork, I could hopefully appeal to non-gamers, such as my teacher (I was still looking for a good grade!) and also offer something different to traditional gamers and the AGS community, which is mostly dominated by pixel art.

I had been doing some scratchboard drawings on plastic the year before (painting with black ink on a sheet of plastic, then using a knife to scratch white back into the ink) and I liked the unrefined messiness of it. With that as my starting point, and Photoshop for adding color, I eventually created all my characters and level art. The characters' body parts are scratchboard drawings, the shadows are ink thumbprints, and the dirty white background is a piece of unwashed board.

After deciding against MIDI music at the urging of one of my rock band friends, I tried to carry the same messy, naive aesthetic into the music, as well. It wasn't a difficult aesthetic to achieve, considering I could barely play any of the instruments I was recording, but having that goal in mind let me relax about my terrible musicianship.

What Went Wrong

1. Not learning programming first.

I had never done any programming whatsoever before starting with AGS script. I didn't know what an "int" was, and all those curly brackets and semicolons were very confusing.

Instead of spending a couple weeks going through some basic programming tutorials, I decided that I'd learn by doing, and I just jumped into scripting my game. I had the AGS help file, and as long as I could get stuff working, then what was the problem?

Everything went pretty smoothly at first, but before long my amateurishness started causing problems. The script became long, badly written, unorganized, and difficult to change. My learning process is now forever entwined in the game script, and because I wrote the core parts of the game first, it's the core parts that are the worst.

In my free time, I'm still working on expanding the game, but the scripting process is slow and painful. By investing a bit of time learning some programming before starting the game, I could have made my life a lot easier.


2. Unorganized assets.

I had no idea how many hundreds of files I would end up generating for this game when all the different working versions of animation frames, sound effects, levels, music tracks, and menu graphics -- plus the backups, finals, and final finals -- were added together. The confusingly named files are still scattered all over my hard drive, and even within AGS my asset lists make no sense.

When I began work on the game, I had a few little sprites and there was no problem remembering what was what. Soon, however, I had to start keeping other windows and programs open so I could check if the asset I'd refer to in the code was what it was supposed to be. In the script, the enemies would be labeled A or B, 1 or 2, or color-coded depending on my whims, and the level names were messes of numbers, dashes, and underscores. I was constantly telling myself that I should sit down and do a major clean-up, but I perpetually thought I was almost done and that it wouldn't be worth the effort. I was wrong in both cases.


3. Using 3D software for 2D animation.

I've described how I made my character art with a combination of scratchboard artwork and Photoshop, but for the animation I actually used a 3D program. Why use 3D software for 2D animation?

For some reason, I had become obsessed with the idea that all my characters needed to have really smooth joint bends (for example, knees and elbows) and this would be difficult in the 2D software I knew. But I thought I could make it work in a 3D program using bones. Using Anim8or (a freeware 3D program), I mapped my character art onto flat 2D polygon silhouettes of the characters, as if I were applying paint to a paper cutout. Then I built skeletons for my characters, animated them (keeping everything flat on the X-Y plane) and rendered out the animation frames from an orthographic camera. Those frames were taken back into Photoshop where they were resized and formatted for the game, and outputted once more.

Why did I go to all that trouble? Don't ask me! If I could do it again, I would have just done all my animation in After Effects or ImageReady. Going through a 3D program was a huge hassle, and since the final sprites are only something like 30 pixels tall (with elbows only a few pixels wide) the smoothness of the bends is sadly not one of the most notable features of the game.


4. Late playtesting.

Being the shy fellow I am, I was hesitant at first to let strangers play my game before it was done. I didn't mind showing classmates my work in progress, but most of them weren't gamers. Even those who were into video games seemed hesitant to critique the gameplay -- they were too kind to hurt my feelings.

By the time the game was ready for the fresh eyes of play testers, I was so close to being finished that I didn't want to wait and get really thorough feedback. The handful of AGS play testers I had gave great advice, but there were a few big things, such as the lack of keyboard controls or an aiming aid, that drove some people mad once I posted it online. As I was working on the game, I had become really good at playing it, and I didn't even notice how cruel the game was for new players. I should have gotten a broader sample of testers to give feedback earlier in the process.

I was able to add and improve some features in subsequent versions, but if I'd considered these issues early on, they could have been much easier to implement and incorporate into the rest of the game script. And I don't think it would have been hard to find testers -- my experience with the indie gaming scene is that everybody's only too willing to offer feedback.

5. Didn't research engine enough.

At the start, I was so eager to jump right into development that I didn't spend much time researching my engine. The version of AGS I used (2.72) was great, but there are Mac ports for older AGS versions that I could have taken advantage of if I'd looked into it first.

And that's only AGS. I often wonder what the game could have been like if I'd used another engine altogether. Online play? A level editor? When I started the game I never considered anything besides AGS, and realistically, features like that would probably have only bogged me down. Regardless, it would have been nice to have those options for future versions.


Good Health To You!

A lot of the problems I encountered while working on Gesundheit! are probably the most common and obvious mistakes a newbie can make, and I'm sure the game could have been done better if I'd had someone with game experience guiding me. Yet, stumbling through the process was part of the fun, so it's hard to view any of it with regret.

Doing the game for an art course was very liberating, and having an experienced illustrator give me feedback helped me push the graphics much further than I would have on my own. And it was quite a treat at the end of term to show off my own video game to the rest of the class on the school's digital projector.

Making Gesundheit! was probably the most fun I've had on a solo project. Learning stuff is cool, and I did nothing but learn the whole way through. My inner control freak loved working out everything from the scripting to the snot stains, and I'm better at the recorder than I've ever been before. As an aside, Gesundheit! was my first serious attempt at character animation. I ended up enjoying that part so much that I took a postgraduate course in the subject. I start my first job at an animation studio next week, so I guess I owe a lot to my little green pig and his smoothly bending elbows.

 Game Data

Gesundheit!

School: Sheridan College, Ontario, Canada

Development Time: 4 months in school plus 3 months part time before release

Team Size: 1 

Hardware Used: Laptop PC, Wacom tablet, USB audio mixer, instruments and art stuff

Game Engine: Adventure Game Studio

Software Used: Photoshop, Anim8tor, Cubase, MS Paint

Total Lines of Code: About 6,000

Final Project Grade: A

Download: https://www.underwaterbase.com/

Return to the web version of this article
Copyright © UBM TechWeb