How do you design a game?

Like every gamer in the world I have ideas for games I think should be designed. Right now I'm kicking around a particular idea that I think might actually 1) be something I want to play enough to actually design and 2) I will have the opportunity to actually play enough to design. My problem is that I am terrible at putting big ideas into action, especially when it's a process I've never handled before.

I know we have a few published designers here. I'm curious about how some of you take designs from abstract ideas, to prototype, to something approaching "finished". I'm not particularly concerned with what it would mean to get something actually published, and I'm not even sure my thoughts will advance beyond something abstract. But I'm curious to know how it works all the same, if it were something I actually WOULD want to pursue.

Lots of work.

Start with a story, the story you want to tell. Then determine the top 3-5 abstract, one word themes that the story holds. For example, I have a game design about post apocalyptic tribal war, and the themes are desperation, survivalism, scarcity, and detachment.

Once you have established a story idea and the theme(s) which describe the story, then you can logically develop gross mechanic ideas to support the themes. For the aforementioned game:

Scarcity: Economic management, scavenging
Survivalism: Hoarding, hunting, protection
Desperation: Impossible choices, unforeseen consequences
Detachment: Apathy about other tribes and consequences

So, now we have ideas to work with. Take the gross mechanical ideas and rank them, and then develop concrete ideas that will best distribute the gross ideas.

Scarcity:
- Finite resources
- Feed people to deplete them
- Make acquiring them dangerous

Survivalism:
- Priority on weapons, shelter, skills
- Body count
- Win condition based on end game state of tribe’s population and/or prosperity

Desperation:
- Violence or fear of violence
- Events which further the feeling of desperation, make it real
- Constant struggle to stay alive

Detachment:
- Ability to sacrifice people to keep leaders or tribe alive
- Apathy about suffering of others, especially if it helps self

So, now that you’ve drilled down, you can start tacking solid mechanics down.

- Event cards which change game state for the turn (sandstorms, animal attacks)
- Unit specialization (Hunters, gatherers, builders, shaman/priest class, leaders)
- Depleting recources - feed all units each turn
- Battle over resource areas, resources, territory/ warfare
- Politics - Manipulation of game state via trade
- Scavenging area, disputed. Also able to develop economy via trade.
- Weapons for hunting and murder


So, now you’ve got it drilled down, so look to games you like and think about what worked and why. I look at this particular game and see Stone Age, but where you can kill enemies, build farming or husbandry, where there’s central choke points to fight over. The end game would likely be a turn timer to limit the game duration, and the winner is the ones who have surviving people, and based on one or two factors such as population and remaining key resources or upgrades.

That’s how I have done it, and I’ve made some neat games, with Hoodrats being my masterpiece.

Story first. Story will give me mechanisms, but will also shape what kind of experience I want the players to have. From there on out I find ways to tell that story. If the story requires travelling, how do you do that? If the story requires uncertainty, how to give the players that feeling and so on.

I usually start writing rules very early in the proces. Describing a round or turn structure, lining up components and key concepts and so on often help me visualise the game.

Early testing - possibly solo - is also a given. Not for balance and all that, but simply to give you an idea of whether the game gives you the experience you want. It's pretty easy to design a game flow that works on paper, but simply feels boring when it hits the table.

For me, the germ of the idea is usually player experience, but it can also be mechanism, a specific theme, or whatever grabs your brain and won't let go.

The goal should be to get a prototype to the table as quickly as possible - for solo playtest with yourself. Just play all the different sides, and see how it goes. Spend as little time as possible on the proto - scrawl on index cards, use slips of paper, whatever. Don't be afraid to change things mid-playtest.

It's going to be terrible - just be prepared for that. That's why you want to spend as little time as possible on materials. Most likely it is all going to get thrown away.

Don't be afraid to test out just a part of the game. You don't have to have everything pulled together before testing. Just do a part and wave your hands and say that something magical happens over here.

I also try to write down rules very early in the process, because it helps me see edge cases and clarify things. And in general, if a rule is hard to write clearly it's a red flag that it's a bad rule.

But I know plenty of designers who think that's crazy, and just write the rules much closer to the end, since they're in flux so much.

Some games will come easy, and some will be agonizing. Space Cadets: Dice Duel basically emerged fully-formed from my brain onto the page, and was ready to go almost out of the gate. The Fog of War took 14 years to get right.

So just keep plugging away - but if something isn't working, don't be afraid to scrap it.

Geoff

Yeah, Jeff is dead on with regard to prototyping and most importantly, don’t get married to any ideas.

Mark and I have a philosophy in STF: Anything that makes the game less fun is removed. We had so many cool ideas which would have been more simulatory (which I wanted) but he ultimately was right about removing shit like ammo management, and other fiddly shit which made the game more realistic but less fun.

I am a prototyping madman, and I spent a LOT on getting the game prototyped. I wish I hadn’t. I have a mind for mental simulation of maps (which is why our maps are so good, thank you very much) but you can’t play test without making them. After spending way too much I realized it is easier to scale the game down to 8.5x14 and use Risk: Rogue Battlefield (or whatever) miniatures snd small Euro cubes to play test, which resulted in much faster development near the end.

My only published game was in 2006, and I probably did a lot of things wrong in the process. I also have a few complete prototypes of games that will never be published for one reason or another.

I always start with setting, and that usually leads quickly to the story that the game will tell. The nature of the story will indicate if the game is competitive, cooperative, team versus team, or one versus many. The nature of the story should also strongly suggest the mechanics. Will there be combat? (In my games, yes.) Will there be economic activity? Trading? Auctions? Buying and selling? Asymmetric roles or factions? Etc. I also tend to confine my games to things that are within my ability to prototype. So most of my games use cards and/or tiles, but I have so far avoided doing maps.

Then I sketch out a rough outline of rules, and make some crude prototypes, and play some partial games by myself to get a feel for the general gameplay. Where does the game bog down? What is fun? What is a hassle? I spend a lot of time at this phase, and this is where some of my designs died. It's easier to quickly replace or adapt crude prototypes, so I don't get too committed to any elements yet.

Based on what I have experienced so far, I take my first shot at a solid rule book and better components. Despite the presence of two great local game stores within mere miles of my home, I tend to have trouble recruiting playtesters beyond my immediate circle of friends. So my prototype tends to look nicer at this stage so it's easier to recruit random playtesters. I steal the best art and photos I can find online to make my components look better.

Some playtesters are better than others. I like the ones who try to break the game, even though they can be obnoxious under other circumstances. If they can break my game, then I need to improve the rules or even go back to an earlier stage of the design. I also like players who are competitive or experimental, because they tend to challenge my assumptions and force me to improve the game. Other playtesters suck. They will helpfully explain to me how I should make massive changes to the game to make into a completely different game that they happen to like. I smile and thank them for their input, and ask if they have considered designing such a game. Other people will blame the design if they lose the game, when that isn't necessarily the case. If the game still seems fun after a bunch of playtesting and reactionary revisions, then I might push ahead to the next stage.

In the old days, my next step would be to contact potential publishers and pitch my idea. Sometimes I already knew the exact publisher because I wanted to do a game based on their existing IP. This is how I got my one game published. Thanks to Kickstarter, it is no longer necessary to contact a publisher, though it would now be necessary to directly contact companies who might produce the components and the box. Then set up the Kickstarter.

All that said, I don't recommend that you design a game unless you are strongly motivated to do so, and you have an idea that is not currently represented by the bajillion published games. Game design is a lot of work for not much money, and only strong motivation is likely to carry you through the whole process.

The last time I designed a game, I went into the process knowing that it was a game that I had always wanted, but would never get published. I was hoping to just play it once in a while with close friends and fans of a specific IP. I put a lot of work into the game, and spent a little too much on it, but I was free to design the exact game I wanted.

Make sure you have friends. A partner and I worked meticulously on playtesting a skirmish game for half a year, including only a tight group of playtesters. When it came time to play test it, our closest friends were not much interested, and we really couldn’t get anyone outside of our group interested in it, either, because for most people testing games is torture, and not something you’d want to do for a stranger.

As designing the game tested the bonds of our own friendship, I’d say, at this point, that I regret ever having started it. It really is a lot of work.

Lots of great advice already in this thread, but here's my take:

Start with what the game is about, and decide how you want your players to feel. Suspicious, excited, scared, nervous, etc. Think about the actions you want players to be able to do. Don't get hung up on mechanics at this point... for example, your game could include real estate, so you definitely want your players to buy property. But HOW they do that could happen any number of ways. Maybe they have a draft. Maybe a blind bid. Maybe they draw tokens out of a bag. Who knows.

Once you have your core actions figured out, THEN think about what mechanics best reflect those actions. Hack together a prototype and run through some sample rounds.

It's also worth thinking about player count and game length. If you want to show it to publishers, it needs to be 90 minutes or less, or they will not care.

Then it's back to the drawing board to make corrections. Rinse and repeat 1000 times.

ubarose wrote: Also, DO THE MATH. You will save a lot of time if you do your math up front, rather than flailing around trying to find it. You need to think about how often you want certain things to happen, how many turns it should take to do things, how many turns the game should last, where the game state should be the 1/3 mark, the halfway mark, and the 2/3 mark, what you want the probability of success to be for various actions - and then do the math to make it happen. If math isn't your strong suit, tap someone to help you. I've sent probability questions to the Spawn's math teachers, and to my own college probability professors that were too difficult for us to figure out on our own.

This is a great tip. Enough playtesting will get you where you need to be, but figuring this out up front will save you huge amounts of time.

Similarly, think about how long you want the game to be, and how many turns you expect it to be. That will give you an idea of how long each turn needs to take, which in turn impacts how much you can have the players do in a single turn.

SuperflyTNT wrote: Anything that makes the game less fun is removed.

People have made a bunch of good points and suggestions here, but this is really the root of it all and can never be forgotten. Yes, you need to do the math and make your crappy index card prototype and keep everything together in a handy box, but the essential part of play testing is constantly asking: "Is this fun"? Every move, every decision, every strategy needs to be fun. Don't be "married" to any aspect of the game. If it's not fun, it needs to go.