Love failure: make better games, faster

In my experience, most people can grasp one, but not both, these concepts when prototyping a game:

“If you fail, there will be dozens more”
“failure is ok! That’s what prototyping is for, so go crazy!”

Too often, I meet people who go crazy – but only once. It ends horribly, and they give up in shame.

Just as often, I meet people who make lots of stuff, quickly – but it’s all generic derivative crap; they never took creative risks.

The linked article above is a must-read for any serious designer: it’s a post-mortem from the Experimental Gameplay Project guys (“design + implement a new game every week for a whole semester” – if you haven’t played the games, or read about the concept, I can’t recommend it enough). I *frequently* tell wannabe-game-designers to go do exactly the same themselves – there’s no better way to learn the art and craft of game design.

Other choice quotes from the article include:

… how bad can it be?

“Although they were utter failures, the whole team was thrilled to take such a bold risk to prove the failure of audio-only gameplay, and I could point with pride to my hideous creations.”

… for all those misguided individuals who still think designers shouldn’t learn to code:

“Each member of the team had to be comfortable with all aspects of game development. Everyone was responsible for their own programming, art, sound, and everything else that went into the final product.”

(as Designers, you should aspire to be the games-equivalent of a Product Manager: making the final, shipped product come together as an awesome whole, rather than locking yourself in a cupboard doing your little niche thing, and ignoring the end-product)

…an observation I made a few years ago, and lead me to plan a 4-day week for our studio:

“after much investigation, it appears that you just cannot schedule creativity.”

…Scrum: start with a vertical slice of cake, and add slices, not layers:

“we found that gathering art and music with some personal significance was particularly fruitful”

(if you want further correlation of this, IIRC Jonathon Mak made the same point a few years back at GDC: Everyday Shooter sucked and was dull when he prototyped “game mechanics without animations”, and lead him down the wrong paths of improvement; you cannot take the style out of gameplay, it’s too tightly interwoven)

…how to: Simulate a prototype … in your head:

“It’s really easy! All you have to do is imagine your game audience saying, “Wow!” And then just work backward and fill in the blanks. What’s making them enjoy your game? What emotion are they feeling? What is happening in the game to make them feel that way? ”

Go read the article…

If you’re not convinced already, here’s their Handy Cut-Out List! (which won’t help much till you read it, as each line is one of the sub-headings:

Setup: Rapid is a State of Mind

* Embrace the Possibility of Failure – it Encourages Creative Risk Taking
* Enforce Short Development Cycles (More Time != More Quality)
* Constrain Creativity to Make You Want it Even More
* Gather a Kickass Team and an Objective Advisor – Mindset is as Important as Talent
* Develop in Parallel for Maximum Splatter

Design: Creativity and the Myth of Brainstorming

* Formal Brainstorming Has a 0% Success Rate
* Gather Concept Art and Music to Create an Emotional Target
* Simulate in Your Head – Pre-Prototype the Prototype

Development: Nobody Knows How You Made it, and Nobody Cares

* Build the Toy First
* If You Can Get Away With it, Fake it
* Cut Your Losses and “Learn When to Shoot Your Baby in the Crib”
* Heavy Theming Will Not Salvage Bad Design (or “You Can’t Polish a Turd”)
* But Overall Aesthetic Matters! Apply a Healthy Spread of Art, Sound, and Music
* Nobody Cares About Your Great Engineering

General Gameplay: Sensual Lessons in Juicy Fun

* Complexity is Not Necessary for Fun
* Create a Sense of Ownership to Keep ’em Crawling Back for More
* “Experimental” Does Not Mean “Complex”
* Build Toward a Well Defined Goal
* Make it Juicy!