Gaming Your Way

May contain nuts.

Post Mortem ZombieLand : Bonesnap Boulevard

We're really really pleased and proud to present a guest post from our good friend Pany at the oh-so-talented UrbanSquall ( Developers of Battalion:Nemesis amongst other great games ) not to mention the words behind the always essential GamePoetry blog.

Enough of my introduction, on with the show:




Zombieland: Bonesnap Boulevard

zombieland_in_game.jpg


Intro
:

This is a really late post-mortem for Zombieland which was completed at the end of the first quarter 2007. Zombieland is an endless side scrolling shooter written in ActionScript 3.0. The game was written with the Flash IDE 9 Alpha, and was completed before Flash CS3's official release date. The game is still playable at http://www.newgrounds.com/portal/view/378688

Zombieland was essentially a critical flop. It didn't garner enough eyeballs to warrant a sequel, and despite some really creative ideas, and the flawlessly crafted graphics, people who played the game had a hard time coming to grips with the flawed weapon implementations, gameplay experience and jarring audio. It was a fun project that was executed in a very short time period, but a few missteps ultimately damaged the gameplay experience considerably.

Object_Barrel.png

What Went Wrong:

 

1. Audio. The music in the game is at too high of a volume, and the compression was set too high. The result is that long before you ever see anything approximating a mute button you are assaulted with an overwhelming blast of scratchy static-riddled music. I suspect many potential fans of the game were lost in the onslaught of those first few obnoxious seconds. The great sadness is that the music is actually pretty good. A few minutes could have fixed these problems very easily.

2. Questionable design choices. Random is not fun. The game uses a very basic algorithm for deciding what sort of enemies to spawn and at  that frequency. I think this only barely worked. Static levels would have taken longer to produce, but would have been inherently more interesting. Combined with other design blunders, like the constantly moving forward main character, the weak default weapon, and shoddy collision detection, Zombieland scared off most players long before they could come to appreciate some of the funner aspects of the game.
I'd say our rushed development schedule was partly to blame here, but it was also partly a lack of objective oversight.

zombie_playerGrab.png


3. Syncing gameplay and animations. In Zombieland, the majority of events are queued off animations. Firing, reloading, taking damage are three examples where I let the speed of the action be determined by animations. This could have been fine, except it clashed horribly with the fact that the character is supposed to be constantly moving forward meaning we had to do ugly tricks to maintain the illusion. The result is that most core actions in the game are very unresponsive which multiplied the negative effects of poor collision detection.
This was just a naïve misstep that was avoidable with a very simple design change.

Weapon_Chainsaw.png


What Went Right:

1. Graphics. Tim Wendorf, the artist for Zombieland, nailed the visual aesthetic. The 2x look, combined with the slick character designs really make the graphics the best thing about this game. There is a distinct possibility the game got away with its crappy core gameplay mechanics during development simply because of Tim's quality graphics.

Zombie_Tank.png


2. Inventive zombie designs. Again, I have to credit Tim's warped sense of humor for coming up with some of the more memorable moments in the game, like going toe-to-toe with a wheel chair zombie, or having to face a stream of zombie porcupines tossed by an angry zombie cowboy. The Zamboni Wamboni was all mine, though.

3. Quick turn around. The game took less than 5 weeks of near full time development. We didn't hit any snafus along the way and we delivered the final build ahead of schedule, despite the fact that I was still coming to terms with a new programming language (ActionScript 3.0) and a new content pipeline (bitmap tilesheets). We shipped the game with gameplay flaws that only became clear after the dust had settled and it was too late to do anything about it.
Scheduling wise, though, Zombieland was about as good as they come in terms of everything just coming together right.

Weapon_Shotgun.png


Conclusion:

The hindsight of almost two years since the game's release has given me some time to reflect on why Zombieland failed to achieve the success I thought it was due.
The most valuable lessons I can take away from Zombieland, at this time, is that I should avoid integrating slick graphics early in the development pipeline, and instead focus on prototyping and nailing the core mechanic and avoid getting seduced by a pretty presentation.
A part of this is getting more feedback on the gameplay mechanic, especially in those earlier stages, which can help identify issues with a poor random level generation algorithm, or crappy engine limitations, like bad collision detection and animation-based timing dependencies.
I'm hoping fate allows me another opportunity to revisit the Zombieland setting, as I think it was under served by a few key bad decisions that spoiled an otherwise solid game.

Panayoti Haritatos / UrbanSquall

Comments (4) -

  • Viza

    12/24/2008 5:40:12 AM |

    Post mortems are great!.. this one is no exception; always good to hear other dev stories. =]

    Viza.

  • Squize

    12/24/2008 11:19:57 AM |

    Couldn't agree more, Pany's done a great job with this write up.

  • tomsamson

    12/25/2008 10:49:42 PM |

    yeah, just browsing around to distract my self from my shaking stomach (ate way too much sweet flavored candy & cookies stuff the last two days, bah) i read this, really well done pany.
    Rare these days to read such honest post mortems and then really good ones at the same time. squize and me had something similar going (though more internally via mail) regarding polarity a while back when i decided to make a web spreadable version.
    So on one side i suddenly received lots of feedback from the portals having comments systems and at the same time some emails from squize where we basically discussed what all went ok and way more what didn´t go well during the develoipment and as result in the end product. I think such things are really highly benefitial to becoming better game designers and developers and team members, one can only not redo the mistakes one understood one did in the past ;)
    I think all your points are good ones, i especially want to underline the point: do not start with focussing on artside and adding nice polished art in too early.
    The problem with that one is of course depending on what type of game/engine it is one sometimes HAS to add in graphics early on to see limits or get a feel for it, but yeah, i meanwhile think its best to do most of the game with sucky developer art, too.
    It really helps focussing on gameplay instead of beeing too blinded by the yummilicious art as you pointed out very well.
    When reading alot about braid´s development that made me notice that point a lot again, too. (Have you seen the early programmer art driven first gameplay demos of the thing? I think that he brought the game pretty far with such art is one of the essential reasons why it ended up having such good gameplay).
    And yeah, also see this when reviewing most project´s dev cycles, i think it can really be taken as thumbrule, when one adds in too nice art too early on one really gets dragged away with that side.
    besides all that: i liked the core idea and some sides of the execution of your game, so yeah, hope you sometime get to refine the quirks and do a nice followup :)

  • Nate Pacyga

    12/29/2008 12:05:32 AM |

    Great post.  Thanks for the insight on your post mortdem.

Comments are closed