It’s been over a year since I enrolled in university as a Game Design student, and I’ve learned a lot of things. Theory has been slung around ad nauseum, and Gen Ed courses have been suffered through.
The funny thing about being a Game Design student is that you can read all the Raph Koster and Jesse Schell you can handle, but it still doesn’t really prepare you for the main event – making a game.
In the end, it’s best to look at people like Schell and Koster like the world’s best parents. As a parent myself, an important part of the process is having the wisdom to know when to let my child fail, and when to let him make his own mistakes. Being a great Game Designer – just like anything else – is all about making your mistakes and learning from them. And when things look terrible, and all hope is lost, you can go crying to A Theory of Fun for inspiration.
As a fledgling designer, you need to realize that not only is it all right for your first games to fail, it’s encouraged. Screw up the balance of your game just for kicks! Spend five hours flowcharting and find out that nothing you did works! Have a field
day, because every design flaw makes you that much wiser. However, it’s important to remember that a lot of us have, or currently are,
walking the same path that you are. There are a lot of mistakes that we have made and lessons that we have learned that you should take our word on.
An Epic Fail
I recently had the honor of working with three very talented design students on a board game. Over the course of one month, we would conceptualize, design, prototype, iterate, and launch an original analog game. In addition to this being a fully realized game, it also held great symbolism as well. Two months later we would cast aside our analog shackles and begin programming and level designing original video games. It was a major test in our progression, to see if we could hack it before we started coding and doing all sorts of freaky computer stuff that us young game designers are apparently so petrified of.
We quickly set to work, forming a team charter and assigning roles. As it was a four-man team, we decided on having two designers, an art lead, and a narrative lead. This brings us to our first lesson.
If you have a limited time to build a game, put all your resources in design. Aesthetics will happen naturally as the prototype evolves.
This small decision at the beginning of development proved to be a major problem. As amazing as the art and narrative leads were, it was a wasted effort. I chalk it up to us “playing game studio.” We wanted to tackle the game like the pros, with none of the resources or experience. Had we taken a moment to step back and look at the big picture, we would have seen the error of our ways.
As this was a team that had already worked together on previous projects, we were currently in the “performing” stage of team development, where all group members were firing on all cylinders, and everyone had a great deal of respect for the abilities and dedication of the other members. This proved to give us false confidence – we felt unstoppable and brilliant. We were the Gods of teaming.
Running on the heady high of working with a great crew, we drafted a design doc. The concept sounded really fun, if not immensely dense for a board game. It would a juxtaposition of tower defense and Battleship, featuring 2v2 play. The board comprised of two identical maps with a divider running between them to prevent either side from seeing what the other was up to. One team needed to collect a number of keys that opened a door at the edge of the map that signified their “escape”, and won them the game. The other team needed to stop them from “escaping” within the time constraints of the game. There would be trap cards, logic puzzles, riddles, and massive obstacles. One side had most of the firepower in that area, where the other side had to rely almost entirely on their intelligence and cunning.
With everyone running mostly blind (fueled by snippets of information and paranoia), the game would be a suspenseful game of strategy. We thought it sounded pretty fun, but soon found that it just wasn’t, unless you like saying the same exchange every 10 seconds:
Attacker: I landed on C32.
Defender: No traps, you’re good
The game turned in to this faux equation – (Nothing happens, ever * ∞/hear the above conversation over and over again * ∞) = OMGIHATETHISGAME111!!!!
Unfortunately we found out that this wasn’t fun about 2 weeks in to the development cycle, roughly 20 hours before we had to submit our completed design doc for final approval to make the game. When the concept was initially fielded we could have said “Hey, let’s get a
board mock up right now, write a few abilities, and just go for it”, but we didn’t do that. We felt that we needed more information before we began a prototype, and worried about EVERY single thing imaginable before we put pieces on the board and tested it out. Had we done rapid prototyping from day one, things may have panned out better for the initial concept.
Don’t wait until you have more information to prototype – there’s never going to be enough information. If you have an idea, boil down its basic mechanics and get something to work right away.
In those first two weeks as we worked on the design, we all had nagging doubts. We wondered if it would be fun, if it would be good enough. We wondered if after all our swagger over the past year, that we could actually make a workable game. We did the only thing we could do to stay sane. We pushed the doubts in to the back of our heads, and kept plowing through the work. We thought we had solid mechanics, but we didn’t factor in how boring the “in-between” of a board game was. Board games require a lot of tasks. The players have to roll dice, move, grab cards, strategize, etc. If none of those things are enjoyable, then the player is just going through the motions to get to the next cool part. This isn’t just exclusive to board games. Every game is filled with moments that just aren’t naturally compelling. You have to min/max your gear in Dragon Age, manage your ammo in Call of Duty, and arrange your offensive line in Madden.
Designers spend hours of their life making this process painless. Even then, some of the biggest gaming juggernauts can’t pull it off. Blizzard just announced recently that they hate how threat works, because managing it isn’t fun. They have been trying to get it to work right since they started development on World of Warcraft, and they just can’t do it. Making the dull parts of a game fun is a problem, there’s no denying that. But you still have to push forward, grit your teeth, and innovate. We found that there was not enough action in our game to compensate for all the dull bits. So what did we do? We amped up the action, hoping it would offset a problem that we didn’t even attempt to solve. That was a huge mistake, and we spent a massive amount of time iterating a game that just wasn’t fun, because we avoided the root problem.
Yeah, you need cool moments, but don’t forget that the stuff in between those cool moments needs to be engaging and fun.
We learned the above lessons the hard way – by making the mistakes ourselves, and it cost us dearly. After two weeks of working on the game, and seven iterations, it was dead in the water. It was 20 hours before we had to submit our design doc, and we had a game that was useless on every possible level. As we finished up our last iteration that night, I looked at the other designer and said the one thing we had been avoiding since we started.
“This game isn’t any fun, isn’t it?”
He shook his head as I said those words, and we knew at that moment, that we were in some serious trouble. We made a snap call – with the time frame we had, it would be easier to trash the game and come up with something new. We could get a design doc together, and just work our butts off the following week to get it ready to launch. And that’s what we did. Twenty hours to go, and we scrapped two weeks worth of work.
Don’t be afraid to panic for a minute. It’s all right – you’ve earned it.
Make sure you check out my next post, when I wrap this tale up with lessons from our development hell week, how we made a pen and paper RPG in seven days that actually worked, and how we stacked up against our peers.