It's not really fair of me to start up a brand new blog without paying some attention to the old one, is it?
I've been working on a lot of game designs recently, and it's had me thinking about my process for making a game. I'm not sure how long I can ramble about this, but let's start with initial concepts.
My games usually start with a single idea. Most often it's a mechanic I want to explore. It can come from another game I've played where I liked something but didn't think that it had been done right (or at least the way I thought it should be.) Or I want to explore it more than the designer had or take a minor mechanic and focus an entire game around it.
The second most common way I start a game design is with a theme of some kind. Time travel, or zombies, or something will strike my fancy and I'll think about ways to make a game out of it. Most often this gets married to a mechanic I'm interested in and we're off to the races.
Guillotine happened in this way. I was having lunch with a bunch of the other game designers at Wizards of the Coast one day and we got onto the subject of the French Revolution for some reason. By the end of the lunch I'd decided that it would be a good theme for a game. I settled quickly on the idea that the players should be the headsmen competing to get the best nobles from the line, and the rest of the basic mechanics fell into place from there.
Ideas can come from other sources as well. One game I'm working on at the moment started as an idea about packaging components and a whole game has evolved from it.
Once I've gotten my initial idea I tend to create games like a parfait (who doesn't like a parfait?) Maybe more like an onion, or even better, like a space station. There's the initial idea at the center, and then I add bits to it wherever they seem to fit best. I keep adding bits, and then discarding them when they don't work. I guess the best way to describe it is that I have a very "modular" approach to design. I ask questions like "What's the hand size?" "Do players score as they go or only at the end?" and so on. I then create the mechanics to support those ideas and bolt them onto the superstructure (I like the space station metaphor) until I've got something I can prototype.
Sometimes the game comes together well and with a clear vision and I make the whole thing up for testing. That can be a lot of work, but if I have faith in all the pieces it saves time because it's much easier to tune a completed game. Sometimes, though, I need to test the core to see if it's worth creating the whole station or not. It can be hard to know if that initial mechanic is even viable without testing. In the most extreme cases I'll only do the bare minimum of extra design work. I'll create a playable game, but with a lot of bare bones mechanics surrounding the core I want to test. That way I'll (hopefully) be able to isolate that mechanic and see if there's something worth pursuing.
Once the basic structure is done it's playtest, playtest, playtest. I try to play every game as much as I can. I learn something new with every game I play.
The most important advice I can give about playtesting, though, is "don't be afraid of change." Don't hold onto a bad mechanic just because you love it. It might be wrong for the game. And don't be afraid to scrap or heavily modify big sections of the game to see what works. In fact, as much as you can, think ahead of time about different ways the same game might work and test them all out. You'll find hidden synergies in the mechanics this way.
Also, bring a pen. Take notes. Change components in between games as you discover problems and try again with the changes. I say between games because in general you should finish most playtest games you start, even if you've discovered something minor that is wrong and you want to change it. You'll get valuable data about the endgame, scoring, etc. that you'd never even get to stopping and starting again.
I hope this post has helped you get some insight into my design process and maybe even helped you think a bit about your own.
I've been working on a lot of game designs recently, and it's had me thinking about my process for making a game. I'm not sure how long I can ramble about this, but let's start with initial concepts.
My games usually start with a single idea. Most often it's a mechanic I want to explore. It can come from another game I've played where I liked something but didn't think that it had been done right (or at least the way I thought it should be.) Or I want to explore it more than the designer had or take a minor mechanic and focus an entire game around it.
I designed an unpublished game for Wizards that eventually became mob themed (title: Mob Rules) before being killed, but it started with an idea. I was a designer for Magic: the Gathering and was fascinated with how much of the rules of the game were on the cards and not in the rule book. So I set out to make a game that only had one rule:
On a player's turn they play one card from their hand and then draw one card from the deck.
Now if you really want to get technical, there HAVE to be other rules than that. There's game setup, there's creating definitions for "hand" and "discard" and a whole slew of "maintenance" rules, but the core idea was solid, and I especially liked that there was no winning condition in the rules. The only way to win was to play a card that said "You win." Or more specifically, "You win if you X."
So I started with that one rule and set about making a game that followed it and was hopefully still fun (in the end the game was green-lit, art was created, and text was laid out, before the plug got pulled. So it was at least fun enough for that.) I started by making cards with different colors/factions. Then I made cards with rules on them that cared about what color other cards were. I put numbers on the cards as well and then put rules on the cards that cared about them. I introduced mechanics that weren't tied to cards like the concept of "money" and made some of the cards care about it. Games evolved differently as players focused on areas of the game based on the cards they were drawing.
The second most common way I start a game design is with a theme of some kind. Time travel, or zombies, or something will strike my fancy and I'll think about ways to make a game out of it. Most often this gets married to a mechanic I'm interested in and we're off to the races.
Guillotine happened in this way. I was having lunch with a bunch of the other game designers at Wizards of the Coast one day and we got onto the subject of the French Revolution for some reason. By the end of the lunch I'd decided that it would be a good theme for a game. I settled quickly on the idea that the players should be the headsmen competing to get the best nobles from the line, and the rest of the basic mechanics fell into place from there.
Ideas can come from other sources as well. One game I'm working on at the moment started as an idea about packaging components and a whole game has evolved from it.
Once I've gotten my initial idea I tend to create games like a parfait (who doesn't like a parfait?) Maybe more like an onion, or even better, like a space station. There's the initial idea at the center, and then I add bits to it wherever they seem to fit best. I keep adding bits, and then discarding them when they don't work. I guess the best way to describe it is that I have a very "modular" approach to design. I ask questions like "What's the hand size?" "Do players score as they go or only at the end?" and so on. I then create the mechanics to support those ideas and bolt them onto the superstructure (I like the space station metaphor) until I've got something I can prototype.
Sometimes the game comes together well and with a clear vision and I make the whole thing up for testing. That can be a lot of work, but if I have faith in all the pieces it saves time because it's much easier to tune a completed game. Sometimes, though, I need to test the core to see if it's worth creating the whole station or not. It can be hard to know if that initial mechanic is even viable without testing. In the most extreme cases I'll only do the bare minimum of extra design work. I'll create a playable game, but with a lot of bare bones mechanics surrounding the core I want to test. That way I'll (hopefully) be able to isolate that mechanic and see if there's something worth pursuing.
Once the basic structure is done it's playtest, playtest, playtest. I try to play every game as much as I can. I learn something new with every game I play.
The most important advice I can give about playtesting, though, is "don't be afraid of change." Don't hold onto a bad mechanic just because you love it. It might be wrong for the game. And don't be afraid to scrap or heavily modify big sections of the game to see what works. In fact, as much as you can, think ahead of time about different ways the same game might work and test them all out. You'll find hidden synergies in the mechanics this way.
Also, bring a pen. Take notes. Change components in between games as you discover problems and try again with the changes. I say between games because in general you should finish most playtest games you start, even if you've discovered something minor that is wrong and you want to change it. You'll get valuable data about the endgame, scoring, etc. that you'd never even get to stopping and starting again.
I hope this post has helped you get some insight into my design process and maybe even helped you think a bit about your own.
Comments (0)
Post a Comment