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:

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:

Anyway, that’s my short history of the early Atom Zombie Smasher prototypes.  In closing, take with you this key knowledge: prototyping, do it.