Last weekend I was invited by the University of Birmingham Tabletop Gaming Society to do a workshop on game design. I’d like to write about how that turned out and some of the surprising things that happened in it – so if you’re planning on running this sort of event or if you’re a new designer who’s interested in hearing what information most surprised new designers, read on!

The structure of the thing was that I had six pages of notes divided into sections, each section had a full bullet points for me to talk around and ended in some sort of excercise. Generally 2-3 group discussions followed by something practical, like building prototypes or pitching games. The first section was a very high level run down of “This is what a game designer does” and the other sections went through the things in that one at a time in more detail.

Early on I asked everyone what they thought a game designer did, to get a handle on how much they already knew. Between them they got pretty much the whole process nailed down with two exceptions, so here’s my advice for new designers based on those:

Once you’ve got a prototype play it against yourself. Set it out and physically move between chairs taking the role of several different players playing your game. This lets you get a handle on whether the core mechanics work in the way that you think they will and to detect the most broken systems. If you need to (often if you have bluffing or diplomacy mechanics) create personalities for these players and stick them around the table. This is the chair of the one who always attacks, this is the good liar who’s normally believed, this is the person who calls every bluff etc.

This is a really important step because it’s one of the things that will keep your playtesters coming back to test game after game – if you weed out the worst problems and the most broken systems before showing the game to another human being you will much less frequently have playtests that aren’t fun and people will not learn to fear you bringing a prototype to game night.

The second was that a lot of new designers didn’t seem to know the difference between a designer and a publisher. Flippantly, the designer designs the game and the publisher publishes it. More usefully, a designer needs to focus on making a good game that’s fun to play, they shouldn’t be spending a lot of time acquiring art assets or thinking about production. There’s an extent to which it’s useful for a designer to know about these things (If you design a light game that requires £500 of components nobody will publish it) but you shouldn’t actually do them. Of course if you decide to self publish or run a kickstarter then you’re taking on both jobs – make sure you understand both of them and know how to do them well. If you are taking your game to a publisher be aware that they might want to change things about it, it’s not uncommon for publishers to suggest that a game be entirely rethemed (i.e. The rules stay the same but what the pieces are called changes. So instead of trading one soul for two points you might pay one coin for two vegetables.) and have an idea about what you are and are not comfortable with in that regard.

Going forwards I ran into another surprise with my audience. I was expecting largely to run into people who enjoyed playing games and were exploring the idea that they might decide to make some – there was an exception. One fellow had shown up because he worked in environmental modelling and was interested in creating an eduacational game to encourage sustainable, collaborative behaviour. He’d obviously played a few things and was familiar with coop games, but didn’t have a broad understanding of what was out there and how it worked.

Here I dropped the ball a little, in making some assumptions about what people would and wouldn’t know. For instance I didn’t stress that it was (generally) necessary for a game to have a winning state and a losing state and that you don’t really have a prototype until both of those outcomes are possible – I just assumed it was wrapped up in the word “game”. So the lesson for me is to make less assumptions 😉 However I firmly believe that it’s hard to create anything with experiencing it a lot (Consider what is written about writers who write more than they read) so even if your reasons for going into game design aren’t “I played lots of games and love them.” make an effort to play lots of games – even if you don’t particularly enjoy them.

This also lead to an interesting diversion into a publishing method that I haven’t seen game designers write about widely: Game design via public sector funding. There are entities out there (At least in the UK) who can find £10,000 to make a game not because they think 1000 people will buy it for £20 each, but because they’d consider it to have some inherent cultural value and would like to see it created and distributed freely (or cheaply) regardless of its profitability or popularity. I think that the game design community as a whole is missing a trick here because some of the games that come out of these initiatives are *awful*. There are unique challenges to creating this sort of game, but I think that established hobby game designers could rise to them and create some truely spectacular things if we had closer links to public arts projects – That’s something I’d really like to see and am working on being a part of in a few different domains.

Anyway – back to game design talks – one of the concepts that the new designers seemed to have some inherant resistance to, but that I find extremely useful, was “fail faster”. I talked about this at the end of Somthing From Nothing (Don’t worry, much sexier designers also talked about fun things) last week, but the notion is simple: Throw a prototype together as soon as you’re able and start testing. It’s better to fail a dozen times than to not get around to trying anything because you’re trying to make it perfect before you put pen to paper.

Almost nothing works first time, the games that I’ve worked on have all changed substantially from their initial state. It’s best to work out what your core idea is, create the minimum game necessary to support it and start trying it out. Once it exists you can vary it and tweak it and add and subtract ideas to your hearts content, but it has to be there before you can start experimenting with it. A lot of decisions you can almost make completely arbitrarily and then refine as you gain experience with this new thing that you are creating.

Over the course of the day pretty much everyone wound up with some sort of game. The main excercises punctuating the talk were idea generation, prototype construction, testing, playtesting, rules writing and blind testing – though we didn’t quite get to the last two in a meaningful way (In playtesting everyone had played every game so blind testing wasn’t really an option – I’d apply more structure to this section if I ran this workshop again). I thought that everything I saw by the end of it had something interesting to say, even if everything was in its first iteration and not really approaching a playable game.

There was a game which literally couldn’t be lost and that was completed in minutes by everyone who touched it that generated laughs and positive emotions in everyone who played it.
There was a roll and move game that had a gaggle of experienced gamers forget for a minute how hated such mechanics are because the theme pulled them in so effectively.
There was an action point based coop in which players selected special abilities from a shared pool at the start of the game which, while broken mechanically, demonstrated the potential to become something special as a complete game.

I can’t really imagine that I’d make prototypes like this these days, so perhaps there’s something to be learned for us too. It’s easy to get attached to a style, or to rules or simply to lose sight of everything that is possible – so it’s worth periodically doing something that pushes your comfort zone a little to expand your horizons.

There’s much more I could write about here – which is probably reflective of my nature as someone who runs seminars with more hours than pages of notes or who likes blogging but struggles to grasp twitter – but that seems like a nice note to end it on 🙂 I’m not sure if my bullet points from the thing would be of any practical use for anyone who’s not me, but if you’d like a gander drop me a line, always happy to share stuff like this.