Production Diaries: Ready, Steady, Go

It started, like most things I do, with spite.

Seriously, one of the best ways to get me to do something is to tell me I either can’t do it or that said thing is impossible.  Then I get it into my head to prove them wrong and shove their noses in it like a misbehaving puppy while I’m at it.  Sometimes, it occurs to me that I am not exactly a nice person.

Remember that last bit, it’s going to be important later.

Back in 2010, a friend and I had been talking.  Both of us were very big fans of the show Avatar: the Last Airbender, as well as being tabletop junkies.  One of us bemoaned fact that there wasn’t an official sourcebook, because an A:tLA campaign would be, in a word, awesome.  And so the seed was planted in the back of my head.  I wrote down some vague ideas and some sketches, and then pretty much shoved it out of the way because I had a thesis to write and a job to get.

Fastforward to PAX East 2013.  There was a panel, in the Tabletop Theater, on the Future of RPGs.  The panelists warned for “at least 90% wrongness”.  So I went anyway.  And, oh, man, I spent an hour biting my tongue and trying not to beat my head against a table.  Because the panelists, 3 very well-respected authors in the indie tabletop world, well, let’s just say that it was above 90% wrong for me.  The straw that broke the camel’s back, however, was the response to the innocent question on what’s a good tool for designing a game collaboratively.  Ignoring the fact that the three panelists had no idea (Google Docs, a wiki, and a version control system are the three that pop into my head after about .5 seconds), the infuriating part was the stubborn conviction that you couldn’t write a good game collaborating with other people.

Seeing as how I’d just come off a 3 month project writing a Persona tabletop system with two friends and have spent the last 8 years writing LARPs on GM teams, it was a little beyond insulting.  And so, telling me that I can’t do something?  That something is impossible?

Enter spite.

So here we are.  The old A:tLA idea has evolved into its own independent setting and set of world rules.  And although I’m going to start this out by being the main one typing things, I know I’m not going to do it alone.  The idea has morphed into a world I’m calling Salt, Silk, and Steel (or 3S).  It’s an elemental wuxia system and setting, set in an expy of Tang Era China and the surrounding countries.  Probably with some dashes of steampunk-esque.

And I’m not doing it alone, because I have friends who a) have been dying for a decent Eastern-based tabletop system that isn’t horrible, and b) know where I sleep and will stab me if I do insulting cultural appropriation shennanigans.  I also have friends who have spent as long as I have writing games or thinking about game mechanics, who will also happily tell me when I am being Wrong.

So on one hand, I’m doing this because 3 authors told me I couldn’t.  On the other hand, I’m also doing it because I really want to and I want to try to write a system independent of an already-existing property.  I’ve been wanting to write this for a very long time, and I think I finally have the skills to make it happen.

So here we are.  I’ll be taking you guys through as I write this, explaining some design notes and where I had trouble making mechanics fit, be they because of theme or numerical constraints or something else entirely.  You’ll probably also see when I inevitably have to scrap a thing because it doesn’t work.  Game design is a process.  It’s long and you can’t be afraid to cut something because it isn’t working.  You also can’t give into the temptation to just give up when things are hard or overwhelming.  

It’s not exactly something that’s easy to explain, so writing this all out is helpful for me, as a designer, to lay out my thought process.  It’s also helpful to you, the audience, I think, to see what a designer might be thinking when designing a mechanic, why choose this mechanic or value over that one.

If you, as a reader, ever have any questions or comments, feel free to say so in the comment section.  I’ll do my best to answer and explain.

At the very least, I hope all this will be entertaining.

And okay, the smugness when I pull it all off will also be hugely gratifying.  I told you spite was important.

Design Notes: PC vs. NPC

This topic is slightly more relevant to LARP design than tabletop design, but it’s a topic that a designer (and GM) needs to be cognizant of in the design and storytelling process.  It may seem like a simple distinction, the player characters (PCs) vs. the non-player characters (NPCs).  After all, in a tabletop, this is blatantly obvious as the PCs have actual breathing humans attached to them, and usually them alone, while an NPC is part of a stable kept by the GM.  Using this definition, however, leads to thorny issues when you move to a LARP, where an NPC is also attached to an actual breathing human.

So let’s try a different definition.

The definition I’ve been working with for the last few months, and has turned out to be fairly robust, is simply stated as thus: “The difference between a PC and an NPC is the amount of agency the character has.”

As it happens, this definition has been robust because it ultimately ends up to be a zero-sum game.  A PC will have agency; an NPC will not.  What this means is that a PC is defined by their ability to meaningfully interact and affect the story and world around them, while an NPC lacks such an ability.

“But wait!  What about villains?!  Darth Vader tries to blow up the rebels, isn’t that by definition ‘affecting the story in a meaningful way’?” You are probably all yelling at me.  And well, my answer is “sort of”.

This is why this topic gets a bit thorny when we move to tabletops and video games.  But there’s a key point about highly plot-relevant NPCs like the main antagonists that keeps them firmly in the NPC camp.  A plot-relevant NPC will possibly cause an action that kicks off a plot, buf from that point onward, the key turns of that plot are in the hands of the PCs.  The NPC will react to the PCs actions, even if it looks like they’re manipulating the PCs in being the reactive side.

To go back to the Star Wars example, if Luke decided “screw this, I’m outta here”, well, the outcome of the trilogy would have been very different.  If you’ve ever run a tabletop, you know players are a force of nature onto themselves, and they’ll only follow plot-hooks if they want to.  The NPCs will go off onto their determined path based on their initial conditions unless an action by a PC causes them to deviate.

Bluntly stated, a PC must have agency in most situations.  An NPC is a plot device.

To be engaged in a game, the player must feel like they can affect the game world in some way.  They have to feel like their choices matter in some way.  An NPC, especially in a LARP, is a point of interaction, a way of manipulating a plot.  This part is equally true in tabletops and games.  And remembering it is a good way of ensuring that the most memorable (and hopefully enjoyable) parts of a game are in the hands of the PCs.

Service Announcement

I don't know if anyone actually reads this thing, but here's the deal:

This blog is going to get rebooted a bit in the next few days.  I haven't abandoned this!  I actually had the next post on mechanics interplay about half-written, before I got completely distracted by Mass Effect last year.  As it turns out, I'm likely to be recycling that into an Ides talk in a month, so I'll post a version of that talk here afterwards.

The more interesting thing is that also within the last year, I ended up collaboratively writing a tabletop system based on the Persona universe.  Which taught me a lot of things.  And which now leads me to the most relevant part for this blog.

I'm currently in the beginning steps of writing an original tabletop system and setting from the ground up and have decided to do something similar to the Atlus Production Diaries in this blog.  I'll basically be recording the game design process as I go.  Since this is a blog, I'll be able to answer questions and respond to commentary.

At the very least, I hope it will be somewhat entertaining.

Status Update

No, I have not forgotten about this blog.  I'm currently working on a post on mechanics interplay, which will hopefully be posted soon.  I've also been playing through the Mass Effect series.  Expect some case studies and analysis from that at some point in the near future.

Mechanics Analysis: Building Blocks

One of the key things that makes a game “a game” is that it uses mechanics.  A mechanic in soccer is to move the ball without using your hands.  A mechanic in go is to place a white or black stone on the board to represent your territory.  All games use mechanics, and how the mechanics interact with each other is one of the dynamics of the game.  Without mechanics, an RPG is just a book or people telling stories.  There’s no “game”.

Therefore, when you want to create a game, you have to think about the mechanics.  Not only that, but you have to think of how the mechanics interact with each other if you want to write games more complex than tic-tac-toe.  We’ll get to how mechanics interact with each other dynamically in another topic, but for right now, let’s start with the basics.

The key to a robust mechanic, even if it’s not necessarily good, starts with a question: “What do I want to accomplish?”

Notes on Spoiler Policy

Since this is a blog about game design, it is fairly obvious that we're going to be talking about games as examples.  There are probably spoilers afoot.  In the case of tabletops or board games, these, if they even exist, are fairly minor.  In the case of LARPs run by the MIT Assassins' Guild (which is where I learned to write such games and generally run the ones I write), games declared "dead" are fair game.  For video games, anything older than ten years is also fair game.  These will not be noted with spoiler warnings.

LARPs that have not been declared dead and any game made within the last ten years will be tagged with spoiler warnings.

In short, I'll give a warning if I'm talking about Mass Effect 1 or Persona 3, but I'll talk about Final Fantasy VII until I'm blue in the face.  The statute of limitations ran out a long time ago on that game.

Something of an Introduction

I'm Ash, and I'm a gamer.  Which should be fairly obvious by this point, but it never hurts to make it blatant.  In addition to being a gamer, I'm an engineer.  What is not obvious is that this means I have a tendency, when I get my hands on a game, be they tabletop, LARP, boardgames, or video games, to take it apart piece-by-piece to see how it works.  This is not new.

I've been writing LARPs for about the past 8 years.  If we want to be technical, the first game I wrote was actually a board game for a school project that was a combination of Monopoly and Trivial Pursuit (that was actually playable) when I was 10.  I currently have two tabletop systems I'm in the process of developing and an attempt at expanding a d20 system using the 3.5 SRD (under the OGL) that's stuck in a perpetual state of limbo.  And while I can claim no credit for designing a video game (yet), I have been playing them since I was 3, and they are fair game for dissection.

That's what's going on here.  We're going to take games I've written and games I haven't written and use them as case studies and examples.  We're going to go through game mechanics and design philosophies and practices to see what works, what does not, and why.  If I'm lucky, we're going to get knee-deep in theory, from writing to psychology to mathematics.  I have a few topics already planned out, and am always open to suggestions.

And since this is me claiming no great wisdom beyond my own experiences, this is my invitation to all of you to share your own thoughts and ideas.  Together, we're going to reverse-engineer some games and figure out how to make them stronger, faster, better!  We have the technology!  Okay, maybe not the faster bit.