Backstreet's Back. In Black.

photo credit: A Guy Taking Pictures via photopin cc

Been a while.

It took me some time to come to grips with a nasty reality: I was burnt out. Between work, and medical stuff, and working on Phoenix RPG, something had to give. So I've spent a lot of the last few months just watching TV (Chuck marathon, anyone?) and playing video games (mostly SWTOR and Path of Exile). Well, and still going to work, which as we all know is a bit of a necessary evil.

Phoenix/Monstrarium has been an amazing learning experience and I want to get back to it. However, I'm not ready for that yet. I'm going to take a break and start a new project, code-named Stellar. My intention is to use some of my lessons learned from Phoenix/Monstrarium and see if I can have a better process this time around.

Process? What?


Three key things I've learned are important when designing games, both from my own experiences and studying the efforts of others that have been both successful or not (in no particular order):

Play it. A lot.

Pretty much, for every page of manuscript written, have a playtest in between. Seriously. Especially when the authors (like me) are not substantially experienced. Monte Cook can do whatever he wants, he is a god of RPG design. The rest of us need a very tight and frequent feedback loop.

Why?

Because if someone goes too far down a rabbit hole, it's too hard to climb back up. This is the equivalent of Agile software practice for RPG design.

Something might sound great in my head, or even on paper, but playing it could be cumbersome or frustrating or impossible or worst of all, just plain not fun.

Playtesting doesn't have to involve a group of friends and a 24-pack of Mountain Dew. It can also involve beer, and it can also be by myself, at least in the beginning. Playing it in my head is not sufficient. Sitting at the table, rolling the dice, moving the minis - that's work well worth it.

Know Graphic Design

I've learned a ton about graphic design in the last 3 years, starting with becoming a near-expert in Adobe InDesign (even helping others on forums and working on my ACE certification). I'm not quite as good at Illustrator but I've done some crazy stuff in there, too, from learning the psychotic pen tool to making 3-D gradient meshes. And oh, I can make a sweet pie chart. Oh yes. Yes I can.

Learning tools, however, is only half the necessary skill. Maybe less.

Actual artistic talent is important. I can be highly disciplined with styles, layers, and the likes, but if I think Copperplate Gothic is a really cool looking font then I will never succeed. So, I've taken drawing classes and read tons of design books and put serious effort into studying the works of others from a critical perspective to understand why I like or dislike the design.

Graphic process is at least as important as skill and talent, and knowing when not to play with my toys has been an important lesson. For instance, separating Copy from Layout is such a huge deal, yet in the beginning I couldn't understand why. On my new project, I'm starting with InCopy and 4 basic paragraph styles (Division Lead, Section Lead, Bullet, and Basic Paragraph). I can do almost everything from a pure game design perspective in InCopy. I don't need fancy illustrations and well-thought out typography to get a couple of my friends together and see if the rules are fun. I do need the fancy stuff when I am ready to distribute it as a full draft to strangers. InCopy works well with InDesign in that regards, even to the point that I can have my editor check out and edit the InCopy text while I'm doing layout on that same block of text in InDesign. Freakin' sweet.

Knowing basic graphic design and layout principles helps even if a game designer doesn't want to do the actual graphic design. For instance, understanding the importance of consistent heading structures, when to (not) use italics, don't put two spaces after a period, things like that. They make the layout work a lot easier.

And let's take a page from fiction's bible: the first draft is ugly. Write it all down. Don't go back and edit it meticulously until the second draft. Maybe not even then. Just get it on paper.

Desired Outcome, first. Actual Mechanics, second.

I have a really cool idea. Let's make a core mechanic that does d8+d12+d4 for every roll. How cool would that be?!

Alright, we all have a collection, either written or in our heads, of cool mechanics ideas. Nothing wrong with that. But when making a game I find that theme and desired gameplay are best served first. In Phoenix, I really wanted to use exploding dice, to the point that it overruled a number of downstream decisions. I probably shouldn't have done that, as I no doubt missed many opportunities to improve the system.

When I wrote the first page of my new project, Stellar, I used d% everywhere. Because sci-fi.

Then I did some self-playtesting and it just didn't feel right. Over and over. So I stopped and asked myself what I imagined it should feel like. I drew probability curves on scratch paper, to represent success/failure odds. Maybe I want enemies to miss players 60% of the time, hit 35%, and crit 5%, or something like that.

I sat down with AnyDice and started to play around until I found the mechanic that fit the experience. Turns out, for Stellar, the best match is a dice pool approach with d12's. Not quite d% right? But as soon as I started playtesting with it, bam! Hit the nail on the head.

There's lots of other lessons I've learned over the last few years of hard effort, and I'll keep trying to share them as they come up. Some are larger and some are smaller. Learning them has been a big part of the fun in my ongoing adventures, and hopefully yours as well.