Lessons learned from watching playtests

It’s been a week since #7drl 2024 wrapped up, and it’s been such a pleasure to watch folks playing and reacting to runner. I’ve learned so much from watching these reactions and I want to share what I’ve learned about what works in the design and what doesn’t. My intent with this is to offer relatively high level insights that might apply to other game design contexts and thorny questions.

If you haven’t played runner yet, start with that! I’m going to assume you have at least a general sense of how the game works. You might also enjoy my developer commentary playthrough, which offers a game overview.

Tutorials

A playable tutorial was on my wish-list from the start of #7drl planning, because I knew I was violating a bunch of roguelike conventions in the design. I worried people would not stick with it long enough if basic ideas like “you can’t bump into enemies to kill them” simply didn’t work. I’m glad I spent the time on it it, but I tended to over-estimate how much I could simply show players something once and have them understand it. Probably every tutorial author has this feeling to some degree and you have to set your expectations on the low end of how much you can really teach someone in a tutorial. Here’s what hit and what didn’t.

What works:

1. They learn special moves and how to use them. I haven’t seen anyone in the main game not using the moves. (Burrow, especially, is memorable to people.) The game is impossible if you don’t learn this, so I’m glad it works!
2. Doors. People learn to open them! Although the “wait to operate adjacent objects” idea is fundamentally not comfortable to most players, and their instinct is much more to “bump” them than use the “wait” command.
3. Theme. The tutorial provides some space to do a little bit of tone setting in the writing.
4. Hunter. Its introduction is scary and surprising and it’s good that players see it before it’s “real.” Everyone exits the tutorial knowing to be afraid of the hunter and knows it will follow them.

What missed:

1. The exact constraints on using special moves don’t really hit. Players tend to have some intuition based on the names and the circumstances the move seemed to work for them in the past. But it is quite common in play that players will say “wait, I thought I’d be able to use that here.” This is probably not something I can solve purely in the tutorial; there needs to be some more UI here to communicate why a move is not available, and what the precise constraints on using a move are.
2. Diagonal movement. You don’t need to use it in the tutorial, and a lot of players miss that this is possible. In runner, diagonal movement is crucial because the Hunter can move diagonally. If you don’t, you will fall behind rapidly. I thought it was enough to say “8-way movement” but it is definitely not.
3. Buttons. I put the button lesson after the Hunter introduction because I wanted to simulate a little mini level. Hunter behind you, buttons in front of you, hit them and run to the exit. But the Hunter is so charismatic and stressful that I find players quickly mash buttons to get away from it and do not have the attention available to read about pressing buttons. Lesson learned – don’t expect a stressed player to learn a new concept!

Vision + Damage

The logic of taking damage in runner is “if you end your turn in a space that is within enemy vision, the nearest enemy that has vision on you will shoot you for 1 damage.” The implication of this is that standing within enemy vision is not a problem, you just can’t move INTO enemy vision.

This does not generally make sense to players. This distinction doesn’t always matter; if what you learn as a player is “stay out of the red zone” that will certainly keep you from taking damage. But when players end up in situations where enemies move and that movement turns the players’ tile red after they moved, I observed a lot of dissonance. Players ask questions like “Am I guaranteed to take damage now?” or “Did I already take damage from that?” This undermines their mental models of how the game actually works.

It’s a tricky problem to solve. I have a hunch that slowing down the turn processing speed might help. Tactical games often have phases like “enemy movement” and “player movement” that are distinct. In practice what is happening is: (1) player move, (2) enemy shoot, (3) enemy move. But because all phases happen essentially instantly in “real” time there is no conceptual separation for players about what is happening when. So the fact that enemies shoot first, and move second is not something they can parse.

Speed of play

Roguelikes have an odd rhythm to play. Imagine a chart of “turns played per minute” over time in a playthrough. In my own play, I know that it varies wildly. Sometimes I’m zooming around a floor in Jupiter Hell at max speed, looking for the last enemy I need to kill. Other times I am thinking deeply about whether to reload my gun or switch to my secondary and which target to prioritize and I might take 30 seconds or more on a single move.

Typically, speed relates to the number of enemies on screen. You go slowly in combat, and you go fast in exploration. In runner you are in a sense always in combat with the Hunter. But for the first 20 turns, you don’t see the Hunter. Players tend to “mess around” in this window. Rarely using movement abilities and not necessarily moving towards objectives. On the one hand, this may be a fine learning moment. Skillful play need not be obvious. But it makes me also think there is some misunderstanding about the Hunter’s design. In the prologue level, the Hunter is triggered by you picking up the amulet. But in the rest of the game it simply waits 20 turns and then emerges. I wonder if I’m pulling a bait and switch that feels bad, rather than feels like a developing mastery.

Some sort of UI indicator that communicates how many turns away the Hunter is might work. This could double as a range indicator for the Hunter after it enters the level.

I’ve observed another odd dynamic on speed of play. People sometimes seem to have an urge to make moves quickly when the Hunter is chasing them. They understand rationally that this is a turn-based game, and entering their moves faster doesn’t help (and in fact on balance probably hurts). But the Hunter creates a sort of ominous feeling that players seek to run away from quickly. In one play through, when the player finally won, they breathed an audible sigh of relief.

My interpretation of this is that the Hunter creates not just a game challenge, but a feeling of tension and pressure in clock time as well. Players are moving quickly because it could bring catharsis faster in clock time if they complete the level faster.

This is admittedly a bit of an odd idea. I’m not sure it’s what’s going on. It may also be that some players are less patient, and would rather move quickly through a play through and then reset. The game certainly is responsive enough for that to feel like a valid way to play. But it’s making me think about how you might want to organize different kinds of experiences in a larger version of runner. Would, say, 10 levels that are all running from a Hunter be fun? Or would it just exhaust a player’s “flight” response? I lean towards thinking that this is a powerful mode of play, but a game that was purely this level of adrenaline might be too much. Or perhaps the player needs some agency around starting and ending this mode. For example the player might start a chase sequence when they steal some item, and the Hunter only has battery power to chase you for 2 levels, at which point the alarm turns off and you’re in “sneak” mode.

Diagonal Movement

This is somewhat of a religious question, I know. I really like 8-way movement myself. It feels natural to me; if I’m in a square park, the fastest way from one corner to the opposite corner is a diagonal path, not walking parallel to the edges. But it was such a persistent issue in playtests that I have to do something major about it.

The problems that emerge:

1. The Hunter uses diagonal movement efficiently, so if you do not it will constantly be catching up to you around corners in a way that is disorienting to players.
2. Passability. Some players will look at a wall with a diagonal passageway through it instinctively impassable.
3. Tension between the special moves (which only operate on the cardinal directions) and basic movement (which offers diagonals); why is it different?

Setting aside my own personal preferences, I do think 8-way movement feels running-like to me. In my mind, it’s like you’re running forward and then you plant your foot and shoot off sideways, changing your direction smoothly. That’s what I imagine is happening when I switch to a diagonal move. Or I’m squeezing through a tight gap in a wall. It opens up more efficient basic movement, which is an opportunity for skill development. But simultaneously it is an opportunity for growth that seems to be invisible to many players. Especially the non-roguelike players I’ve observed. It is so uncommon to have 8-way movement in other games that it simply will not enter their mind. Their fingers are programmed to use WASD and to add QEZC is crazy.

I’m curious for feedback here from other designers. My instinct at this moment is to cut diagonal movement. Although I like the feel, I think the overall design works totally fine with only cardinal movement. It simplifies inputs, reduces confusion, saves some tricky thinking about how diagonal special moves would work. Overall I think it would make the game more accessible to more players with more diverse input options available (e.g. no numpad) and that is probably better.

Conclusion

Looking back on the “how to address what’s not working” it’s apparent that the UI and visual design of the game is so crucial. I’m also never thinking “something is wrong in the rules of the game.” Instead I am thinking “I need the player to be aware of something they are not aware of yet.” If I decide to work on some of these bigger and deeper issues, I need to prioritize a lot of UI iteration and testing to see what is comprehensible to players. There’s a kernel of fun in here for sure, but there are also lots of moments that can undermine a player’s mental model about what’s going on, what’s possible, and how the game actually works.

Further reading:

1. During the game jam I wrote nightly progress updates. This includes my Day 3 crisis of confidence, which spawned the Hunter! Would you believe the Hunter wasn’t in my original design doc?
2. Map generation approaches and lessons.