Using Keep Talking and Nobody Explodes in a university setting

Some thoughts and experiences from running the game as a seminar for psychology students.

Author

Håvard Karlsen

Published

November 20, 2022

I first played Keep Talking and Nobody Explodes sometime in 2015 or 2016 and was struck by the communal state of flow that all participants entered. Hours flew by as we defused bomb after bomb. As time pressure necessitated increase efficiency, we organically improved our communication and teamwork to master all challenges. Since then I’ve always wanted to use the game in a teaching setting, to see if if would make the abstract principles of communication and teamwork we’re teaching them more tangible. In 2022 I was finally able to test it out, and it was a blast!

What is Keep Talking and Nobody Explodes?

It is a game developed by Steel Crate Games released in 2015, available for all major consoles and devices. In the developer’s own words:

You’re alone in a room with a bomb. Your friends, the “Experts”, have the manual needed to defuse it. But there’s a catch: the Experts can’t see the bomb, so everyone will need to talk it out – fast!

Put your puzzle-solving and communication skills to the test as you and your friends race to defuse bombs while attempting to communicate quickly before time runs out! Whether it’s defusing a bomb or deciphering information from the manual, everyone has a crucial role to play.

In the game, one person is tasked with defusing a bomb, with the help of the bomb experts, who are the remnants of the group. The defuser can see the bomb (on the screen), while the experts can read the bomb defusal manual. The key point here is that the defuser cannot see the manual and the experts cannot see the bomb on the screen. Add to this is the complexity of the bombs: each bomb consists of different modules with a unique technique being used to solve it. The final challenge is that the defuser has a set amount of minutes and failed attempts allowed for each bomb. Thus, the defuser and experts and have to communicate well to successfully defuse each bomb within the time limit.

Why is Keep Talking good for teaching teamwork and communication?

The game is expertly developed in such a way that players are forced to adapt their playing style (and thus communication) in order to progress through the game. The key idea here is that the players learn these things organically, they emerge from the group itself, not from the lecturer telling them that they have to do something. Some groups might need more nudging than others from the seminar leader, but even then, they would immediately see the benefit of the change in communication.

An example: On the subject of keypads

The point of this module is to press the keys in the right order. The defuser has to read out the symbols, and the experts will identify which order the symbols have to be pressed. The symbols are diverse, and no one team I’ve seen has given them the same name. Engineering students tend to know all the Greek letters, while social science students are more creative in their descriptions, so the same symbol can be known as the psi or as the fork.

A page from the manual

The first time the team solves this module, it takes a while to get through it. But quickly a rapport emerges. All the symbols are unconsciously given good names. A bad name causes a strike, and too many strikes cause the bomb to explode. This causes the good names to emerge quickly and the stick. This module can take ten seconds to solve in later stages, while it’ll take the whole bomb timer the first times around.

This illustrates that there’s no right way to solve any module. There are certainly more or less optimal strategies, but I’ll wager no team plays exactly the same.

My experience with running the seminar

I was teaching a class in work and organisational psychology for bachelor students at the University of Stavanger in Norway. The class size was about 40, and 9 students remained for the seminar, which I held after a lecture. Thus, we had two bomb groups. The seminar lasted 1 hour and 45 minutes from start to end. It took a little bit to get into the game, but pretty soon after the first bomb was defused, the energy and spirit got high. The students had a lot of fun, and I enjoyed watching them figure things out and cheer loudly as the conquered a new bomb. I had to step in to get the teams to stop playing at the end of the session, otherwise I think they could have gone on for quite some more time.

We spent a bit of time at the end of the seminar to debrief, talking about how the flow of communication went, what changes happened during the game and so on. As it happened, this session was the last teaching period of the week, so it was a great way to end the week.

The students were able to point out several changes and efficiencies that happened during the game, and they discussed the consequences of this. For instance, at one point the identity of the bomb defuser changed. This initially caused worse performance, but they reported that long term it was good because the former defuser had more insight into what the modules looked like, and this was helpful in their new role as an expert.

Extensions, variations and considerations

Playtime

One of the major considerations is the playtime. We had a two-hour session (which means two times forty-five minutes, in academia). I ignored the middle break period, which gave us 1 hour and 45 minutes from the start to the end. I honestly think they seminar ought to take longer. Ideally somewhere between four and five hours. It takes a while to get into the game, and we had only barely gotten started when we had to end. I believe this is the major hurdle with the seminar because it’s hard to get university employees and students to commit to the time demand. One solution is to order free pizza in the middle. Pizza is a great student motivator.

Instructions

I deliberately gave a minimal of instructions before we started. There were two reasons for this:

  1. The game explains itself pretty well when you start it up the first time
  2. Learning the game as a group is part of the teamwork.

But I might want to give more information the next time. What happened at the start was that the defuser was so keen to get started that they didn’t read the introductions in the beginning and was struggling to defuse the tutorial bomb even with the instructions on the screen in front of them. It was a pretty tense situation as I had deliberately made it a competition between the two teams, so this is understandable in hindsight. The experts also spent a long time reading and understanding how each module worked. In addition to the tech issues this meant that we didn’t really start playing properly until after 30-45 minutes.

Tech issues

Unfortunately, it’s a bit of a hassle to set up the game. Firstly, there’s no easy way to purchase multiple licences. I ended up buying them from Humble Store, but I could only buy two licences with the same payment option (for anti-scamming purposes, I believe). Luckily, I had several payment options, but this meant it all took longer to do. I now had each licence in the form of gift. I gave one student in each group a link to this gift. They then had to register at the humble store. Then they had to register for Steam to get the game connected to their steam account. This was a lot of steps that took time. The first group made it quickly. I think they either had a steam account form before, or the steam step was unnecessary for a Mac. The other group ran into issues. After redeeming the gift and realising they needed Steam to install it on their PC, another member with an existing steam account tried to redeem it instead. That didn’t work, and now the original owner couldn’t get into the Steam account either. It was probably possible to fix it, but by now we were already 15 minutes in and they hadn’t been able to get the game installed even. So I ended up lending them my own computer to use.

In the middle of the session, the Mac group ran out of power. And they didn’t have a charger. Even though 8 out of 9 students use a Mac, they all had different chargers (Thanks, Apple!), and the group seemed doomed. Starting on a new computer would mean resetting the progress. Luckily, the other group’s defuser snapped out of their flow state for a moment to realise that they had the correct charger, saving the day.

Giving hints

As stated above, on of the main points of the seminar was that knowledge and changes would emerge organically from the group, not from me telling them what to do. However, the time constraints (we had 1 hour and 45 minutes, and only really 1 hour and 30 minutes to play) lessened the opportunities for this. To compensate, to make sure the students noticed changes in themselves, I occasionally gave some hints. I did this when they seemed stuck, meaning when they had been exploding to the same bomb for a while. The hints I gave went like this.

On the subject of mazes: This is an early game stopper for many. It is very hard for the defuser to communicate the position of all the points on the board, and then for the experts to communicate how they move. In my own first playthrough, we discovered a super-streamlined way to do it: treat the board as a coordinate system, with 1,1 being the bottom left. Then the upper right becomes 6,6. Then “circles at 1,5 and 6,4, white at 1,2 and red at 4,4” replaced the much more time-consuming “There is circle at third position down from the top, all the way to the right. The other other one is at second to last from the left, then at the fourth from the bottom.” Etc.

I gave the hint to consider something like a coordinate system. The groups quickly picked up on it. Interestingly, they used a combination of rows, columns and positions in their speech that I was unable to decipher. But they aced the mazes from there on out, which shows that the important thing is that it works within the group.

Timer: After some bombs, the timer changes from 5 minutes down to just 3 minutes. This is the point in the game when you are supposed to realise that you need to organise the work efficiently. Up until this point both groups (which had three or four experts each), would sit together with all the pages of the manual in front of them. They would handle one module at a time, together. It worked so far, but with just three minutes they were doomed to fail. After some time, I suggested they split up the work by having groups of people taking care of separate modules.

This was implemented, but not really to any effect. Now the one sub-group would just watch as the second group solved one module, then the roles would switch as the second group watched the first group. The idea is that the defuser gives some information to the one sub-group, like the serial number of the bomb, the number of wires and the colour of the wires. This allows the sub-group to work on this for a little while and work out which wires to cut while the defuser works with the other sub-group on another module. This is key to progress in the game and will be a naturally learnt fact after playing for long enough. We did not play long enough for that to emerge, and perhaps I even hindered it more by coming form the outside and suggesting they split up the tasks like I did.

On the subjects of Morse code: This module is the most difficult of them all. I never really found a perfect way to solve it when I played either. When this module showed up, the team would lose, consistently. They only progressed when they were lucky and got another set of modules. The key to solve this module, I believe, is for the defuser to try to sound out the Morse signals to one of the experts, and for that expert to spend the entire timer trying to figure out what the frequency is. It takes a while to get to this stage, and we didn’t have nearly enough time. I wish I could have removed the Morse code module form the bombs, because at that level it was just frustrating to always lose to it. Consider using a mod that removes it, or using a cheat sheet found online to reframe the module. I believe this module is deceptive, in that many players spend a long time trying to make sure they have perfectly captured the code. The experts only need a few pieces of information to decipher the frequency. But this takes a while to internalise.

Debrief: Our debrief was five minutes at the end of the session where I wanted the group to discuss the experience. As a group, they filled out answers to a series of questions I had prepared beforehand in a Google document. Since we were at the end of the session, the groups could either do it now or later in their own time. Thus, only one group remained to fill it out. We talked a bit while they filled out the form. It would have been much better, especially with only two groups, to hold the discussion orally with everyone. We did it in writing because we hoped to use this in a later seminar, and because I suspected we would be spending most of the time on the game. With more time, I’d recommend an oral discussion at the end instead of written.

My set-up

I have already touched upon in, but here is a summary and a plan for how to carry out this seminar (or adapt it as you see fit.)

It should be noted that the developers of Keep Talking specifically state on their webpage that you can use the software in an education setting. Great!

Preparation (before class)

  • Get enough licences: one for each group. So it is good to have an idea of how many people will attend. Each group ought to be at least four people, which a minimum of three experts.
  • Prepare the students: Time changes and as I get older, I find I take certain ancient customs for granted. For instance, that all students keep pen and paper in their backpacks (why would they, in this age?) Pen and paper are critical for the game, so make sure to ask them to bring some.

Set-up (in class)

  • Explain the point of the game
  • Explain how the should form groups. I let them do this on their own, because they already more or less sat in two groups. You could also make your own groups if you want. I think it is more motivating if you can sit with your friends.
  • Make sure the groups sit somewhat apart from each other. It will get noisy as the experts and defusers start shouting when the ticking gets critical. Ideally you want a flat classroom with rearrangeable chairs and tables. With only two groups I was able to use a normal slanted-floor lecture hall with rows of seating, by placing the groups at opposite ends of the room.
  • Make sure the defuser and experts cannot see each other. With the game on a computer, I had the defuser sit facing the experts. Imagine the possibilities if you have access to VR headsets! (But this will require more prep-time before the game can be played.)
  • Install the game. If possible, do this before the seminar, as it is a hassle. If you can know the participants before-hand, you can delegate a computer to install it on. Participation in our seminars was quite volatile, so I had no idea how many would show up and who. Thus, I had to do it at the start of the seminar.

Hover

  • Hover around and watch the teamwork at play! This is the best part. It is super fun to see students engaged in something funny and high tempo.
  • You also have to make sure they follow the rules. It’s natural for the experts to attempt to show the manual to the defuser, so you have to be wary of this in the beginning.
  • If you’re like me, you’ll struggle to not offer too many helpful hints. Remember that they have to fail a lot in the beginning to learn the game. I only gave hints twice, when they were really stuck. Even then I maybe shouldn’t have, especially not if we had longer time to play.
  • You can increase the fun by keeping score of how long each group has progressed. Make sure that you see in the bomb overview which bombs they had cleared. It’s possible for teams to pass some bombs and move on to the next, so you can’t blindly trust that they have cleared all bombs before the ones that they are on at the moment.

End

  • Let them know when they are on the last bomb, so that they have to stop after this. You need some time to debrief.
  • Discuss what happened.
    • How was the communication between team members?
    • Did it change?
    • Did someone take on a role, like team leader?
    • Did you make up certain terms or code language between yourself spontaneously?
    • Did you switch roles?
    • Mention some barriers to communication, and how you solved it. (Unequal technical experience, different language)
    • What would you recommend for another group that is playing Keep Talking for the first time?

Most importantly, and least helpfully: have fun! Change things around if it makes it easier or more enjoyable for your students or yourself.