Uncomfortable Design

This is less a thought about game design, and more a thought about designers themselves.

Looking at my own and others' experiences, game designers seem to learn the most about their trade when they step outside of their zones of comfort.

For example, if designers work on nothing but a single system for years, their design skills - even in regards to their most familiar system - improve if they work on another system in the game. On a broader scale, I'd even say that console design can inform PC game design, and vice versa.

When designers leave their most familiar contexts, while it may be uncomfortable, I think it grants them more opportunities for lateral thought, and greater game-making potential.

Who are you, and why did you start blogging?

I should have answered this question sooner. You, my readers, deserve context!

The idea for this blog started at AGDC. I was speaking with Brent, Cuppycake, Andrew Krausnick and Steve Williams, all of whom have blogs. It occurred to me that I do have a lot to say about game design, so why not join in?

I'm always reading up on one aspect or another of game design, and I try out new games as often as I have time for them. So, when I run across something I think is interesting, I write about it. I hope it will be as interesting to you as it was to me, whether you agree or not. Comments are always welcome!

Now, as to me personally -
I have just over 2 years of computer game design experience, all of it (so far) on Vanguard: Saga of Heroes. While some may point out that Vanguard isn't doing so well, I doubt I would have learned as much about design if Vanguard had been more successful.

I didn't just pop into the gaming industry fully formed, like Athena from Zeus' head. In the past, I've worked as a computer consultant and information architect - both jobs that taught me the importance of user-centered design. And, of course, I'm an avid gamer. I've played and GMed tabletop games since 1994, and played MMOs since 2003.

So, in a nutshell, I'm a D&D DM with her foot in the door in the computer gaming industry.

Addendum:
To concur with Jeff Freeman... yes, I may have taken leave of my senses. :)

Paper Prototypes

Designers love to design, and they are full of design ideas.

For most game designers, the early stages of a project are candy - brainstorming, throwing piles of ideas out on the table, and discussing them with other designers. It's genuine fun to work on something new; to get to decide the rules from the beginning.

An issue with developing prototypes for most computer games is that they require an engine, and a comprehensive set of tools for implementing assets and content. If these are not already developed, designers (if they are not also coders) can end up with a lot of time on their hands while they wait for the coders to get the fundamentals in place.

Here's the danger. Because game designers love to design games, it's easy for them to use this time to design additional, and potentially overambitious, aspects of the game. In a worst case scenario, you end up with a game far too enterprising for the scope of the project.

Considering the <20/>80 rule of thumb that I discuss in a previous post, designers ought to be spending this extra time playtesting their prototype. But how can they do that if their prototype only exists as a design document?

The problem can be solved by testing the game system on paper while it is being coded. I've seen it work. Applying iterative design to a paper UI can help solve many design problems ahead of time, and help make the system more fun than it would have been.

If you time it right, when the code is ready for the final design and content steps to be taken, it's possible to have many gameplay kinks worked out (instead of a thicker design document).

Paper prototypes for the win.