Tuesday, August 01, 2017

Life imitates life - the beginnings of a designer diary for Automatown

A few months ago (circa April 2017) I was responding to interview questions for Initiative Magazine. I was being featured in the June issue of their Game Mechanics section in an interview by Robert Nolan about refining games. It's not a free magazine, or I'd just link right to the article so you could read it.

I may have gotten a little carried away with some of my responses, in particular to the question about what it means to be "finished" with a game. At the time I had ants in my pants about people cavalierly saying "I designed a game," in the past tense, implying that they'd finished a process, when what they mean is that they've only started that process. I may be in a pedantic minority here, but I feel like conflating "I designed a game" with "I conceived of a game idea" really belittles and diminishes the hard work of game design. As a game designer (as well as a developer and a publisher), I stand firmly against anything that minimizes the work of design, and especially development.

Aside: Really, the crux of it is agreeing on where "design" (invention) stops and "development" begins. We don't really have sufficient (or sufficiently agreed upon) vocabulary for this, so as long as the word "design" is used to refer to both a finished game design, as well as just the initial, unfinished game idea, we're going to have a communication problem, one which I maintain is bad, as it leads to people putting unfinished, underdeveloped games up on Kickstarter and therefore out into the wild.

Here's an excerpt from my response to the question I mentioned above:

It's a lot of fun to brainstorm a game idea, come up with the story for a game, maybe suggest a loose framework for how might go, and leave it at that:
"It would be cool to have a game about building automatons to do your bidding! You should have assistants to help you, so maybe it's a worker placement game. Oh! And When you finish an automaton, you could put it to work for you as an additional assistant! Your assistants would gather materials to make automatons, study ways to make better automatons, and eventually your army of automatons would grow in strength until you can take over the world.”

That was right off the top of my head as sit here replying to these questions. It might have taken me 3 minutes. It's an OK idea for a game, it could work, but it’s obviously not finished as you can't sit down and play it! But it was fun to think about. I would not say at this point "I have designed a worker placement game about building automatons." Rather, have come up with an idea for a game. The next step would be figuring out rules of the game. What do you do on your turn? What do the worker placement spaces do? What does it cost to build an automaton? What constitutes a “better automaton"? What does it mean to "take over the world"?

Many designers get to this point in a design. I have several rule sets in my notebooks that seem fully fleshed out, and need to be tested before going any further. Since you’ve got a fully written rule set, it's tempting at this point to say “I’ve designed a game!” But as most designers have probably experienced, the first time you test a game, it doesn’t necessarily go as planned. Game design requires testing and iteration. So, even with a complete rule set written down for the automaton placement game described above, I still wouldn't say “I have designed a worker placement game about building automatons," because I'm not done yet.

Now that we have rules, the next big hurdle is to create a physical prototype and test the game. Sometimes this is as simple as creating a deck of cards; other times there's a lot more arts and crafts involved. For the aforementioned automaton placement game, I would need to gather some pieces to use as assistants, resources, maybe victory points as well, and create a board where worker placement spaces exist. This does not need to be very fancy, and if geography doesn't matter, it could just be a simple grid of spaces. Again, I'm assuming the goal is to create a game to pitch to publishers, not to self-publish. Either way, art and graphic design come later.

Once I have cobbled together a physical prototype, I STILL haven’t designed a game! I'm no further along than the last step until I've tried the game. Upon playing the game - either solo or with other people - we are sure to find details that don't work, aren’t ideal, or could use improvement. This is where the nitty-gritty work of design and development come in: iteration. We make improvements and we test. Make more improvements and test again. Each time, presumably, making the game better and closer to finished. 
As you see, buried in the response to that question, I came up with the seed of a game idea. A pretty neat game idea, one that stuck with me and might be fun to work on. Let's fast forward to July 2017...

Since I was attracted to the idea, this automaton game idea swam around in my head, and eventually made it into my design notebook, along with many other game ideas. In the middle of the night one night I had an epiphany about how a certain part of the game could work, so I went downstairs, got on my computer, and filled out some spreadsheets, and the next day I scrounged for bits and pieces to use, and cobbled together a prototype.

That Friday at RocketCon (a local game day my friend hosted on Raytheon campus), I got a chance to try the first draft of the game. As predicted in my quoted passage above, "it didn't go as planned." We made a couple of audibles during the game, and I immediately had ideas about what needed to change. But the players and I all felt like the game had potential.

1/2 a new prototype later, I played again the next day at a store, revealing more information about what I'd changed, and what still needed to be addressed. A twitter follower was nice enough to volunteer to print and play the game, and he returned feedback that very night, leading to decent design conversation over the next few days, and further updates to the prototype.

The following weekend (we're up to last Friday now), I took yet another version to a local game day and played two more 4 player games. I was homing on on how I wanted the different aspects of the game to work. Yesterday I finished another version of the prototype, and I'm ready to test again - though I think I ought to update the rules before I forget anything.

I think it's amusing how an off the cuff idea for a game that I spit out as an example for an interview question turned out to be something I was inspired to work on, and something that seems to work fairly well. I think it's even more amusing that the process of designing and developing this game has mirrored the narrative of my interview response almost exactly!

In my next post I'll describe the game as it stands. Maybe one day I'll finally be able to say "I have designed a worker placement game about building automatons to take over the world."

1 comment:

Michael Brown said...

It seems to me to mostly be a question of definitions. When is a game done being designed, and when is it being developed? Certainly if a game is playable, functionally complete, and it has been published it is done being designed, but where would you draw the line?

I would probably define it thus: A game is being designed when large changes are still occurring, or when the game has not yet reached a state where all of the parts of the game are well defined. Once the game enters the phase where mechanics are no longer being changed, and balance is the primary concern, then the game is done being designed.

At that point, you begin to develop the game and attempt to make it work consistently and cleanly.

This is of course based on my own definitions.