Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Dejobaan Games' Aaaaa! -- A Reckless Disregard for Gravity
View All     RSS
May 25, 2019
arrowPress Releases
May 25, 2019
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: Dejobaan Games' Aaaaa! -- A Reckless Disregard for Gravity

September 22, 2010 Article Start Previous Page 5 of 5

2. We failed to empower everyone on the team.

Giving our designers strong scripting tools was great, but it didn't mean they could generate all the content they needed.

A level designer could fall through a level, dodging and weaving things like crazy. He could then hit a button and populate his fall path with scoring plates, knowing that players who followed that path would have fun.

However, to add a simple, rotating fan blade to his level, he had to go to Ichiro, who would import the model, orient it, resize it, apply a skin, add it to the catalog, and script the rotating motion. Or, he'd simply not do any of that.

The problem seems simple when we think about it now -- having everyone go through one person was a painful bottleneck.

This either prevented designers from making progress while they waited on him to implement something, or (worse), caused them to simply not think about level design outside the scope of what their tools could accomplish:

Dan (Narrative & Gameplay): Gentlemen, what can we do to make this level fun -- and different from the last fifty?

Tam (Programmer): How about a waterfall?

Ryan (Artist): Or a garbagefall! Junk could come falling out of tubes under a skyscraper, and the player could weave around them.

Tam: Pieces could blow in the wind and or fall straight down. And they could hit birds!

Dan: What would really be great would be a generic system where we could script things to fall and respond to wind. Let's ask Ichiro if he can code that.

Ichiro: No! No time to implement! Raaah!

Dan: Okay, boys. Buildings and more buildings, it is.

As a result, level designers would end up spending 20 hours trying different ways to make the same three pieces play differently. So, after the project finished, we went for some Q&A:

Q: How could we let this happen?

A: Myopia. We never took a look at our level building process as a whole. Instead, each day, we'd come in and just work on the damned levels.

Q: How did this affect the final game?

A: Levels looked similar-er than they should have. Ditto gameplay.

Q: How can we have solve this problem in the future?

A: For starters, we'll sit down with our laptops and talk about how the designers work. ("What does the process of building an entire level look like? What are the problems we've been hitting on a tactical level?") From there, we'll scope up and ask the bigger questions. ("What should the level building process really look like? What's the right balance between tool building and tool use?")

The added difficulty here is that we knew that constraints often aided creativity. In some cases, designers would come up with quick, interesting solutions to problems. However, by over-constraining, we forced designers to re-tread the same paths repeatedly. We ended up squashing creativity.

1. Poor, irregular planning nearly killed us.

This is the mighty one: We failed to step back at regular intervals to get the big picture, and became mired in the details. We didn't ask the big questions ("How does the game look to someone who hasn't been working on it for half a year?" "What are we missing?" "How do our post-launch goals affect design?"). And it almost killed the project.

Stop us if you've heard this one: after the initial planning stages, we never substantially updated our design document. Towards the middle of development, the game looked significantly different from our original plans, so we threw the plans out and flew by the seat of our pants.

  • We had no set interval during which we'd go back and refer to the design document.
  • When we did, we had no procedure in place for a review and rewrite.
  • Eventually, we stopped looking at it entirely.

[The design document as it failed to evolve.]

We compounded this error by failing to sit down and discuss the big picture with each other -- our implicit mantra was "What do we need to develop right now?" This bit us in the butt on a number of occasions; for example:

  • We didn't identify the need for additional architectural pieces -- the game could have easily tossed lots of new stuff at the player in the latter levels.
  • We didn't identify what we needed for the demo experience, instead plowing right through its development.
  • We weren't able to plan for longer-term things such as post-launch content, sequels, or multi-platform support.

At worst, everything we did was reactive, and we failed to recognize problems until after we'd shipped the game. Just about everything that went wrong stemmed from our lack of stepping back and considering the project as a whole. Fortunately, Aaaaa! was modest enough, and our team was small enough such that we were able to correct for that. But we probably won't be so lucky in the future, so we're trying to make amends with our next project.

As such, our new approach has been this:

First: Begin by asking all the questions we can about a project.

We began our next game by posing as many questions as we could. Some required small, one sentence answers, while others broke out into other documents. Here are some:

  • How do we know if our game's high concept is remarkable?
  • Why's it better than every other project we could begin at this time?
  • What team roles are currently unfilled or underserved?
  • What software, hardware, or services will we require to complete this project?
  • How do we determine if this is a dead-end project, and how do we then terminate it?
  • How do we determine if this design doc is out of date, and what do we do then?
  • What do we need for the pre-release?
  • Why will this sell?
  • How does the customer find out that this game exists?
  • How can this game cross-promote with other games?

We've tried to answer these questions measurably. ("We'll know if we have a good high concept if, on hearing it, people laugh and sign up for our fan club. If they say, 'cool, that might be fun', we have to iterate on it.")

Second: Meet regularly to discuss the 30,000 foot view.

Every week, the core team has met to consider the high level questions. Every handful of weeks, we've gone through the design document to answer old questions and raise new ones -- we've tried to keep a living document.

It's on our calendar now.

Third: Conduct pre-mortem post-mortems.

Much of the document you're reading could have been written before we even finished Aaaaa! -- but we never took the time to consider what we'd already been doing right and wrong. On our next project, we've been trying to look back at the past months and figure things out before the end of development.

Our single biggest takeaway from Aaaaa! is that we should regularly step back, become aware of the project, as a whole, dissect it, and move accordingly.


Well, that's it! Those are the most important lessons we've learned on our epic, nine-month journey of Aaaaa! Couples who had sex on the very day we pressed the first keystroke on the game's prototype gave birth on the day of our launch. Poetic, no?

The stars aligned. Our hard work paid off. Our mistakes didn't kill us. And our lucky 13th title has become our single most popular game with critics and gamers alike. For us, Aaaaa! has been a brilliant success. And you know what? This coming year, we're going to blow that out of the water. Stay tuned!

(And in the meantime, visit us at and check out or pan-indie blog at

Data Box

Developer: Dejobaan Games, LLC

Publisher: Dejobaan Games, LLC

Release Date: September 2009

Platforms: PC

Number of Developers: 2 full-time, 1 part-time, 2 interns, 1 Alicia

Length of Development: 9 months

Lines of Code: 15,000ish, though you could probably compact that into just one if you used enough semicolons.

Trivia: Our team at PAX East all had nice, red Aaaaa! t-shirts. Being indies, we created them by buying blanks for $2.49 apiece and spray painting them black. They even go through the wash just fine. God, I love my job.

Article Start Previous Page 5 of 5

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States

Director, Art Management
Pixar Animation Studios
Pixar Animation Studios — Emeryville, California, United States

Animation Tools Software Engineer
Disbelief — Chicago, Illinois, United States

Senior Programmer, Chicago
Disbelief — Chicago, Illinois, United States

Junior Programmer, Chicago

Loading Comments

loader image