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 20, 2019
arrowPress Releases
May 20, 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 4 of 5 Next
 

4. Fear made us conservative.

Halfway through development of the game's 81 levels, we decided to lock down the designers' toolset, forcing them to use many of the same tidbits over and over.

No new mechanics to make later levels more interesting. No new architectural set pieces -- they had to spend time combining existing pieces to make them seem fresh, rather than using new ones to make visually interesting environments.

This wasn't a conscious choice -- we were just afraid that if we didn't focus on the levels, we'd never reach the end.

After all, every new mechanic we'd added to the game (graffiti, flipping people off) required a lengthy process that we remember as follows:


How to add a new feature to the game.

We tried to avoid that long process by stretching what we had as much as possible. We asked ourselves: did our levels reeeally use what we had to the fullest? Were we being lazy builders because we needed a new model or a new mini-mechanic to create 5 new maps? Time was running out, and that made us play it safe (which always seems to be the most dangerous way to play things).

We were afraid to use placeholder art and mechanics in lots of places. If we wanted to add a new feature, our mentality was that we had to get it right the first time. And if we didn't, it was wasted effort, and should be scrapped.

The Story of the Magnetic Grapple

The idea formed: why not allow players to play Spider-Man throughout some of the levels? We implemented a first blush "magnetic grapple," and ended up spending an entire afternoon playing with the feature. We tweaked variables to get the right feel. We formed ad-hoc contests to see who could swing up the highest. We were having too much fun to do any “real” work (which, looking back, is half the point of game development).

But when we asked ourselves how this fit into the overall game, we came up empty. So, we abandoned it. And the lesson we learned was this: don't experiment at this stage -- it's just a waste of time.

Bad us! Bad! Bad!

The last major item we added to the game was a spray can that allowed players to sprawl graffiti over things. It was a tiny addition, but it also a fantastic one! Between flipping people off and giving them the thumbs-up, players would glide between buildings to tag the right ones. After that, we turned conservative. And, as it turned out, you can only fly past the same eight story building model so many ways before it became redundant.

To address this on our next project, we're regularly stepping back to get that 30,000 foot view, making conscious (rather than reactive) decisions about how to truly generate interesting new content. We're also setting aside time throughout development to just experiment with new mechanics or tools, rather than confining that process to the prototype.

3. We flubbed feedback.

We didn't test enough. And when we did bring testers in to toss the game around, we underused the feedback we received.

As indies, we're informal about many things. Roles are often fluid: our tech lead is also responsible for the blog's graphic design as well as getting coffee for our interns, for example. That has worked well, but the danger in creating processes in an informal, ad-hoc fashion became evident in how we carried out testing:

We thought we were testing properly. After all, it was easy to act on some types of feedback:

  • Minor elements we'd been considering: "Aha! The HUD is too high by five pixels. I knew it! I'm so glad we tested."
  • Explicit problems: "The player bounding box is too big for our tester to thread the needle. He dies every time."

And to reject other suggestions:

  • Those that were inappropriate for gameplay style: "Halfway through the game, you should climb up to the top and have to fight through the rest of the game as an ogre in an RTS."
  • Those that were too big for the game's scope: "Collaborative web-based level building over multiple devices. It'd be awesome to edit levels on my iPhone while other people are playing it!"
  • Those that were just plain wrong: "Get rid of hugs and kisses. And change the game's name to something like BASE Jump Extreme if it's going to sell."

What gave us the most trouble was recognizing the non-explicit bits of feedback. Number one was this:

  • You know those places where we didn't have to wrench testers away from the playing game? Those are the boring bits.

As a result, those boring bits stayed in the game.


Article Start Previous Page 4 of 5 Next

Related Jobs

Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[05.19.19]

QA Manager
Dream Harvest
Dream Harvest — Brighton, England, United Kingdom
[05.18.19]

Technical Game Designer
Insomniac Games
Insomniac Games — Burbank, California, United States
[05.17.19]

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

Animation Tools Software Engineer





Loading Comments

loader image