Tagged in: education

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:

http://www.lizengland.com/resources/ArtifactHunt.zip

(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

“The Door Problem”

“So what does a game designer do? Are you an artist? Do you design characters and write the story? Or no, wait, you’re a programmer?”

Game design is one of those nebulous terms to people outside the game industry that’s about as clear as the “astrophysicist” job title is to me. It’s also my job, so I find myself explaining what game design means to a lot of people from different backgrounds, some of whom don’t know anything about games.

The Door Problem

I like to describe my job in terms of “The Door Problem”.

Premise: You are making a game.

  • Are there doors in your game?
  • Can the player open them?
  • Can the player open every door in the game?
  • Or are some doors for decoration?
  • How does the player know the difference?
  • Are doors you can open green and ones you can’t red? Is there trash piled up in front of doors you can’t use? Did you just remove the doorknobs and call it a day?
  • Can doors be locked and unlocked?
  • What tells a player a door is locked and will open, as opposed to a door that they will never open?
  • Does a player know how to unlock a door? Do they need a key? To hack a console? To solve a puzzle? To wait until a story moment passes?
  • Are there doors that can open but the player can never enter them?
  • Where do enemies come from? Do they run in from doors? Do those doors lock afterwards?
  • How does the player open a door? Do they just walk up to it and it slides open? Does it swing open? Does the player have to press a button to open it?
  • Do doors lock behind the player?
  • What happens if there are two players? Does it only lock after both players pass through the door?
  • What if the level is REALLY BIG and can’t all exist at the same time? If one player stays behind, the floor might disappear from under them. What do you do?
  • Do you stop one player from progressing any further until both are together in the same room?
  • Do you teleport the player that stayed behind?
  • What size is a door?
  • Does it have to be big enough for a player to get through?
  • What about co-op players? What if player 1 is standing in the doorway – does that block player 2?
  • What about allies following you? How many of them need to get through the door without getting stuck?
  • What about enemies? Do mini-bosses that are larger than a person also need to fit through the door?

It’s a pretty classic design problem. SOMEONE has to solve The Door Problem, and that someone is a designer.

The Other Door Problems

To help people understand the role breakdowns at a big company, I sometimes go into how other people deal with doors.

  • Creative Director: “Yes, we definitely need doors in this game.”
  • Project Manager: “I’ll put time on the schedule for people to make doors.”
  • Designer: “I wrote a doc explaining what we need doors to do.”
  • Concept Artist: “I made some gorgeous paintings of doors.”
  • Art Director: “This third painting is exactly the style of doors we need.”
  • Environment Artist: “I took this painting of a door and made it into an object in the game.”
  • Animator: “I made the door open and close.”
  • Sound Designer: “I made the sounds the door creates when it opens and closes.”
  • Audio Engineer: “The sound of the door opening and closing will change based on where the player is and what direction they are facing.”
  • Composer: “I created a theme song for the door.”
  • FX Artist: “I added some cool sparks to the door when it opens.”
  • Writer: “When the door opens, the player will say, ‘Hey look! The door opened!’ “
  • Lighter: “There is a bright red light over the door when it’s locked, and a green one when it’s opened.”
  • Legal: “The environment artist put a Starbucks logo on the door. You need to remove that if you don’t want to be sued.”
  • Character Artist: “I don’t really care about this door until it can start wearing hats.”
  • Gameplay Programmer: “This door asset now opens and closes based on proximity to the player. It can also be locked and unlocked through script.”
  • AI Programmer: “Enemies and allies now know if a door is there and whether they can go through it.”
  • Network Programmer: “Do all the players need to see the door open at the same time?”
  • Release Engineer: “You need to get your doors in by 3pm if you want them on the disk.”
  • Core Engine Programmer: “I have optimized the code to allow up to 1024 doors in the game.”
  • Tools Programmer: “I made it even easier for you to place doors.”
  • Level Designer: “I put the door in my level and locked it. After an event, I unlocked it.”
  • UI Designer: “There’s now an objective marker on the door, and it has its own icon on the map.”
  • Combat Designer: “Enemies will spawn behind doors, and lay cover fire as their allies enter the room. Unless the player is looking inside the door in which case they will spawn behind a different door.”
  • Systems Designer: “A level 4 player earns 148xp for opening this door at the cost of 3 gold.”
  • Monetization Designer: “We could charge the player $.99 to open the door now, or wait 24 hours for it to open automatically.”
  • QA Tester: “I walked to the door. I ran to the door. I jumped at the door. I stood in the doorway until it closed. I saved and reloaded and walked to the door. I died and reloaded then walked to the door. I threw grenades at the door.”
  • UX / Usability Researcher: “I found some people on Craigslist to go through the door so we could see what problems crop up.”
  •  Localization: “Door. Puerta. Porta. Porte. Tür. Dør. Deur. Drzwi. Drws. 문”
  • Producer: “Do we need to give everyone those doors or can we save them for a pre-order bonus?”
  • Publisher: “Those doors are really going to help this game stand out during the fall line-up.”
  • CEO: “I want you all to know how much I appreciate the time and effort put into making those doors.”
  • PR: “To all our fans, you’re going to go crazy over our next reveal #gamedev #doors #nextgen #retweet”
  • Community Manager: “I let the fans know that their concerns about doors will be addressed in the upcoming patch.”
  • Customer Support: “A player contacted us, confused about doors. I gave them detailed instructions on how to use them.”
  • Player: “I totally didn’t even notice a door there.”

One of the reasons I like this example is because it’s so mundane. There’s an impression that game design is flashy and cool and about crazy ideas and fun all the time. But when I start off with, “Let me tell you about doors…” it cuts straight to the everyday practical considerations.

Recent edits: Added localization, character artist, system designer, combat designer, composer, audio engineer, monetization designer, and I think that’ll be it for now.