Archive for category atom zombie smasher

Date: March 20th, 2012
Cate: atom zombie smasher, development
3 msgs

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.

Date: September 13th, 2011
Cate: atom zombie smasher, patch
Comments Off on Atom Zombie Smasher v1.89 released

Atom Zombie Smasher v1.89 released

Version 1.89 of Atom Zombie Smasher is now available!

A lot of people asked for the UI to accommodate any arbitrary amount of mercenaries. Previously, the merc buttons would just continue off the edge of the screen and be inaccessible. I updated the system to detect this overflow and make a new row of merc buttons. Here’s a shot of how it looks:

Here’s the full changelog:

– Gameplay: when no more zombie territories, humans win.
– UI: merc control bar now accommodates any arbitrary amount.
– UI: can press ESC to skip Territory Score screen.
– UI: can press ESC to skip New Outbreaks screen.
– UI: can press left/right to select upgradeable mercs.
– UI: can press Enter for Yes/No popups.
– UI: fixed Player 2 artillery cursor mixup.
– UI: added loading animation to File Share menu.
– UI: added URL tooltip in Behind the Scenes.
– UI: vid. resolution menu now shows current resolution.
– UI: helicopter name limited to 23 chars.
– UI: add help message for bad profiles.
– Mods: removed empty mods from database.
– Fix: custom resolutions are now saved.
– Fix: fix crash in Zed Bait.
– Fix: fix crash in Twitter feed.
– Debug: PAX Demo functionality.

The Steam version will auto-update. For non-Steam versions, grab the patch here:

http://blendogames.com/atomzombiesmasher/help.htm

 

Date: August 20th, 2011
Cate: atom zombie smasher, development
2 msgs

Atom Zombie Tech

A fair amount of people have been asking me about the tech used in Atom Zombie Smasher, so I thought I’d make a writeup.  It boils down to three main components: SFML, Mono, and something I call BlendoEngine.

SFML

The Simple and Fast Multimedia Library provides low-level calls to your system’s audio, input, and graphics.  It’s actively being developed, is cross-platform, and is very lean.

Here’s a quick ‘n dirty example of how a sound file is loaded and played in SFML:

SoundBuffer dogbarkBuffer = new SoundBuffer("bark.wav");
Sound dogSound = new Sound();
dogSound.SoundBuffer = dogbarkBuffer;
dogSound.Play();

SFML excels at 2D rendering, but also does 3D, assuming you’re comfortable with OpenGL calls.  This is my first time with OpenGL, so the most I could muster up with my piddly graphics programming was basic rectangles (buildings, people) and square planes (particles, helicopter).

I use the C# (.Net) variant of SFML, simply because I find the C# language friendly and accessible, and I like its IDE (I use MS Visual C# 2008 Express Edition).  The downside of .Net is porting to non-Windows platforms.  This is where Mono comes in.

Mono

In order for my C# games to work on Mac and Linux, I use Mono. Programs written in .Net can only run on Windows machines. Mono is a framework that enables programs written in .Net to go cross-platform.

A Mono compiler (GMCS) is included in the Mono download package. I use this compiler to make a Mono-compatible executable; this is what the user executes to run the game. I also include the necessary Mono libraries in the game folder, so the user does not need to install Mono into their system folders.

BlendoEngine

This is the framework that handles “everything else” – gameplay code, UI, resource management.  It originated with my first title Flotilla (XNA 3.1), and was further developed and used in Air Forte (SFML 1.5) and Atom Zombie Smasher (SFML 1.6).

BlendoEngine is made up of “manager” components. While SFML provides low-level audio/input/graphics calls, my managers give me a way to more effectively access and utilize these calls.  Here’s some of them:

ScreenManager

A game consists of a series of “screens.” Screen examples: the Report-a-Bug screen, the end-of-mission screen, the cityscape screen.   These screens are placed on a stack; the top-most screen is considered in-focus and is the only one who receives user input.  When a screen is done, it just needs to call “this.ExitScreen()” and the ScreenManager will remove it from the stack.

AudioManager

This handles music and sound effects. It is loosely based on Doom3’s sound shader system, though their system has magnitudes more functionality.

Sounds are not called via their filenames, they are called via their sound shader (go to atomzombiesmasher/data/content/data to see the shaders or click here to see an online copy). The AudioManager randomly selects an audio file from the shader.  A record of its playback history is kept, so as to ensure you won’t hear the same sound bite repeated again until it has exhausted the entire pool.

For my next iteration I plan to add more parameters, things such as pitch, volume, and randomization weighting.

And the rest

There’s quite a bit more – InputManager, DrawManager, StorageManager, ConsoleManager, UI system, etc.  What I love the most is that with each new project, this engine framework gets more robust; the time between starting the project and starting actual gameplay code gets shorter and shorter.

Lessons Learned

Random technical gotchas learned over the years:

Mono on PC

For Atom Zombie Smasher I made the decision to make all three platforms (PC, Mac, Linux) use Mono, for the sake of keeping all the builds and save files consistent. However, on some specific system configurations, my PC Mono build refuses to start. I still can’t figure out what causes that. In the meantime, using the .Net build resolves it.

Where are you?

Not only is it important to know system specs, you sometimes gotta know what country it is. To separate numbers, some countries use periods. Some countries use commas. This screwed up all sorts of things, including the version updater (i.e. “1.21” was being interpreted as “1,21”).

File Locations

There are warring camps who disagree on where savefiles & settings should be kept (here is what I ended up using).  Barring some official decree, for the PC build of my next project, I think “My Documents\My Games” is a more reasonable location.

Modularity

I found it important (and sometimes difficult) to keep a clear distinction between gameplay code and system (audio/input/graphics) code.  If you ever want to port over to a different library (i.e. XNA to SFML), keeping your library-specific code isolated in set areas makes the job much easier.

 

Date: July 14th, 2011
Cate: atom zombie smasher, patch
2 msgs

Atom Zombie Smasher v1.84 update

Atom Zombie Smasher v1.84 is now live. As requested, lots of gameplay and UI tweaks, and several stability fixes as well.

– Gameplay: Chooser gamemode no longer scrambles merc lineup.
– Gameplay: landmines now respect user’s gamespeed.
– UI: middle mouse click now opens Merc Chooser window.
– UI: Alt+Enter now toggles fullscreen/windowed.
– UI: added option to quit without saving.
– UI: added social feed.
– UI: added More Games menu.
– UI: increased Report-a-Bug window size.
– UI: campaign log export now includes hours/minutes in filename.
– System: Disable joysticks with “-joystick 0” command line.
– System: Disable sound with “-sound 0” command line.
– System: Added telemetry system.
– Fix: crash in 3D renderer.
– Fix: crash in region generation.
– Fix: crash in newsletter page.
– Fix: crash with empty mod names.
– Fix: crash in music system.
– Fix: crash in pathfinder.
– Fix: crash in text renderer.

 

The Steam build will auto update. The non-Steam patch can be grabbed at: http://blendogames.com/atomzombiesmasher/help.htm#versions

Date: May 16th, 2011
Cate: atom zombie smasher, patch
Comments Off on Atom Zombie Smasher v1.82 update

Atom Zombie Smasher v1.82 update

Atom Zombie Smasher v1.82 update is now available! The new goodie in this update is the hotkey UI. A number hovers above each mercenary, buy displaying their respective hotkey.

1.82 changelog

  • UI: added “Hotkey UI” to display hotkey numbers on mercenaries.
  • Mods: particle effect color when helicopter gathers civilians (HELI_GATHERCOLOR)
  • Mods: particle effect color when Zed Bait gathers zombies (NECTAR_GATHERCOLOR)
  • Fix: crash in cityscape UI renderer.
  • Fix: fixed bugs in territory generator.
     

    The Steam patch is now live. The non-Steam patch is available: here

  • Date: May 9th, 2011
    Cate: atom zombie smasher, patch
    Comments Off on Atom Zombie Smasher v1.81 patch

    Atom Zombie Smasher v1.81 patch

    The Atom Zombie Smasher v1.81 patch is now available! Check out the Behind the Scenes feature in the Extras page.

    • Mods: parameter for controlling how often zombies chase humans (ZOMBIE_CHASECHANCE)
    • Extras: added Behind the Scenes page.
    • Extras: added Version History page.
    • Extras: added Newsletter page.
    • Fix: fixed mystery dynamite appearing at 0, check 0 position.
    • Fix: crash in dynamite detonation.
    • Fix: crash in texture renderer.

     

    The Steam patch is live! Get the non-Steam patch here.

    Date: May 3rd, 2011
    Cate: atom zombie smasher, development
    16 msgs

    How Braaaains Work

    Some time ago someone asked me how AI is implemented in Atom Zombie Smasher. So, here’s a short writeup on it.

    Braaaains 1

    In my first attempt at zombie AI, they began as mindless automatons. Here’s how they first worked:

    1. Find a random place to walk to.
    2. Walk there.

     

    That’s what zombies do, right? They like to take walks. It looks disgustingly simple, but was surprisingly effective. The zombies spread across the map in a fairly natural-looking way.

    A problem arose when the human population dwindled down to very small amounts. When just a few civilians were left, the game became awkward. These last holdouts had an extremely good chance of surviving for a very long time, due to how zombie wandering was left completely up to random chance.

    As a result, the finale of a map tended to drag in an anticlimactic way.

    Braaaains 2

    For my next attempt, I tweaked the zombie AI:

    1. Select a random civilian.
    2. Walk to that civilian’s position.

     

    Zombies were transformed into extremely efficient civilian-hunting machines. This fixed the problem of map finales dragging on – when just a few humans were left, they were promptly devoured.

    A new problem arose: the game was now nigh-impossible. Once a chain-reaction infection starts, it’s difficult to stop.  Due to how these new hunter-zombie powerhouses behaved, these chain reactions were now happening from the moment you started the map to the time you stopped. Furthermore, the cold efficiency in which they behaved was more akin to a special weapons team rather than rumpled zombies.

    Braaaains 3

    For my third (and final) version of the zombie AI, I combined the above two systems together:

    1. Zombie makes a random decision:
    2. 25% chance the zombie hunts a random civilian.
    3. 75% chance the zombie wanders the map randomly.

     

    This achieved the “rrgghh, brains!!” mindless behavior expected of zombies, but also ensured civilians were getting eaten at a reliable rate.

    But really: implementing zombie behavior is a bit of a cheat. One of the nice things about zombies is that if they behave stupidly, it’s generally accepted – after all, they’re zombies. A zombie is expected to act like a drunk fella, aimlessly stumbling around and making questionable decisions.

    The hard part was implementing believable civilian AI.

    Civ Brain

    Civilians are the currency in the AZS world: the more civilians you save, the better. As a result of that, it was important that civilians were fairly capable of self-preservation. Here’s what runs through a civilian’s brain:

    1. If I’m near a zombie, run away from it.
    2. If I’m in range of a rescue helicopter, run toward it.

     

    Civilians get a “panic” speed boost when running away from zombies, allowing them to outrun pursuers. During this panic state, civilians wear blinders – they run toward their destination with complete disregard for their safety. As a result, a panicked human during the beginning of a zombie outbreak has a good chance of surviving; panicking during the peak of an outbreak, not so much.

    An unintended effect of this speed boost was that the little civilian dots were given a wonderful little personality. On screen, you see a civilian dot wander near a zombie and high-tail it the other way at a sprinting pace. The abstracted visuals make it easy to fill in the blanks – you can imagine the civilian’s surprise at seeing the zombie, the crazy flailing-arms as they run away screaming, having no idea what street they’ve ended up on.

    Et al

    I find AI to be one of most difficult parts of game development. It’s very demanding on both a technical and design level.  AI is not my strong point, so AZS mostly designs around that – zombies are not expected to be intelligent, and civilians are prone to panic & hysteria during the end of the world.

    Games with good AI are rare finds. But when a game nails the AI, it makes a world of difference.  The Halo games are good examples of this.

    I’ll end this with a bot for Quake II that I thought was particularly clever, the Eraser Bot. Basically, the Eraser Bot learns from players. As you run around the map, you drop an invisible “popcorn trail” wherever you go. The bot then uses this data for its pathfinding. As you play more, you generate more path data, making the bots “smarter.” They begin to hunt you down with ruthless efficiency, taking unexpected shortcuts and sticking crazy trick jumps.

    Maybe I’m just terrible at shooters, but I found the bot’s effectiveness to be pretty frightening!

    Date: May 2nd, 2011
    Cate: atom zombie smasher, patch
    Comments Off on Atom Zombie Smasher v1.79 patch

    Atom Zombie Smasher v1.79 patch

    Atom Zombie Smasher v1.79 is now available! Lots of miscellaneous tweaks requested by various folks.

    v1.79 changelog:

    – Gameplay: fixed conflict between Elephantbird and Chooser gamemode.
    – Mods: Reload mod data button is now backslash (Steam version)
    – UI: added option to turn off tutorial tips.
    – UI: Improved the Fileshare’s scrollbar.
    – UI: Catbird was mistakenly labeled Elephantbird.
    – Fix: joystick now only updates if more than one player is enabled.

     

    The Steam version is now live. The non-Steam patch can be grabbed here.

    Date: April 25th, 2011
    Cate: atom zombie smasher, patch
    Comments Off on Atom Zombie Smasher v1.77 patch

    Atom Zombie Smasher v1.77 patch

    Atom Zombie Smasher version 1.77 patch is now available. This patch includes a new gamemode, “Chooser”, where you choose which mercs to bring along. Here’s a screenshot of how the Chooser interface looks like:

    Full v1.77 changelog:

    • Gameplay: added “Chooser” gamemode. Select mercenary lineup every month.
    • Gameplay: dynamite no longer required for mission start.
    • Mods: added FORCE_CHOOSER parameter to force the Chooser gamemode.
    • UI: press Enter to end planning phase.
    • Fix: fixed Combatant gamemode (was always on).
    • Fix: fixed typo in mine_triggertime parameter.
    • Fix: fixed “Bookworm” achievement.
    • Fix: crash when time values are too large.
    • Fix: crash in File Manager.

     

    The Steam patch is now live! Grab the non-Steam patch here.

    Date: April 20th, 2011
    Cate: atom zombie smasher, development
    1 msg

    Urban Renewal Kit

    Over the years I’ve become interested in procedurally-generated content. On the gameplay side, it provides a tremendous amount of replayability. On the production side, the bang-for-the-buck value is phenomenal.  I thought I’d take a moment and talk about how levels were created in Atom Zombie Smasher.

    Street work

    The level first starts off as a blank slate:

    At this point, it’s just a big empty plot of dirt. I find a random spot and lay down a street:

    Then, I start laying down the major “avenue” streets.  These streets are laid down in a such fashion to guarantee very large city blocks:

    The major city blocks are now defined. I now divide these giant blocks into smaller pieces.  One-by-one, every city block is measured; if it exceeds a certain threshold size, I divide it with a street.

    With that, the streets are all done!

    Buildings

    Now that the roads are completed, the level is ready to be filled with buildings. The building population system is fashioned after how you pack furniture: first you pack all the big items (the sofa), then you take care of the small stuff (the sofa cushions). In this case, I first start with the large skyscrapers:

    Notice the little empty plots of land neighboring the buildings. Tiny one-story buildings are now crammed into these these spots:

    Finally, some of the buildings are replaced with stunningly beautiful city parks:

    Done!  People are then distributed throughout the streets, ready to be either rescued or eaten alive.

    Et al

    This is an extremely straight-forward way of creating a city – there aren’t really any surprises in how it works. It’s based on a grid, making it very easy to check for intersections, overlaps, building sizes, and such. It’s fairly fast; the load time is hidden when the map zooms down from the world map to the city map.

    If I was to return to this, I’d integrate more gameplay rules into the city generation. For example,  creating “districts” (residential, industrial) characterized with certain buildings, building behaviors, population types.

    Furthermore, something I’d like to try to tackle is non-perpendicular streets and buildings.  This would allow for things like curved roads, round-abouts, etc., and introduces more variability than a straight grid provides.

    At any rate, give procedural content generation a try.  I specifically love how such content gives every player their own one-of-a-kind experience, a custom map that only you will ever get to play. This is something very unique to video games. My favorite description of Atom Zombie Smasher is from Tom Chick, who said it “uses tiny dots to create moments of drama.”  I certainly didn’t author any insightful dialogue or thought-provoking art — the game systems organically conjure moments where civilians are put in back-against-the-wall situations.

    Some wonderful games that focus on procedural content – Darwinia, Dungeon Crawl Stone Soup, Minecraft, and my beloved X-com.  I will never forget my best sniper in X-com, Abraham Lincoln.  You had a clean shot across the map, and you nailed it like the best damn 16th president of the US of A.

    If you haven’t played these games, then do so!