O! for a muse of fire, that would ascend the brightest heaven of invention.

A pile of random game-making materials. Two hour time slot. “Go! Make a game!”

For some, this is oxygen to their designer’s brain, feeding the spark that generates interesting games, but for other game designers like me, this type of game design jam doesn’t work. It’s akin to the blinking cursor on a document when it’s time to write a big paper for school. You know so much about your subject, and you’ve been working so hard to research and compile your ideas, but when it comes to actually starting the work–you blank. You have so many ideas, but which to pick and where to start?

There’s something about the temporary momentousness that can arise in game design jams–the time to design is NOW, with these materials, so procrastination and inaction cannot be entertained.  Game design jams are, in the words of Adrienne Ezell, graphic and game designer, “a great way to spark ideation and fast iteration.” Tim Blank, designer, says, “Game jams force us to use a different side of our creative brains that we don’t often use much as designers. We often do a lot of thinking when we iterate on a game, but game jams don’t give us the time to do that. They force us to design by trial and error, which is at the heart of experience design. They also require us to listen to what the game wants to be, as opposed to using our pre-set parameters for it.” Sen-Foong Lim, designer, says, “I thrive under pressure and work well with constraints, so jams are my… jam. I find the pressure cooker of a game jam so refreshing. My brain needs the strict deadline to force it to work on things.” Game design jams, just by existing, can launch designers from ideation to prototyping quickly.

Game design jams shove designers into the heart of the design process, but outcomes are not guaranteed.

Game design jams can have the opposite effect of sparking ideas; they can confound or even stymie them. The pressure of producing a working game in that time frame, whether it’s an hour or eight, coupled with the performative aspect of designing in front of strangers, is productive for some designers, not for others. Elizabeth Hargrave, designer, says, “My personal experience at the one game jam I have participated in was that it confirmed that I hate being forced to be creative in front of people, with time pressure. I’m glad other people enjoy them, am happy to watch, but my brain freezes and nothing comes out.” So how to create a design jam where designers can be successful?

When I was invited to present at Tabletop Network in 2019, I decided to run a game jam, a very specific kind of game jam. I had taught game design to middle school students for 17 years at that point, so I had a good sense of what worked to help others design games. As a teacher and designer, I had undertaken transformative professional development experiences that informed my thinking. The two guiding ideas that shaped my jam were “Bias Towards Action,” and “Fast and Cheap” from the productivity triangle. First, the design mindset “Bias Towards Action,” from the Stanford d.school method of design thinking, means that if you have a choice between thinking and doing, start doing, because you’ll be thinking as you do the work, and you will progress much faster. The second key idea is to avoid preciousness in design by iterating extraordinarily rapidly. Out of Good, Fast, and Cheap, designers can only choose two, and this jam embraces the concept of Fast and Cheap. In such a short amount of time, games won’t be Good, so designers don’t have to worry about that. They just have to make something testable, in any small part, so that they can work towards it being good later. When we spend a lot of time on ideas, they become precious, and often we don’t want to throw out an idea that has had a lot of investment, even with a low amount of payoff. When we develop the ability to toss out non-functional ideas, we get better at developing the ideas that have actual promise. With these ideas in mind, time became the determining factor in shaping the jam.

In a 45 minute session, designers were presented with three game design challenges, ten minutes each. They were provided the specific materials to use for each challenge, and could choose to collaborate or not with other designers. I presented the challenge, distributed resources, and set them off; and then I did it again, and again. I announced the time several times during each challenge to help with pacing throughout. There was no sharing of results afterwards, unless designers chose to do so outside of the session with me or others. I called this event “A Lightning Multi-Game Design Jam.”

Several key decisions guided my design process for the LMGDJ.

1. Design and material constraints remove some decision-making from the process to allow focus on other specific aspects of design.
2. Ten minutes is not enough time to design a full game, but it can spark an idea that could turn into a full game later.
3. If a designer hates any of the challenges or the format itself, at least it’s quick.

Design and material constraints remove some decision-making from the process to allow focus on other specific aspects of design. The first challenge was called, “This Race Game Is in the Bag.” Designers were given a paper bag with sets of bits inside. They could only use the paper bag itself and the bits. Limiting the resources is obvious; I removed choices about what to use, so they could focus just on what was given, not what was possible for components. The race game concept is one of the best I’ve found for helping anyone to design a game for the first time. First, most of the common kid and family games (Candyland, Chutes and Ladders, Sorry, etc) are race games in some way (moving around a track controlled by a randomizer) so it’s familiar structure. Second, race games have the same objective and victory condition–be the first player to cross the line. In providing the objective and victory condition, designers needed only to start with HOW players would move their pieces. By providing specific components and game outcome, designers can focus on the key aspects of the design challenge to iterate quickly workable ideas.

Ten minutes is not enough time to design a full game, but it can spark an idea that could turn into a full game later. The ten minute limitation is the most divisive choice in the design of this event, but in a sneaky way, it also serves to help people succeed. The reality of a game design jam, even for much longer jams, is that creating a full, working game is very difficult to do; and when you don’t create a full workable game in that time, it can really feel like failure.  Success in ten minutes isn’t a full game, but is the start of what could be a full game. Success is creating something that might be worthwhile to keep pursuing. Jay Bell, designer, says, “It blows my mind that 10 months after a game jam prompt, I’ve created a solid game outside of my normal genre. Sometimes jams can produce fantastic nuggets, diamonds even.” If designers came away with one really cool idea from each challenge, or even from one challenge, that can be enough to call it successful.

If a designer hates any of the challenges or the format itself, at least it’s quick. If you hate what you are doing in a longer game design jam, you have to spend much longer with that game idea than you might if you were working on something at home on your own terms. The ten-minute limitation allows you a very short tunnel before the light appears to free you from a non-functional challenge. The ten-minute constraint did not work for designer Cat Drayer, who says, “The very short game jams don’t work for me at all, because my brain isn’t ready. If I am inspired in the wild, I can kick out a game idea in seconds, and have done so over and over with loose prompts, but with very tight time pressure, nothing happens.” Cat continues, “A game jam is meant to make you uncomfortable in some way. It should push you out of your normal design zone to try new things. The challenge for me personally is to find how far outside my space I can operate, and the go/no go is currently time. If I haven’t got enough time to digest the prompt, nothing happens.” The time constraint can simply limit designers too much, based on their personal preferences and style.

Designers make choices, and in the Lightning Multi-Game Design Jam, I made specific choices that impacted designers differently. At best, the jam has sparked ideas that became published games; at worst, its format has been too limiting for some designers to generate meaningful game ideas. This format was chosen with very specific goals and outcomes in mind, and certainly there are many other possibilities for design jam spaces. If you are considering designing and running a game jam, the lessons learned from this style of jam can help you to see how employing different ways to use time, resources, and specific design constraints will impact the outcomes for designers.

May the muse of fire ascend your game inventions (and design jams) ever higher.

Appendix:

Since 2019, I have run the LMGDJ online during covid and in person close to ten times, and I’ve adapted the different challenges each time for each audience and setting, while usually keeping the race game challenge as the first. Here is an incomplete list of design challenges that I have used.

Design Challenges

The Race Game is in the Bag

As described above; this challenge was about focusing on HOW a race could be won using provided materials.

The IP Challenge

A real company’s set of characters was to be the basis of a buzzworthy, social-media-friendly game. Designers were given two pieces of cardstock that were the entirety of resources for a flatpack giveaway, so space for rules meant less space for components, and each designer was given a two page dossier on the IP characters for them to use.

The Player Experience Challenge

Designers called out emotions and I picked “Rage.” Using paper and additional components, designers had to create a game that elicited rage from their players.

Happy Valentine’s Day

Make a two-player game based on Valentine’s Day using pennies and index cards. Two player games  have great potential for complete interaction between players, and Valentine’s Day can generate a wide range of narratives for games.

Push It!

Designers had to come up with their “entrance song” if they were a professional wrestler or other sports player, and had to design a press your luck game using dice and other components to make a game based on that song. Since entrance songs can generate strong feelings, the idea is to match that feeling to a game that elicits the same, or to draw some other inspiration.

Pick a Direction

Using dice, toothpicks, and meeples, create a game where “Direction” is the driving theme. This was used at an academic conference with a wide variety of audiences from education to corporate, so the theme “Direction” was intentionally chosen to allow a wide range of interpretations, and the components were specifically limited to facilitate quick design ideas.

Think Outside the Box

Using game components and an empty game box, create a game where players must integrate the box into the design itself.  I just think game boxes are an underutilized resource.

The post Lightning Multi-Game Design Jams first appeared on Ludogogy.

The key to designing board games is to set the core mechanism which will provide the fun in the game,  and then connect the sub-mechanisms to make various interesting interactions.

When we design a board game, the core mechanisms, and paper prototypes are the key to continuously providing feedback and improving the game, and to ensuring that the experience of play will be fun.

I will explain what the core mechanism and paper prototype are, and provide a way to structure the core mechanism, and the checklist of the paper prototype.

Core mechanism

In board game design, the core mechanism is the most simple and yet most complex one which the designer will have to think deeply about. This will be the part of the game they will consider most, even when, and probably especially, when several mechanisms are applied.

The core mechanism is what the player recognizes as the most notable feature among the structured systems in the board game, and the most frequent driver of behavior from the start to the end of the game. This is the heart of the game, and all players will get the opportunity to continue the play as new information becomes available to them through the game narrative.

The core mechanism is a model for implementing the major behaviors and progress activities in the game, as well as providing the fun. We can see this is in the core mechanic diagram model which Charmie Kim published in Gamasutra, which is a useful guide to design. In the early stages of board game design, this diagram is useful for communicating the key ideas of the game to others, and for defining the interaction and complexity in the play mechanisms.

The center of this model is the core mechanism which is the key of the game. There is a layer of secondary mechanics, and then progression around the core, and the narrative is outside of that. This comprises the system through which the core mechanism interacts with the game. So, we can easily understand how players can communicate with the game through the interaction.

• The core mechanism is the key to the game and the system through which players interact most frequently in an intentional way. It’s an expression of the game theme or genre. Also, it should be selected to be effective in achieving the game objectives.
• Sub-mechanisms are optional or infrequent interactions. They need to be selected and designed to support the core mechanism.
• The progress system is the source of change in the game. This could be achieved by using events or hidden information.
• Narrative must be designed to be consistent with every other internal layer and to provide a way of eliciting emotion from the player.

Paper prototype

A paper prototype is a tool to use at the early stages of game design to test ideas and check that the experience is fun. It’s necessary for developing board games.

And not only in board games, but in digital game development, the paper prototype is very useful in the early stages of game design to ensure the success of the project and minimize losses through development cost and wasted time. Paper prototype has become very popular in many companies because the many variables in development projects can be immediately analysed, redesigned, and iteratively modified. Also, there are many other positive aspects of the paper prototype.

• Flexibility – Expression of interaction can be quickly confirmed and modified.
• Quickness – Ideas and fun are quickly tested.
• Economical – Development cost is low because only paper and pen are required.
• Accessibility – Everybody can make the prototype because purchasing the materials and developing are easy.
• Scalability – Ideas are freely modified and developed.
• Mobility – It can be implemented anytime and anywhere.

The board game designer has to select the core mechanism for the fun of play and connect the sub-mechanisms for various interactions in game design.

Questions to ask when using paper prototypes

When using paper prototypes to test game concepts, checking whether the game components function well together to create fun experiences is very important.

1. Who is the player? Is this a playable game from that player’s perspective?
2. Are the rules clear? Are they understandable and how easy is it to arbitrarily change and break them?
3. To what extent is the prototype complete? Can others play the prototype?
4. What kind of fun can this game provide? Does this fun have the power to attract people?
5. Is play duration appropriate? Is it too long or short?
6. What games are similar to this one? Are those too rare or similar?
7. Does the player need to prepare a lot for playing the game? Can player easily participate without difficult preparation?
8. What meaning does this game provide to individuals, organizations, or society? What is the balance of Fun and Meaning?

Everybody wants to make a fun board game, but many people fail to do this because they ignore the importance of appropriate mechanism design, and the prototyping and testing to ensure these work well.

To make a good game, we have to experience various games, analyze the original games, and correctly select the ideas and mechanisms that work for our game idea. In addition, making a prototype and getting external feedback through play tests is most important. So, repeating this is the most important task.

The post Core Game Mechanisms and the Paper Prototype first appeared on Ludogogy.

It was an enormous pleasure to co-host this session of the Pizza Game – a continuous improvement game developed by improvement experts Jonathan Grellier and Ed Jepson – with the help of Focus Games.

Andy Yeoman (of Focus Games) joined the fun and ably managed the pizza cooking part of the process. I (wo)manned the toppings station, while Eileen George and Ray Kimball took on the tasks of dough mixing (and rolling), and order taking. Ed took (in the opinion of the rest of us) the easy option of cutting and dispatching.

Jonathan and Ed shared the task of facilitating us through the process.

The game is a great approach to getting your team talking about improvements such as reducing complexity, team communication and resource arrangement and allocation – and much, much more.

You can find out more at the Pizza Game website, or by contacting Andy at andy@focusgames.com

The post The Pizza Game – Continuous Improvement Game first appeared on Ludogogy.

To that end, we’re hosting live play sessions. These could be demos, playtests, prototyping sessions – anything really.

This month, we sadly had to postpone one session, but Corrado de Sanctis will be rescheduling his demo of The Agile Mindset as soon as possible.

The other two sessions went ahead as planned though, and are presented here for you:

Project 911 Project Recovery Simulation

A session co-hosted by Terry Pearce and Bruce Gay, the creator of the game.

Come and play “Project 911” and help its designers refine the game mechanics and game scoring. How will you react to the challenges? What will you decide? Your decisions and leadership will determine the project’s ultimate destiny!

The Working Dead

A session co-hosted by Sarah Le-Fevre and Darren Sweet, the creator of the Ipsodeckso platform, on which this game rus (still under development at time of writing).

The Working Dead takes place at a fictional team building offsite in the midst of a zombie outbreak.

Slaudervale Manor employees become infected and turn into frenzied, flesh hungry zombies, hellbent on munching on the guests (that would be you!).

To survive, players must work as a team to battle zombies, share tools and strategic information, crack escape room style puzzles and acquire codes which unlock critical objects to aid them in their plight and lead them to safety.

Failure to work together and players will quickly join the ranks of the zombie horde and develop a ravenous appetite for the other participants!

Effective teams strive towards a common goal, possess great communication skills and share an ‘in it together’ attitude. The Working Dead with its combination of cooperative gameplay and escape room problem-solving, challenges players to collaborate effectively and drive towards the ultimate common goal – SURVIVAL.

The post Game Playtest Sessions – February 2022 first appeared on Ludogogy.

For example, the ‘Apply in Stages’ card suggests that you break down your content into stages and ask learners to apply it one step at a time to a scenario. The ‘Branching Paths’ card suggests that you create a series of choices, each of which leads to more choices, for the learners to navigate.

Each card has more info about how, why and where you could do this, together with some useful extra tips including other cards it combines well with. There are also seven ‘guide’ cards that offer different techniques to use the deck to inspire your learning designs (including a game you can play with the cards).

I created the deck to distil my experience of designing interactive learning into a tool to inspire learning professionals with new ways to bring content to life. It’s not specifically about gamifying learning, just making it more engaging and effective. But you could call it a toy, or a playful learning tool, and it has many key features that mean that, when it came to transforming the Transform Deck from an initial draft to a market-ready product, I needed to prototype and playtest in much the same way I prototype and playtest learning games.

Jesse Schell is a vastly experienced game designer and author of the Art of Game Design. His six questions for playtesting—the why, who, when, where, what and how of playtesting—were invaluable to me in this process. I’d like to show you how.

Jesse Schell’s The Art of Game Design is available on Amazon

The Deck of Lenses (card deck version of the book) is also available

Why are you playtesting?

This is all about the questions your playtest should answer, and the risks you are looking to investigate and mitigate. Playtests without specific questions in mind get less useful information.

In this case, I wasn’t sure if people would understand how to use the cards. I wasn’t sure if people would be able to use them with content types I’m less familiar with. I didn’t know if I’d included the best selection of activities, or organised them perfectly. I didn’t know if the ways I thought the cards should be arranged and laid out included all of the best ways to inspire.

Each of these don’t-knows can be thought of as a risk. My playtests were designed to investigate and suggest mitigation for these risks, by posing them as questions:

• Do users understand how to use the cards?
• Do they work with different types of content?
• Are any activities less appropriate or useful?

Note that posing these as questions to be answered doesn’t necessarily mean asking the direct question to playtesters. Sometimes it’s better to observe what they do or how they do it. Ask yourself: who is best placed to answer this question, the person experiencing the experience, or me as observer and data gatherer?

By being clear on the questions I wanted answered, I gave myself a solid foundation to design playtests. And I got some great answers to these questions. I dropped, replaced, refocused and merged some cards. I changed the instructions multiple times. I found new ways to use the cards that worked better to inspire users.

Take the time to be clear on your aims in playtesting: the clearer you are, the clearer the useful information you’ll get.

Who should you playtest with?

There are pros and cons to various groups, often centred around convenient people (e.g. coworkers) versus relevant people (your likely audience) versus insightful people (experts).

In this case, in particular, the product is not very relevant to anybody not designing or running learning experiences, and I have convenient access to such people through my work. So, I was able to take advantage of this to observe the intended audience using the product, and glean some incredibly useful insight. I was also able to get insight from games-based learning experts that helped spark ideas to improve the product.

If you aren’t the beneficiary of such a happy accident, you may want to conduct multiple playtests to get different perspectives.

When should you playtest?

The key question here is really at what stage should you playtest, and the answer is often: at every stage. You can test a concept, a rough paper prototype, a ‘full’ prototype with placeholder art, and a fully working draft.

My first prototype was a spreadsheet of activities versus useful fields for each, divided into categories/suits. I discussed this with some sample users, and this helped me clarify the suit divisions, as well as weed out some less appropriate activities. Each stage after this—rough paper cards, cards with placeholder art, draft versions—helped me on the journey, including giving me insights I hadn’t expected. Earlier versions helped with card selection and which fields were more or less useful. Later versions helped with colour choices.

Most importantly, by playtesting early and ‘ugly’, I was able to change things before I became too attached to them.

Where should you playtest?

The key divisions here are effectively ‘your place or theirs’, as well as online versus offline. Again there are convenience considerations, but the more realistic you can make it to how the experience will be in practice, the better the feedback.

In practice, I developed much of this product during a pandemic, so most of my playtesting was online. But I noticed that one early playtest with a client designer team at their offices had a relaxed feel to it, and I was able to record some striking observations about how they reacted and how they used the cards. The richness of face-to-face communication means you can pick up on more subtle cues from playtesters. I probably got more useful info from that one face-to-face playtest than from twice as much time spent online testing.

What should you look for?

There is some overlap with the ‘why’ question here, but whereas that focuses on what you know you want answers for, this question in Jesse Schell’s sextet also cautions us to be on the lookout for the ‘unknowns’—things we weren’t expecting, but that help us.

By observing as keenly as possible during playtesting of my cards, I caught all kinds of unexpected reactions including a tendency to skip the instructions, misunderstandings about the card layouts and how people intuitively used the cards. In one case I saw one person lay out the cards in an interesting and innovative way, and adapted it as an ‘official’ method.

How should you conduct the playtest?

The answers to the other five questions set you well on the way to the sixth, but there are some further key considerations:

• To what extent should you be present?—you want to get great data, but real players won’t always have access to you, and your presence is a source of bias
• How should you introduce/explain things?—this can be a great proving ground for briefings and instructions, but again you want to minimise bias
• Where should you look?—while your instinct may be to observe the game itself, people’s faces can often offer more useful feedback
• What data should you collect?—as well as doing things qualitatively, should you count and time how long, how many, how much?
• Should you pause mid-game to review?—this can break the flow, but if you don’t, people will be subject to recency bias, and you may lose insight on early stages

In my case, I addressed these by, among other things:

• Being present, but hanging back and letting people play rather than getting too involved, and observing keenly as well as asking questions
• Letting them ‘unbox’ the cards themselves and explore before any explanations
• Looking at faces and what they did with the cards
• Noting what cards they used first, in what ways, and what went un-done
• Pausing after each ‘use’ to explore responses

As noted above, the results of this considered approach to prototyping and playtesting were far-reaching for the details of the Transform Deck.

Jesse Schell talks about the ‘rule of the loop’: “the more times you test and improve your design, the better your game will be”. The Transform Deck went through four main iterations with several adjustments within each. I playtested these on a huge variety of groups over a long period of time, remaining open to changes and making them frequently.

The result is further away than I could have imagined from my initial prototype—visually, in terms of content, organisation, phrasing, and most noticeably in the user guide. But it’s closer than I could have hoped to the intent of my initial vision—an intuitive, delightful deck to inspire people to transform learning experiences.

Terry’s innovative learning design tool, The Transform Deck is available to buy from his shop.

The post Jesse Schell’s Six Questions for Playtesting first appeared on Ludogogy.

In boardgames, there isn’t a formal term to cover the set of boardgame playtesting techniques that are about observations of play rather than post-game feedback or questionaires.

I’d like to propose “Observational Playtesting”. For me, these techniques have strong parallels with observational research in a number of other disciplines, such as anthropology, behavioral economics, and cognitive psychology. I work as a designer and user researcher for a large retailer, so my playtesting techniques are very informed by a User Experience background.

 The video games user research community is much more developed than the boardgames one, and many of the top labs there already use these types of research practices to conduct playtests.

In Observational Playtesting, you are trying understand the player experience of a game, paying close attention to the ways they feel and react to moments during play. The best ways to be wholly focused on watching and taking careful notes as testers play (video / audio recording can be helpful too).

If you’ve only taken notes or collected feedback forms at the end of a session, you miss most of what you can potentially capture. The experience of your game happens during the game, so it’s silly to only measure and record data afterwards. Limits of human memory and a number of powerful cognitive and psychological biases make observational playtesting the best way to capture playtest data that is difficult to collect or skewed in post game feedback. In part, this is why many top designers have started asking remote blind testers to video record their game sessions.

Obviously, postgame feedback from the players is still very important and still leads to lots of design improvements. I’m not saying stop having those discussions, but rather that your tests will be more productive if you also use observational techniques.

 I’ve talked a little bit before about this topic before on “Playtest Like a Researcher: Stop Playing in Your Own Tests.” In this post I’m going to dive into what types of data I like to capture while I’m observing a game.

So – what am I looking for?

Key Moments:

At the core of what you want to be watching for are key moments of engagement from the players – the times when the players are most or least engaged with the game, its systems, and their interactions with the other players. While I’m not suggesting attaching galvanic skin response sensors or anything, broadly, if the graph of players engagement looks something like this:

You want to be tracking the circled moments that lead to those upturns and downturns. (the local minima and local maxima)

Keep track of which moments felt good or exciting! Which moments felt boring or confusing? At the same time you’re streamlining your game to clear up weird rules edge cases and bad interactions, you also want to be streamlining it to deliver maximum fun!

Writing down quotes:

Part of understanding player experience is watching what they say to each other or in reaction to key moments during play. Bring those quotes up during feedback: e.g “You said that you ‘wasted a turn’ when you took that action – how did that feel?”. This helps players contextualize feedback, and can prompt on experiences that they might not have otherwise remembered. It puts players in the moment of their experience, and helps compensate for some of the cognitive biases that affect what parts of the game players will give feedback about.

Bringing quotes up at the end helps you mirror understanding of that quote back to the player: confirming that you understand what they meant.

Player confusion and questions:

Understanding the learnability of your games rules and systems is significantly easier using observational techniques than by gathering endgame feedback. I like to note every question players ask during the game (even when they are just wondering and not looking for an answer). These indicate points of potential confusion from players or areas of the game they are particularly engaged with (sometimes both). You’d be surprised how much you can get out just writing down each question players ask, as you can then iterate your components and rules to answer those questions without you there!

I’m also watching for hesitation when making decisions, and when players check printed reference material such as player aids.

Boredom and dips in engagement:

Over multiple tests, you can look for particular times during play that boredom might cluster. Good indications of boredom are: Spending time on their phone when it is not their turn, asking “who’s turn is it?”, looking away from both the other players and the game components, and leaning back away from the table and the game.

Time sub-elements of the game:

Observe how long a round of turns around the table takes and how long a player’s individual turn takes. See if rounds tend to drag on as the game gets toward the conclusion. It also helps you figure out how game length and pacing might change if you added a step, or shortened the game timer.

Watch player dynamics

If your game features player interactions, watch emotional and strategic responses to their moments. How do people feel after the action space they wanted is taken just before their turn? Do players use more aggressive tactics after being attacked for the first time?

Paying attention to inter-player dynamics gives you an idea about how players respond to certain design choices you’ve made, and gives you an idea about how they might react to changes you could introduce.

Final Thoughts

Observational playtesting is a powerful way to capture playtest data. This is a surface level look at some of the things I watch for, but a lot varies test to test and where a game is in its design and development cycle.

I encourage you to be taking notes continuously during play – you’ll be able to iterate quicker and gain valuable insights from fewer tests. When you move to remote blind testing, try getting testers to video-record their sessions so you can capture similar data.

If you are hungry for more formal research-focused resources, I highly recommend checking out:

• Contextual Design by Karen Holtzblatt and Hugh Beyer
• Games User Research by Drachen, A., Mirza-Babaei, P., & Nacke, L. E.

The post Playtest Like a Researcher: Observational Playtesting first appeared on Ludogogy.

0: Here we go

Day Number Zero

It all started one day with one of our corporate clients asking us, “Can you do something different next month?” There was vagueness in the request and desperation in the tone.

They had done enough PowerPoint-driven sessions. L&D was frustrated, business managers were bored and participants were mutinous. They were all at the end of their tether. All they wanted was something different. Anything different. We had an idea.

Game-based Learning is what we felt we should try. We thought we could design a quick game to facilitate a session on Change Management. This is the story of how it came to life – from Idea to Prototype and finally to Finished Product.

1, 2, 3, 4: The Storm before the Calm

One office. Two people. Three hours a day. Four days.

All we did was brainstorm ideas and eat pizzas – lots of both. Beyond the discussions at the office, we were on calls throughout these four days.

Some themes that stand out in my memory involved space travel, sailing across a pirate-infested sea, building a settlement on an island, war prep against a tyrant, building a startup, running a restaurant, and a race to the North Pole.

Somewhere there, we had thought of a game about Running an Organic Farm too. In all fairness, it felt like a very (how do you say) “uninspiring” game. All the other theme ideas seemed much more epic in their scope as well as meaning. I still have no idea why, then, we were drawn to the Farming theme.

In hindsight, I am glad we were. The idea provided so many possibilities and so many real-life inspirations. I can’t think of any of the other themes which could have given us so many facets to work with.

5, 6, 7, 8: Let’s dance

To the tunes of every constraint

The next four days went in interviewing a wide variety of people and making tons of notes. We spoke to L&D and IT departments. We spoke to potential participants and their managers. We spoke to game designers and graphic artists. We spoke to coders and database designers.

Each conversation took us farther from any form of consensus. There were new constraints, contradictions and conflicts unearthed at each step. We had to keep in mind, among other things, the requirements put forth by L&D, participant interest (or sometimes lack thereof), shortcomings of the platforms approved by IT, and worst of all, Internet bandwidth issues due to participants spread all across the world during the pandemic.

This is what the requirement document looked like. (It was enough to make grownups cry):

1. The game has to be played collaboratively – but must have some competitive elements
2. The game has to be played strategically – but must have some elements of chance
3. The game must include all participants who are present – but not mandate their presence
4. There must be clearly assigned roles – but the game shouldn’t stop if someone drops out

9 to 11: Run away? Or run with it?

In India, 9-2-11 is a colloquialism that literally means to run away. Don’t ask why!

For a while, we seriously considered declining the project. After investing so much time and energy in it, the roadblocks seemed too many to deliver anything worthwhile. We agree that “Creativity stems from Constraints”, but surely there has to be a limit after which they just become a hindrance and not worthwhile anymore.

Good sense prevailed though. A little because it was a long term relationship with this client, and a little because we had come to love the hundreds of hand-sketches and notes enough to want to see the game in action. But, mostly because we got on board a wonderful game designer. Shoutout to Psy Sai.

With her creative input and long hours of discussion, we found an answer to pretty much every question that was troubling us.

12, 13, 14, 15: The Grind

The days are a blur, but the game becomes clearer

After much discussion, making, testing, breaking, remaking, here’s how our erstwhile hopeless requirement document had become. Some aspect of the game addressed every constraint and turned it into a strength.

1. A team of 4-5 people will manage a farm each. There will be multiple teams simultaneously managing their own farms. They’ll play collaboratively within their farm, while competing with other teams. Collaborative & Competitive: Check
2. The game has decisions to make about cost of sowing, duration of harvest, revenue from the yield, matching vegetables to soil types – all strategic decisions. Investment decisions are to be made to improve profits, protect against disasters, get intel about weather and general consultation/advice – still very much strategic. Market demands fluctuate, and weather and other disasters wreak havoc – all of which depend on chance/randomness. Some you can plan to mitigate, others are out of your control. Strategy & Chance: Check
3. Due to obvious internet bandwidth issues, we decided to not make the game turn-based. Instead the game time keeps running in the background. Every 10 seconds represent one game day, and if even one player in the team is online, the clock keeps ticking (and the calendar keeps flipping). Everyone can play, but no one is missed if they are missing. The game goes on. Everyone Involved & Everyone Not Mandatory: Check
4. Everyone can discuss and decide. Everyone can sow and harvest. Everyone can invest and liaise. Clear roles can be picked from a list and adhered to as an agreement between the teammates. But the game puts no restrictions on who can do what. Roles are suggested, even encouraged, but never imposed. That way, if someone with a specific role drops out, the game doesn’t come to a standstill awaiting that person to join back. Role & No role: Check

 A game was born. Those four days of work had created a game so well-rounded that even after nine months of continuous tinkering, it has retained much of its original essence.

16: Bittersweet emotional day

You win some, you lose some

One of our big advantages is that we have a solid tech background as I have run a software development company for a decade. Our prototypes aren’t built on Miro or Google Docs or other collaborative tools. Instead, we code them as standalone software. The benefit here is that when the game is done, it’s done. Nowhere else to go. No one else to talk to. Nothing else to do.

The prototype is ready to use – pretty much right away. In the past, this approach used to take us a little longer than using publicly available platforms, but now we have enough pieces of the puzzle ready that we can assemble our software in days and weeks, rather than months.

Anyway, we present the product to the client. They absolutely love it: the attention to detail, the turnaround time, the debrief possibilities. They love everything about the game. We have a deal.

This felt too good to be true. And, it was.

Last week, their IT department decided to ban Zoom. Unfortunately, MS Teams didn’t have breakout rooms (at that time). How the hell do you play this game without putting people into breakout rooms? We felt… well I can’t put in words what we felt – not in print at least.

17, 18, 19, 20: The Grind (Again)

Communication is the Lock!

The most amazing game we had created to date could potentially not get used by the client who commissioned (and loved) it because their IT department made some decision. In hindsight, 20/20 as it is, I can’t thank the IT department enough for their contribution in the form of this new constraint. While it pushed us to our limits, it made the product that much better.

Our two-week timeline was now shot to smithereens. We were back to the drawing table. We tried and tested dozens of options, while the most obvious solution to the “No Breakout Rooms Allowed” problem patiently awaited discovery right under our noses.

Two days later, after discarding one hare-brained idea after the other, we finally saw it. We had to create our own chat system – deeply integrated into the game. The actual work itself was pretty simple – once the idea was approved. We added text and voice chat into the game. People could now communicate with their own team as well as with the facilitator using it.

We tested it over the next few days, and found it worked like a charm. Due to a few other IT constraints, we have now put audio chat on hold, but the text chat has proven adequate to scale the last, seemingly insurmountable mountain.

21, …, Today: Here we are

The Home Stretch and WIP forever

We have a game that is fun for the players to play, even more fun for the facilitators to facilitate and different (and more impactful) for the L&D Department. We have a win-win-win product which is creating quite a buzz wherever it goes, and we can’t be prouder of it.

This is how the Player View looks with some portions trimmed for brevity.

There is also a robust back-end Facilitator View to manage the game. It can be used to change market demands, bring disasters on demand, see everyone’s chat, move people around in teams, allow/block investments, pause/speed up/slow down the game and many more things.

More changes are on the way, the next one is code-named The Four Seasons and deals with automations relevant to Seasons. So Farm So Good (SFSG)  is an agile game – not just in the way it is played or facilitated – but also in the continuous improvements we are making to it.

Creativity does stem from Constraints. The more the better. Also, #WIPForever

A live play session of So Farm So Good featured in our Make and Break sessions. Watch it there.

The post So Farm So Good – from zero to ‘done’ in 21 days first appeared on Ludogogy.

Playtesting

Playtesting is the moment of truth, the moment that you or other players try your prototype and you record the feedback and reactions and try to understand what works and what needs to be changed in the game. Playtesting can be useful to improve game design even if one person plays your game. You still gain loads of interesting feedback that can help improve it. Don Norman (2013), one of the most famous researchers of cognitive design and usability that helped Apple design some of their most iconic products, suggests that testing your product with five users helps identify 85% of the problems the design has at that stage of development.

Prototyping and playtesting are a coupled iterative process that can happen again and again until you feel you have a game that can go into the final design and production phase. Fullerton (2018) presents the below model conceptualising the relationship between prototyping and playtesting and how the process helps you test and narrow down your game’s details the further you go into the design and development process.

The Iterative Game Design Model demonstrates the process of going from your initial prototype to the final version of the game with play testing sessions providing data that are evaluated and then enable revisions of the game. Playtesting helps identify what game elements are working and which ones need some tweaking, always keeping in mind that game designers should be serving the game’s end users.

HOW TO RUN A PLAYTESTING SESSION

You and your team can be the first play testers and many times there are a lot of insights that you can draw from playing your own game but there are limitations to how much you can learn from people that are close to the game. After you make sure you have a playable prototype you can give it to your close friends and family to try out but again do not forget that these people are close to you and they might be biased towards liking your game or might have a hard time giving you honest feedback because of your personal relationship. The best play testers are people you do not know that can be considered potential end users.

If you are making an educational game for elementary school kids for example, testing your game out with children or their teachers can be very useful. The first thing you need to avoid when playtesting is to defend your game. Ideally, someone else should be facilitating the playtesting sessions and game designers should be just observing or watching a video of the playtesting session afterwards. The point of playtesting is not for the designers to pitch the game to anyone but to identify which elements of the game work and which elements need to be tweaked or even taken out. Listen to everything the testers say and write it down or record it with your phone or on video if possible. There will be plenty of time to analyse the data your testers give you. Do not answer a lot of critique during playtesting. Just make sure you write everything down. Before you start playtesting do not pitch your game to your testers, there is no need for a 15 minute presentation of why you built this game and what the goal is and what your aspirations for it are. A 2-3 minute intro to the game and a brief explanation of its rules are enough. Ideally you should have written all the rules on a piece of paper and players should be able to play without your help.

If you are part of the game design team, I would advise that every member of the team be present at the playtesting session if possible. If you have a team of twenty people or some similar large number, make sure to record the session on video and share it with everyone. It is normal for a designer to get defensive about their game. If the feedback is visible to all though then there can be no disagreements about the changes that should be made to improve the game.

Check out the review of Vasilis’ book ‘Designing Games and Gamification for Learning here

The post Adding Playtesting to your Game Design Process first appeared on Ludogogy.

I am immensely gratefully to all the wonderful contributors to Ludogogy who participated in this tie-in event and gave generously of their time, expertise and playfulness to make it such a great event, and a useful resource into the future.

I hope you enjoy what you see below, and that you will take the time to connect with these game creators and find out more about what they do.

The panel disscussion on 14th September saw great tips and insights from (L to R, top to bottom) Andy Yeoman, Sarah Le-Fevre, Joe Slack, Laxman Murugappan, Mohsin Memon, Mihaela Danciu, Erik Agudelo, and Andrew Lau.

On the 19th September we were lucky enough to run two game demo sessions, The first was with Mohsin Memon, who took us through a thrilling round of Evivve, the Leadership Game. Did the team win or lose? You’ll have to watch and see. You can also read Mohsin’s other articles.

The second session had the players/learners running a farm in a round of So Farm So Good. This was run by one of the game’s creators, Abhilash Purohit. If you want to know more about how this game was created, read this article from Abhilash.

On 21st September, we got the opportunity to learn about creating our own worlds, courtesy of Eduardo Nunes and Bruno Gavaia. In a fascinating session we looked at  a number of free resources which can be used to generate maps, narrative, player characters and even currency. We learnt how learning outcomes can combined with narrative to create compelling quests, with which learners will eagerly engage.  Make sure you get time to read Eduardo’s other articles, about his game ‘Liber Domus’.

The 22nd September saw two appearances in one day by long-time friend of Ludogogy, Terry Pearce. First of all, he took us through his latest project, a set of practical and beautiful cards which help learning professsionals put more play into their learning designs. You can read Ludogogy’s review of these cards here.

… and then a couple of hours later he was back, along with Matt Stevens, Ben Stevens and Jessica Roberts of Lessons Learned Simulations and Training, to playtest the Humanitarian Crisis Game. If you like the idea of a game which has a mechanic based on Maslow’s pyramid, then this is one for you. You can read Terry’s articles for Ludogogy here.

Erik Agudelo is soon to launch his innovative learning design tool, Toolbox 4 Creativity (TB4C) on Kickstarter.  But he stopped preparing that for just long enough on the 23rd of September, to host a session showing how the principles behind that idea work.  If you want to find out how the affordances of game design can be used to create a deep learning experience for learners in any topic, then this session is for you.

On Friday 24th September, we experienced two very different games, with very different approaches to equally serious issues. Andy Chong Brought us Fishy Business, a game where your team can learn about running a sustainable business by harvesting the bounty of the ocean. Massive Kudos, too, to Andy for creating a beautiful rendition of his game in Miro, which as anyone who has attempted this will know is, as Andy put it ‘A Boss Level Challenge’

Richard Schreiber of Unite2Games has an important mission – preparing young people to be the leaders of tomorrow.  His Ubuntu Game strives to tackle issues of Diversity and Inclusion by prompting teens to engae with each other through a series of questions and quests – each of which has the potential to be a deep conversation-starter.

Our final day of live sessions for the Make & Break event kicked off with a very innovative application for a game – the conversations we all need to have when onboarding a customer and getting to the bottom of what it is they want to achieve through working with us. Laxman Murrugappan, Mihaela Danciu and Alejandro allowed us in at a very early stage in the development of their game – which seeks to build this important realtionship between supplier and client, by having them prepare a delicious feast together.

And last but by no means least, Antonis Triantafyllakis brought us Nutstarter, a pun-fuelled quest to guide a colony of squirrels through the process of raising funds (acorns) from their community to build a Nutapult (or Trenutchet (like I said – puns) in order to defeat a marauding dragon who wants to steal their winter stash of nuts. If the crowdfunding sounds familiar, so it should. This is a learning game about running a Kickstarter campaign.

The post Focus on… Make & Break Live Events first appeared on Ludogogy.

And so, the story goes like this: “No one likes to be told they have an ugly baby”. Heavens knows, us game designers regard our games (even very early prototypes) as our babies. Naturally we don’t want anyone saying anything bad about them. And that’s a mistake.

In spite of how compelling this analogy sounds – comparing physical babies [flesh and bone ones] to games we create [brain children] – it falls a bit short. For instance, with flesh and bone babies we cannot take them apart when they don’t perform as expected. We cannot remove features, improve some others and create new versions – someone please explain this to my father. He now has 7 kids and they, us, are not really getting any prettier with each iteration (I don’t have daddy issues… alas, I do).

Something else we are meant to the prototypes of our games that we cannot do to our flesh and bone children is: dress them up in their best clothes, take them to competitions, line them up and let complete strangers judge them and pick a winner, the prettiest.

Oh wait. We do do this. We do have baby beauty pageants. But I’m not ready to open that ugly can of worms at this time.

It would appear that we then need a better analogy. Else, a better explanation as to why we resist, sometimes despise, prototyping our games with strangers.

The reasons we as individuals make decisions and perform activities are complex. These reasons change constantly. Multiple forces simultaneously influence these reasons.

More importantly, these reasons are formed in the unconscious mind. Asking a game designer why they are not playtesting their prototypes is the best way to get the wrong answer.

But look at populations, groups of people, and Eureka. Those elusive reasons turn into patterns. Some of these patterns are easily explained through biases and heuristics.

Ideas are sticky. Whatever thought, conscious or unconscious, we believe is the result of our own making, we will defend viciously. And this is a bias. A very dangerous one for that matter.

A simple explanation about the danger of this bias is that these “original” ideas can be easily implanted in our heads. You, me, all of us can be easily primed to arrive at our unique and expected conclusion. Social media does a great job at amplifying this condition of the human behaviour. But that’s another can of ugly worms to be opened at another time.

Your games. Our games. They all start as ideas. You then invest a lot to take this idea and turn them into physical projects (yes, even digital games). These physical products are now much bigger ideas.

Trends in human behaviour show us that we do not like having our ideas being challenged. We have visceral reactions when we are told point blank “your game sucks”.

Yet, these are biases and we need to find ways to ensure our game is seen and used by other people. We need to seek feedback, collect this data and build it into the design of our games.

In summary, we need to play-test our games multiple times. We need to do this in spite of how loud that little monkey inside our heads screams at us “Your game is perfect as it is”.

Check out Erik’s archive of Ludogogy articles

The post Playtesting and the Ugly Baby Complex first appeared on Ludogogy.