As many of you already know, I work as an Agile Coach for a large organisation, and I am a creator of agile serious games. In fact, I deeply believe that playing a game can be often more effective than a classical lecture or presentation, particularly when we are talking about a soft skill (which an agile mindset definitely is).

Creating games is also a way to apply the agile approach in different contexts. If you are thinking if agile is just for IT, you are wrong!

I already successfully applied agile in marketing, HR, finance and, obviously, in game creation. If you are wondering what agile is; this is too long to summarise here. Just to give a clue – agile is a way of building great products in uncertain scenarios: based on values, principles and practices. This successful (and fun) way of working requires a different mindset, and this is why you (or your company) need coaching (and not training). For more details Google is your friend, on the web you can find zillion of articles, or maybe you can follow me on Linkedin because I often write article on agile topics.

In this article, I will try to describe the process of creating a game, using agile. In the next three chapters I will introduce a basic agile process (Design, Build, Improve) and I will present in each of the sections one practice directly derived from agile practices, showing also a specific real example.

Keep in mind, that today, there are hundreds of agile practices, and very probably all of them could fit in your work. However remember that applying a practice without the proper mindset (values and principles) is only a mechanic and is not really effective.

To help in this r-evolution Agile Game Factory is working on a specific game on the connection between Mindset/Principles/Practices in agile. Stay tuned!.

Update : You can see this game in action in Corrado’s live playsession of The Agile Mind

Designing a game

When you start designing a new game you have to keep in mind very clearly WHY you are building the game. To help in this process, I have developed a Game Vision Board. This is directly derived from the  Product Vision Board by Roman Pichler and is adapted to the specific context of game design.
This canvas is composed by 5 areas where creators can put main the attributes of the game and, at the end, the Vision statement that will guide them in all decisions. These attributes are:
1) TARGET: who are the players? (think of personas, how many, interactions, …)
2) NEEDS: why players want to play it? (think of what is motivating players to play it)
3) FEATURE: what makes the game stand out? (think of unique/new and imported/improved mechanics, components,… you would like to have)
4) GOAL: why this is useful for us? (think of what is motivating us to build it)
4+) How do we MEASURE success? (think of some metrics and how to measure them)
5) VISION in a sentence (think of a tweet)

FOR EXAMPLE, recently, I worked with a team of serious game designers on a possible new game about sustainability. We spent a couple of sessions to understand and share our ideas around this game and we put everything in the canvas below

Clearly we could have had an open conversation, but the canvas gave us a few rules and helped us to have a well-defined outcome to be used in the future.

Building a game

To build a game you can use Kanban or Scrum. These are the most used agile frameworks which are also PERFECT for gaming. First, you have to identify the parts of the game to build; then organise them into small pieces and prioritise them. Later you can build starting from the most relevant piece. Prioritisation is very important because this lets you create MVPs (Minimal Viable Product) of the game at different levels and test them following an iterative and incremental approach, collecting more and more information around your game.

Note that you can use this approach also for more complex activities like designing a mechanic or writing an instruction manual / rulebook. Furthermore, the fact that you have designed the game starting with a vision, helps you to keep the right direction. Finally agile frameworks are great if you are working alone, but they are much better if you are a team.

FOR EXAMPLE, I am currently working together with a team of six people distributed across Europe to build a new narrative RPG. The image below is a section of the scrum board.

The board is a visualisation of the process to build stuff, and each stage has “cards” that represent activities, mostly directly related to the players’ experience.

Improving a game

To understand if a game is working or maybe how you could improve it, you need to collect feedback.
Feedback is one of the core attributes of the agile mindset and, for a game, comes mainly in two modes: from play-testers and from actual players.

To collect feedback for a game, I have created a dedicated model called TARGET from the initial letters of the six dimensions:

• Theme: Is the theme enjoyable and close to reality? Is information on which the game is based  realistic? Is the goal of the game consistent with the theme?
• Aesthetics: How are the materials of the game? How is the iconography of the artefacts? What about readability of the information (cards, rulebook,…)?
• Replay-ability: How can knowledge of the game change the game experience? How many variants can you play? How many player combinations can be used?
• Game length: Is the game length consistent with theme? Are there some moments where some players are only watching? Is the flow of the mechanic fluent or start & stop?
• Ease of play: Are rules clear and straightforward? Are there some weird exceptions to normal flow? Is  there support to explain the game?
• Tactics & strategy: What is the role of luck? Can players predict, monitor and control different phases of the games? Are players able to adopt different working behaviours?

Note. The TARGET model has been presented in this article.

You can measure each of these with a score 1 to 5 (or stars) and with open text to ask the players how you might improve the actual score.

As you can imagine, this can be easily automated using an online form.

FOR EXAMPLE, at the following link you can find the Google form I have created for Agile Game Factory’s customers.

Here a link to an article showing how impactful feedback from real players can be.

Final thoughts

Sometimes, you may want to check if a hypothesis can work in a multi-layer context.

I can show an example strongly related to this connection between agile and games. At the moment, I am working in agile on a agile serious game on the core concepts of the agile mindset. This is a three-time spiralling logic and it is probably a tough use case to check an idea. however apparently it is working. So the final thought is that agile works.

The post Applying Agile Practices to Create an Agile Serious Game 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.

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.

In addition, the process mainly involves clarifying the vague points, adding fun elements or reducing boredom, balancing the victory situations, and so on. This according to Techopedia. While Playtesting is a term that is applied commonly among PC and or role-playing games, we applied the basic playtesting principles first to our physical board game version.

There’s more about the Ubuntu Game in this article about debriefing and feedback

Validating the Game through Playtesting

Both Prototyping and Playtesting play an important hand in hand role in validating your game or application.  We created our version of our game or application, often called a beta test or prototype, based on some early assumptions about our MTP which included who the target audience is, what problem we’ve identified and are solving and how we can create an intuitive, enjoyable gaming experience for our target audience. In the chicken and the egg schematic, your prototype of course precedes your playtesting, which puts your prototype through some hopefully tough validation paces.

Most of us develop our prototypes based on an initial, limited number of features and characteristics that we generally feel will have broad based acceptance among our audience and user community. This is also commonly called an MVP or minimal viable product. At Games 2 Unite, with Ubuntu Game, we were ready to first try it out internally before we expose it to beta test customers or initial adopters. Our initial prototype was actually a physical board game.

Games 2 Unite launched its Ubuntu Game prototype in June. We built an MVP based on what our MTP was. Our target audience is teenagers of different ethnicities and cultures who together play our game to, through questions and collaborative activities, learn about their differences through conversations around diversity, inclusion and equality along with some of the critical issues facing the world today like climate change or overfishing. Once our MVP was created, we turned to Playtesting where play testers playing our game.

Piloting with the Target Audience

First, we play-tested our physical board game prototype internally to validate the mechanics of the game and to fine tune our user instructions as needed, we were then ready to take on exposing the prototype to our beta test users. Our early beta customers not only played the game, but recorded feedback on a micro level detail, validating our actual questions in terms of what landed well for a teenage audience. Playtesting with our ideal audience was invaluable in validating our game and processing improvements that went into the next iteration of the game.

Our next Playtesting will involve the digital version of our game through a platform called Tabletopia. We will again engage our target audience now with the digital version of the prototype and not only process the feedback but compare the feedback to the initial physical board game version. The true test will be what is called Blind Testing, where the testers have no prior experience or exposure to the game.

Prototyping is an important milestone and accomplishment as it serves as the first version of your gaming application, but one word of caution is to not get too attached! Some of the feedback you can get through Playtesting can be critical, even harsh and with any MVP or prototype, be prepared for the worst and the best. Even if you have to significantly course-correct given the feedback on your prototype, imagine staying the course without that feedback. This would be a sure failure!

The Ubuntu Game features in our Make and Break live play sessions

The post Prototyping and Playtesting – Games 2 Unite’s Ubuntu Game first appeared on Ludogogy.

3D printing workshop

In 2014, I led 3D printer assembly workshops. Students had the opportunity to build their own machine. They not only improved their mechanical skills, but they discovered cooperation and the exchange of know-how in programming and project management. So I had the idea to hack the “Arduino” boards, the sensors and actuators to make my own materials characterization instruments. The concept of the role-playing game “Hack and jaM” was born.

Hacking 3D printer parts to build a new device

In materials science we need to know the mechanical and thermal properties to choose the material suitable for a specification. In a 3D printer, all the ingredients are there for the design of a new prototype. Teams of six players challenged each other to design a new measuring instrument. As a client, I announced my expectations to clarify my needs. The players then had to analyze the market and check the overall feasibility. As the game master, I announced unforeseen events that players had to adapt to. Due to the limited duration of the session, the players had to outsource some of the work. To avoid boredom during the session, I limited the number of players to three per team : a project manager, a business engineer and a designer. The agility of the role-playing game has allowed the emergence of new rules such as the use of a currency: experience points, XP. The first six students who enter the room earn 100XP for their team. If a player character does not have a skill that slows down the progress of the project, he or she has the option of going to training. Delay points and a loss of XP are counted but
the success of the project is guaranteed.

Soft Skills development in Project Management

Although the main theme is mechatronics, students are assessed on skill development. They will know how to choose a sensor (temperature, pressure, force) and how to physically connect them to an “Arduino” board. But they will also know how to organize themselves, how to distribute tasks, how to manage time under stress. And they will also have to adopt collective intelligence strategies to solve complex problems. Sometimes I ask for the design of an instrument with a lot of features. The teams work on part of the problem first. Then they come together to share their progress and join together to complete the challenge.

Patent filing and book writing valuation

I first used Post-it notes for the first play tests. I then quickly designed square cards in 3.5 inch format using LATEX. A pattern-matching and color coded key on the cards allows the technical feasibility to be checked. The cards also serve as a “supplier” catalog. The card game has been patented (e-Soleau). University of Montpellier has supported a patent filing of “Hack and jaM” Role Playing Game (INPI). The game play can be easily adapted for other situations in Project Management, e.g. how to organize a social event, or how to develop a new prototype and so on.

Laurent’s book – Innovation Pédagogique, Serious Gaming et Game Design (French Edition) is available from Amazon

The post “Hack & jaM”: The birth of a Role Playing Game first appeared on Ludogogy.

There is no doubt that 2020 was a challenging year for many, and for young people in particular. It impacted their learning, both academic and emotional. It was with this in mind that I signed up for a course with Future Learn, and naturally it was the LEGO aspect that attracted me. Coping with Changes: Social-Emotional Learning Through Play is a course developed by the LEGO Foundation. It’s available for free online and participants can proceed at their own pace. The LEGO Foundation was established to build a future where learning through play empowers children to become creative, engaged lifelong learners. The skills developed through the course enable participants to redefine play and reimagine learning so children develop the broad set of skills they need to thrive and succeed.

Knowing that I work with young people and knowing the barriers they have faced in the last few months, the idea of combining play with meaningful learning was a resource I was interested in.

A few months later, the annual email arrived – would I like to come and deliver a LEGO session for two hours with young people from the ages of 8 – 12 years? To my surprise I was delighted to accept this time – I wanted to use the new ideas to tailor a session that would be truly beneficial and FUN!

Firstly, I had to reflect on why the previous sessions hadn’t worked, what had gone wrong and how I had known this? Simply put, the organisers wanted the young people to have a session designed around a theme. Year 1 had been “Our Community”, Year 2 had been “Superheros” and both years had issues.

With such a wide range of ages, it can be challenging to keep everyone engaged, 12-year-olds can become immersed in a build while 8-year-olds want to show you every single stage of their build. Some children naturally levitate to teamwork while others are very happy to work on their own. While some children could have built all day long, others felt they had achieved their goal very quickly. Very often it didn’t feel fun and it didn’t feel like they had the space to learn from the session.

What made this year different then? No theme. When the invitation arrived I immediately explained I had participated in this course and wanted to develop a session specifically around the ideas. The organisers were delighted with the idea, understanding the impact of recent months and a need to bring young people together again.

The first stage of planning was to develop activities that could be done over different time scales; something quick for young ones who want to explore it all and something more complex for older children.

One of the principles covered in the Coping with Changes course is the idea of Chain Reaction, building together to achieve a result. To address this I developed a Marble Run activity, with a range of bricks to add height, textures and movement so builders could explore how to make an obstacle course with different elements and challenges.

Another principle covered in the course is strategies for well-being. As the parent of a young child, I know just how popular fidget toys are at the moment. To address this I developed a Fidget Spinner activity. Ideal for the young builders the challenge was to use the selected bricks to build a Fidget spinner to generate something for them to focus on, to reflect.

Finally, another aspect of the course I wanted to incorporate into the session was social-emotional learning, how to communicate with others, how to respond to challenges. For this, I developed the Island activity. Each builder had a base plate and some time to design their own island. Then, when ready, there was a set of challenges for them to pick from i.e. “Zombies are invading, build some defences!”, “You are bored, make your camp more fun”, “You are running low on food, what do you do?” As a result, the builders can work together to solve the problems and share their responses with others.

Another valuable lesson I took away from the course was the benefit of free build time as well, and letting them be creative. As well as the range of building activities, we had a carpet of bricks in the centre of the space where builders sat and built, when they had completed the activities at their own pace, often incorporating ideas for earlier builds, such as adding story to the Marble Run using mini-figures and props. As a result, the builds started to come alive, to have meaning and to communicate the fun they were having.

I’m delighted with this approach and it took me so long to understand how to make the most of these sessions with young people, however, the course enabled me to reflect on why it hadn’t worked, to place meaning on the activities and to design a session that supported the learning of young people, our builders of the future.

See other articles focusing on Lego including Lindsay’s article on Lego^® Serious Play^®

The post Taking time to get it right – even if it’s three years first appeared on Ludogogy.

But alongside those, there is also room for exercising your creativity by creating your own play materials, and expanding your view of what might be acceptable materials to use in ‘paper’ prototypes and playtests before you settle on the final form of your game.

There are two reasons for following the hints and tips below.  First, you may be prototyping or playtesting on a tight budget, so the more you can save money on your materials the better. The second, and in my opinion, even more important reason is that making your own toys and game materials allows you the opportunity to play – the very specific form of play / fun which is afforded by Making.

There are well-documented wellbeing benefits of making, which can have effects similar to meditation, increasing levels of dopamine, decreasing anxiety, stress and even depression

As games designers, we often tout the benefits of getting into ‘Flow’, which is at the heart of how people become, and remain, engaged in activities which are just at the right level of challenge. People learn better when in flow, they achieve ‘effortless’ productivity, and it can lead to feelings of joy and happiness. Embracing making into your practice will increase your own experience of flow in your work.

Creative activities, such as making, equip you for improved problem solving. Indeed the making itself, can actually be a problem solving response. As such, making concrete artifacts can have numerous positive benefits on our practice as designers.

What you can use as play materials or the extent to which you embrace making as a practice, and the simplicity of elaborateness of the artifacts you create is really only limited by your imagination, but a suggested toolkit for making might contain the following.  You can even carry this with you to playtests/prototyping sessions in case you need to make on the fly.

• Cutting tools – scissors/scapels/craft knives etc
• Sticky stuff – glue/tape/glue stick or even hot glue gun if you are a dedicated crafter
• Mark-making stuff – pens/pencils/markers/paints
• Containers – you can never have enough of these to keep your materials in order. Save shoeboxes/ product boxes etc. Gift boxes of toiletries (Christmas is coming) are great because they are robust and often have clear lids.

Plastic fantastic

Made materials can come in two forms – fixed (those which cannot be unmade or remade once created) and flexible (reusable). For minimum waste and impact use flexible resources early on in your prototyping journey, and only use fixed resources if you have settled on a final(ish) form of an artifact or if the flexible form is to fragile for long term use.

For example, a good selection of Lego bricks is ideal for making and remaking playing pieces. These are especially useful for items such as tokens (pieces which represent a player), and counters (representing points), and as such, a good selection of smaller bricks are recommended. However, you can also build larger components, such as boards, and the Lego Dots range provides potentially limitless possibilities when combined with base boards.

When you are ready to create something more permanent, a good option is using Hama (Perler) beads. These are ‘fixed’ by melting with an iron, and are great for creating anything with an ‘8 bit’ vibe. Although the standard way to use them is to create 2D pictures, with a glue gun you can create 3D objects. They come in three sizes, the most popular ‘midi’, ‘maxi’ – designed for small fingers but great as are, as counters, and ‘mini’ – really tiny, but can produce stunning works of art because of the level of fine detail that can be achieved.

If sculpture and modelling is more your thing, then plasticine provides an excellent ‘flexible’ option, and you can move to Das or Fimo when you want something more permanent. Das gives wonderful effects when textured objects are pressed into it, and works marvellously well with coloured pencils, which can be blended on its surface when dry to make truly beautiful coloured objects.

A word of warning – never mix any kind of modelling clay with Lego. Absolutely NO GOOD will come of that.

Crafting for Games Designers

If you start to view your prototyping and playtesting as an opportunity to extend your experience of different kinds of making, then you open yourself to new experiences, skills, and the joy of working with your hands. Here are some ideas for potential making opportunities.

• Soft crafts such as sewing. While this is not immediately obvious, consider how fabric could be used to make playing surfaces, such as boards and playing mats. Felt is a versatile non-fray material which can be sewed or glued, and stitching is among the most versatile and beautiful methods of decorating surfaces.
• Knitting and crochet – I can’t think of anything more charming to pay with than ‘amigurumi’ player tokens
• Origami – making playing pieces from folded paper is inexpensive, and gives you the option to work with colour and pattern as well as form
• Wooden playing pieces say ‘quality’ to most players, and pyrography is a surprisingly easy and equally surprisingly inexpensive, way of making wooden pieces with pictures and other marks.
• Relief printing with lino cuts or even just the humble potato can make the most beautiful cards and other paper components

Plundering your other games

Not strictly speaking a making activity, but ‘borrowing’ components from your existing game collection is not only inexpensive (free), but often brings inspiration along with practicality.  If you doubt this, consider how many games (other than chess) are played on an eight by eight chequerboard, or how many card games feature ‘suits’ (or even how many have 52 cards).

A fun and creative plundering activity which has reaped many benefits for me is to randomly select components from a number of game boxes and to force yourself to include them in some capacity in a game design you are working on.  It is surprising how many times this results in a breakthrough design idea.

Nature’s playing pieces

These are especially appropriate to work with when creating games with a natural theme, but many things you can find in nature are so useful as playing pieces that you shouldn’t let your game theme hold you back. Use them as they are, or carry out further joining, cutting, mark making or embellishing to make more appropriate components (and increase your making pleasure).  Good stuff to look out for:

Pebbles, seeds, nuts, sticks, leaves, sand, bark (as a surface), feathers, logs, fibres (for joining, tying or even felting in the case of animal fibre), slate (great for boards and play mats)

Recycling and upcycling

There is nothing, literally nothing (OK maybe food waste – and other icky stuff) that cannot be upcycled or recycled to serve as a game component. I have already mentioned boxes, but the very act of looking at every piece of ‘rubbish’ that passes through your hands, as if it were already useful, increases your creativity. Here are a few ideas:

• Plastic milk cartons – can be cut into shapes and coloured with marker pens to serve as ‘standees’. The plastic tops make great standee bases, when you make a slit in them, or can just act as counters, as they are.
• Bottles and jars – obviously great containers – but I have used these as scoring mechanisms – the level they are filled to representing the score – (better filled with sand than water – for obvious reasons)
• Plastic bottles – use as playing pieces for ‘giant’ outdoor games (imagine something like the giant outdoor chess sets)
• Card and paper – I’m sure you can work out how this could be used, but for general day-to-day ‘scrap’ – receipts and so on
• A box full of old DVD-Rs were once made into circular playmats with Sharpie decoration and writing – and these are, as far as I know, still in use, six years later.

Edibles

When I played my first Legacy game, I have to admit to a certain amount of resistance to the idea of destroying and/or defacing game pieces. I really liked the idea that the game world would irrevocably change.  In fact, I was really excited about the possibility of the legacy format for learning games around areas such as Climate Change and Ecosystem Degradation.  However, I still couldn’t feel comfortable with the idea of spoiling the perfection of a beautiful designed and made game – and let’s face it, games are not cheap items.

A couple of years ago, I came across a book which might have made the legacy format a little more palatable (pun intended) The Edible Games Cookbook by Jenn Sandercock contains a ‘bakers dozen’ of games which you first have to bake or cook, and which you will eventually eat as part of the gameplay.

From cake boards, through sweets used as tokens, to secret codes baked into treats, the potential for creating edible game components is pretty much limitless.

I hope you have enjoyed this brief exploration of the possibilities for bringing making into your games design practice. There are many more ideas which I haven’t even touched on here, and that is the point. Games Design requires creativity and making kills two (and potentially many more) birds with one stone. Not only does it provide us with the concrete components we need for prototyping and playtesting, but it makes us more creative with each project we attempt – benefitting our work and bringing us joy and flow along the way.

The post Putting the play of making into your Playtesting first appeared on Ludogogy.