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.