Tagged in: lesson

Artifact Hunt, A Board Game Design Workshop

I haven’t been blogging much right as we race to finish Sunset Overdrive at work, so now seems like a good time to talk about and share a cool board game design workshop that I’ve run with Molly Jameson (@UltraRat), a fellow gameplay programmer, and Lisa Brown (@Wertle), a fellow designer. I’ve run this workshop three times for girl scout troops, and once for a young girls game coding after school class.

You can download the materials here:


(Full credit goes to Anthony Ortega and Juancho Buchanan, who created the workshop at Harrisburg University, who passed the lesson plan to Lisa Brown, who passed it on to me.)

It requires:

    • A large poster-sized printout of a very simple board / team
    • A rules handout / team
    • 4 token pieces / board
    • 2 player pieces / board
    • 2 dice / board
    • Pens or pencils

The first step is to set up the boards with all the pieces. I’ve found that teams of four are good for this, but it works well with anywhere from 2-5 students. We’ve run this workshop for 10-18 year olds and it’s worked out really well each time with minimal fuss.

The first thing you do is have the teams play the board game. If you look at the rules, you’ll notice that there are some major flaws in the game’s design. It’s incredibly easy to get a stalemate so that it’s impossible for either player to win. It’s easy to end up in a tie, where both players reach the finish with the same number of points. Almost every single group will one into these problems.

While teams are playing, walk around and make sure that if they have questions about the rules that you can explain them (especially for younger students). Play usually takes 5-10 minutes. We usually wait til everyone has played one full round, and a couple groups have usually played a second by then.

When all the teams finish the first round, that’s when you start to solicit feedback. Some good questions to ask:

    • Did you like the game? Did you not like it? Why?
    • Who won?
    • Did you think it was fair?
    • Did anyone do any battling? How was it?

Usually that’s all the questions we need in order to get teams to open up and talk about their experience. The important thing is to get them to express why they liked, or didn’t like, the game and to think about the mechanics and rules.

The next step is to have the team go back and, together, choose ONE rule that they will change. They can remove a rule, replace a rule, or add an entirely new rule. But they can only change ONE! After they have changed it, they will play it again as a team. This process usually takes about 10 minutes, sometimes a little longer.

I usually offer students extra dice, players, and tokens at this point if they want to involve those in their rules. Wile they are hammering out their ideas, walk around and ask them if they know what they are going to do, and encourage them to play the rules. Some groups will take a long time figuring it out, but we’ve never run into any that didn’t come up with something eventually.

When they are done, and everyone has changed a rule and played their games again, we stop them and ask them a series of questions:

    • What rule did your group change?
    • Did it make the game more fun? Why?
    • Did it cause any new problems? How would you fix that?
    • To the rest of the class, did anyone else change the same rule or do something similar?

You can do a second round, but this is usually where we end it. I sometimes bring handouts on free game-making software for students to take home.

Some of the changes we see are: added tokens to create asymmetrical play, the ability to ‘steal’ tokens from each other, changes in how score is calculated, changes in dice are rolled and calculated during battling, disallowing diagonal movement, allowing movement outside of the play space, removing or changing the movement penalty for carrying tokens.

At the end I usually talk a little about what design and iteration are, and how they are involved in making games. It’s important to only change one thing at a time because every change has cascading effects. If you change too much and the game is better or worse, you won’t necessarily know which change brought about that new dynamic. On top of that, this lesson gives students a chance to design without worrying about the technical or artistic skills involved in game development.

One of the great things is this lesson really runs itself. The kids – and young adults – are always engaged, they are having fun, and they are thinking critically when challenged to talk about the mechanics and how they make the game fun or not fun. I feel like it’s a very good introductory lesson to have at the beginning of a game design class or otherwise introduce students to design.

If you have any questions, feel free to leave a comment or contact me at my email – lizengland07 @ gmail.com