Processing my process. Or: How to get better at game design.

Saturday, May 9th, 2009

I’ve sent my alpha version of Strangers out to some folks for feedback.  Most of the feedback boiled down to: ‘This is kinda complicated’ and ‘Where’s the fun?’

After getting the third return with the same feedback, I started to do some serious introspection.  While I don’t talk about it here on my gaming blog (heck, I don’t talk about much here at the moment) – I also do web design and programming.  Over the last few months, I’ve been lucky enough to gather a nice stable of clients and steady coding work.  It’s taken up a lot of my ‘free’ time, which is why I haven’t had much to say here.

Since I’ve been programming a lot more lately, I’ve started really honing my process for development, at least when it comes to web projects.  What I’ve discovered is that I’m: iterative, atomic and utile.  I’m no rockstar when it comes to coding – in fact, my programming blog is called ‘Groping for Code’, which it sometimes feels like I’m doing – looking at an end result that I want to achieve, and slowly building a scaffold to get me there, refining it along the way.

So:

Iterative: I make a lot of small changes, seeing what the result is along the way, and usually breaking shit.

Atomic: I work on one feature at a time, making it work, then integrating it with the whole.

Utile: I look for the best, cleanest way to do what I want to do, regardless of any sort of overarching programming principle.

I realize these things may even hold me back from being a good coder, but I’m working on improving – and more importantly, they’re working.  I’m getting things done.  Projects are moving.

So let’s contrast this with my game design process.  First of all, I don’t really HAVE a process, as such.  I just sort of jump into a design with both feet and see what happens.  Part of this is an artifact of how my completed (or mostly completed) projects to date have come about – they’re products of things like 24-hour RPG challenges or Game Chef, which imposes either a one- or two-week deadline.  Soup to nuts, make everything at least look like it hangs together.

But it’s not entirely that.  I have a sense of myself as ‘game designer’, so to some extent I’ve pre-judged the end result of my efforts: it will work, because this is hat I’m passionate about.  My designs tend to be all-or-nothing thunderclaps of effort.  This is just about as opposite an approach to process as you can get from my programming.  

I’m not iterative: Any changes that I make, I propagate them through the design without testing their viability, or the relative merits of the original version.

I’m not atomic: Games come out of me whole-cloth.  Any one section of the rules may or may not stand on its own.

Utile: I work from more formalist principles (the desire to create games that push certain envelopes, like integrating board game components, or exploring some facet of play) as opposed to looking for what works, then throwing mechanics at it until it sticks.

And the results are perfectly obvious: my programming gets done.  My games don’t.  So the question now is: how do I apply my programming process to my game design?

Iterative: Test, test, test.  Start with a framework for the game, then start hanging components on it, testing each component as I go.  If it doesn’t work, figure out what’s wrong and change it.  Question everything: is the form factor wrong?  Is the theme wrong? Is the approach wrong? IS IT FUN?

Atomic: Work with the minigame model – write up  mechanics for each aspect of a game, keeping in mind the overall shape of the project.  Test each minigame, then integrate and test again.  Obviously, some sort of testing mechanism is going to be crucial, here.

Utile: If principles are getting in the way, eject the principles for now.  If the principle is important, integrate it into the process at a lower level – does this facet support the principle AND the game, or just the principle alone?

Obviously, there are implementation problems that are independent of the process problem.  It’s a lot easier to iterate my web projects when all I have to do is alter a few lines of code and sync my localhost web directory.  But I like the shape of this, and I should invest brain cycles in trying to figure out a) how to make it work, and b) applying it to Strangers and Terrible World.

Strangers Rough Draft: Why Story Games are Hard.

Friday, April 3rd, 2009

I’ve completed the first full draft of Strangers, my game about ensemble dramas.  In doing this, I’ve come to the conclusion that story games are difficult to write. 

Let me back up a step and define some things.  A story game is (by my definition) a role-playing game where the mechanics primarily directly address the narrative of the game. This can be contrasted to (the majority of) roleplaying games where the rules address the theme or setting directly.  In D&D, for example, the rules are primarily concerned with the interactions between the character and the fictional world.  There’s no ‘Fade to black, cut to an exterior of the baron’s castle’  rule in D&D.  Sure, that sort of thing can happen a given game, but if it does, it’s the bailiwick of the DM.

Story game rules directly address the narrative being spun by the game – Strangers, for example, is chock full of rules on framing scenes, generating motifs and themes for your characters, and narrative arcs.  There is a ‘fade to black’ mechanic, in other words.  All of the players are co-authoring the drama in a literal sense instead of a rhetorical one.

What makes this so much harder is that mechanics become semantically challenging – the interactions between the players, the game itself, and the interactions that take place inside the game between the components, are hard to get your brain around because they all deal with abstractions.  What does it MEAN when I move my play card in this fashion?  What does it mean when I take chips out of this stack?  What does this interaction translate to in dramatic terms?  Have I covered all the obvious possibilities?

A lot of RPGs cover a lot of ground with their rules, trying to encompass the play experience.  But when the rules, to some extent, define the play experience itself, this metadrama gets really hard to think about.  

I’ve done my best to try and capture it – I’m test-driving the rules this weekend to make sure the wheels don’t fall off before I send it to a few people to pick it apart.  Finding a setting has proved challenging as well – I wanted to move away from genres that would put me in a rut (no medical dramas, etc) – but at the same time, I didn’t want the interactions between the setting and the characters to overwhelm the interactions between characters – which is at the heart of the game itself.

I finally settled on a compromise of a Jericho-like premise; a sort of World Without Oil: The RPG.  It’s 2019, and the economy has collapsed once and for all.  Peak oil turned out to be in 2011, and with the global economy so stressed by the shenanigans of Wall Street, recession becomes depression and a worldwide sense of feudalism pervades – the global village is dead, to a great extent.  Cities in the US have been abandoned for the most part, but when the tide of humanity tried to disperse into the rural areas, they found their country cousins less than welcoming.  Subdivisions in the exurbs became refugee camps, with extended neofamilies taking over cul de sacs and parking lots being stripped for asphalt to burn as fuel.

It’s in this setting that the characters, living on the edge of a dead Chicago, try and make their way in the new world order.

The Bucket List

Saturday, February 21st, 2009

I recently combed through the last 100 or so posts (we’re almost at 300 now!), and came up with a complete Bucket List of every game project that I’ve put the least amount of thought into.  Here they are, in no particular order:

1. DEAD
2. AFTER
3. Terrible World
4. Strangers
5. OORT
6. Expressionism
7. Bluebeard
8. Decathalon
9.  Merchant
10. Elsewhere
11. Elseworld
12. Cold War
13. Makuria
14. Get It On
15.  On the Air
16. Big Kahuna

So let’s play with this a bit to get priorities straight.  If I rank them in order of “words on paper” or “work done”, the list looks like this:

1. Elsewhere
2. DEAD
3. Merchant
4. Terrible World
5. Elseworld
6. Strangers
7. Decathalon
8. OORT
9. Expressionism
10. AFTER
11. Cold War
12. Makuria
13. On the Air
14. Get It On
15. Big Kahuna

Really, Big Kahuna is just an idea – but I included it for sake of completeness.  So now if I take this list and put it in order of “games I would want to have done”, it looks like this:

1. DEAD
2. Elsewhere
3. AFTER
4. Merchant
5. Terrible World
6. Strangers
7. OORT
8. Elseworld
9. Expressionism
10. Decathalon
11. Cold War
12. Makuria
13. Get It On
14. On the Air
15. Big Kahuna

So if we add the ranks from the two lists together, we get:

1. DEAD
2. Elsewhere
3. Merchant
4. Terrible World
5. Strangers

The interesting part of this exercise is that Merchant made it to the top five – the things that I really want to get done.  I think this is a sort of wake-up call that my pursuits are out of whack.  That I have so much done on things like Elsewhere and Merchant, but they’re sitting there on the shelf.  Mind you, they’re definitely not in a place where I could exploit them for the GenCon Year – not by a long shot.  But I think I need to take a long look at myself and my process – and figure out how these sorts of things happen.