Atom Zombie Primordial Soup
I gave a talk at GDC this year: “Nuke it From Orbit: The Making of Atom Zombie Smasher”. During the talk, I showed some footage from early prototype versions of the game. Here’s a short video of a very early iteration of Atom Zombie Smasher:
Controls
At the time, the primary platform was the Xbox360. The controls were:
- X = artillery strike.
- Y = carpet bomb.
- B = napalm bomb.
- A (tap) = move infantry.
- A (hold) = call helicopter.
- Left stick = move cursor.
One of my goals was to make the controls easy enough to learn in a few seconds, so I intentionally avoided using the triggers, bumpers, d-pad, and right stick. Although AZS later transitioned to PC/Mac/Linux, the game retained its approach to controls, in that all the player really needs is a 2-button mouse (there are some keyboard shortcuts, but they consist of secondary and tertiary commands not required to play the game).
On an unrelated note, my favorite playtesting feedback was that my napalm bomb fire effect “looked like cauliflower.” If I received this feedback more often, I probably would’ve kept the napalm bomb in the final game (or, make the game all about vegetables).
Gameplay
My first attempt at AZS (prior to this video recording) had a different victory condition. If this video is 1.0, let’s call its predecessor version 0.1.
In 0.1, the goal was to wipe out all zombies within a set time limit. At your disposal was a variety of bombs, airstrikes, and other miscellaneous explosives. There’s something compelling about the idea of creating a human firebreak, and I felt that this victory condition fit that idea perfectly.
But, what you see in your head doesn’t always survive translation to what you see on the screen. That’s why implementation and prototyping is so important to me. I implemented the “destroy all zombies” game in 0.1, and immediately didn’t like it for various reasons:
It was too fast-paced and twitchy. The infectious chain reactions were fun to see, but when your job was to destroy all the zombies, it made the game feel too chaotic & messy.
It got tedious. It was satisfying to wipe out large swathes of zombies, but chasing down those last stragglers at the end of the level was awful.
It was too easy to reach that “point of no return” limbo state where you’re unsure whether the level is still winnable or not.
I hate time limits.
I recognized potential in the zombie infection mechanic, but needed to tweak something to make the game work. After some thought, I started playing around with a roving King of the Hill scenario, where you had to defend randomly-chosen “rescue zone” hotspots. Every X seconds the hotspot would randomly roam to a new spot, and your job was to make sure the zombies wouldn’t overrun that spot.
That worked well, but I had some problems with the mechanic. The main problem was that I had to make the hotspot chooser reasonably smart. Instead of just randomly picking any spot, I had to make sure the spot was a reasonable place. When random generation is in the mix, I think it’s easy for a game to feel unfair. If the random hotspot chooser constantly chose awkward or difficult spots, that would be a shelf moment for me - the moment I put the game on the shelf and never play it again. So, I had to find a spot that had people to rescue, not too many zombies, didn’t have incoming bombs, etc. The AI brain required to handle this was rapidly growing out of my control.
Then I thought, “why not let the player just manually place the hotspot?” It was a duh-doy moment. Instead of making some wacky AI brain to handle this system, I let a wacky human brain handle it. This became the helicopter rescue mechanic, and ended up in the final version.
Et al
This prototype shed light on a lot of gameplay miscellanea:
Like the last straggler zombies in 0.1, it was now sometimes tedious to rescue those last straggler humans in 1.0 - levels were ending with a whimper, not a bang. Eventually I put in the day-night cycle, where zombies start pouring in from every which way during the evening. This served as an “apocalypse timer” in which levels were nigh-guaranteed to not drag on. And it made levels end with a lovely bang.
Having the same four weapons every level got old fast. This led way to the randomized monthly mercenary roster.
Buildings were intended to serve as level design chokepoints. But the spaces between buildings were so wide that they were basically useless. This eventually led to the constricted streets and alleys in the final game.
For storyline purposes, there were some levels where you were aided by Cpl. Tabajaras and his Howling Commandos, an AI-driven infantry squad that ran around the map shooting zombies. This is one thing I wish I had kept around. It always made me laugh when they’d walk straight into your falling bombs.
Anyway, that’s my short history of the early Atom Zombie Smasher prototypes. In closing, take with you this key knowledge: prototyping, do it.