There’s this moment in the Titanfall 2 tutorial called the “gauntlet.” It’s a straightforward FPS tutorial that’s teaching you to crouch, shoot, jump, and so on. It ends with a timed section where you put the skills together. When you finish, you see a high score board with fake times from other pilots, like at the end of a game in an arcade machine.

For most people the feeling at this moment is “wait, what?” Your first run is probably a minute or more, and you’re saying it’s possible to do in 25 seconds? And then there’s this:

I find moments like this to be really magical. My primary design interest is in non-combat games, especially those that focus on interesting movement dynamics. My main design goal this year was to create a movement system that didn’t have explicit moves but it had depth and expressiveness in it that reveals moves over time. A game where players are unlikely to win their first run, but get a feeling like “there’s more to this” or “I could get good at this with a few more tries.”

So I took a swing at that with GRIDLOCK this year. I think I missed, but in a sort of weird way. Let’s talk about it.

First, what do I even mean about expressiveness of movement? Here’s a video of a run where I’m rarely crashing and maintaining pretty high speed throughout.

You’ll see in this:

1. Tight 180 degree turns
2. Careful drifting to align with traffic lanes
3. Adapting angle of attack on Boomers to avoid crashing into their explosions (not always…)
4. Tight 90 degree turns into smaller alleyways.
5. High turbo usage, including in turns.
6. Breaking locks to regain health.
7. Low crash rates overall.

I think there are four root causes:

1. It sucks to feel like a bad driver, and that’s the start of every player’s journey.
2. I use unpredictability in the game in ways that are surprising to roguelike players in particular.
3. The “feel” is off on the core motion.
4. Game jams in particular are tough contexts in which to violate a lot of player expectations; what feels challenging and interesting to explore in one context might feel like a broken game not worth playing in a game jam context.
5. I didn’t lay clear enough breadcrumbs about what is possible in the game.

Starting with a crash

Watching players run the tutorial, the dominant feeling is one of being out of control. Few new players complete their laps around the course without crashing repeatedly and feeling surprised and dismayed.

My hope is that crashes inspire curiosity. Is it possible not to crash? How would you do it? And from there, a sense of challenge. Just how fast can I go and still not crash?

But there’s something missing to draw people through this experience. Looking back at the Titanfall 2 Gauntlet, there’s an important difference. “Failure” in that case is getting a time at the bottom of the leaderboard. It’s not necessary to develop the movement skills of a speedrunner. Most players never do, and play the game on a difficulty that supports moving like you’re playing Call of Duty, not Titanfall 2. Those players go “huh, I guess you can do it faster than I did” and move on.

In GRIDLOCK, if you don’t build these skills the game is barely playable. You will move from crash to crash and even if you manage to get a win, it doesn’t feel very good.

So lesson one:

Make mechanical skill development more optional, with a satisfying-enough experience available without it.

I’m not sure how to reconcile that goal with my interest in making an expressive movement system at its core, while still being fundamentally optional. Perhaps the synthesis is you need something flashy that is very straightforward and easy to do, and ALSO something you can build on. Grappling hooks are a version of this – point and click to go somewhere inaccessible feels pretty good. If you can also develop Spider Man-like movement on top of that, amazing.

Output Randomness

There’s an often-discussed concept of input versus output randomness. Essentially, is the player presented with situations that have randomness in their creation (input randomness) or are the actions the player takes going to have an uncertain effect in the world?

Traditional roguelikes tend to score quite high on input randomness via procedural generation. Output randomness is more carefully applied. There is certainly combat outcome randomness; 2d6+5 damage. Cursed items are a form of output randomness. But when there is output randomness, it tends to be pretty explicit. You are taking an specific action (quaffing a potion, reading a scroll, swinging a sword) that is known to have random (and often easily enumerated) outcomes.

A real-time game like GRIDLOCK is a whole other matter. A player might be able to articulate “I want to move from here to there without crashing.” But the controls are not straightforward. The series of inputs to create that outcome is not something you have time or even the capability to reason through. There is, of course, concrete logic at the core of the game that sets the rules for movement. But I don’t think a player could even outline them in pseudo-code.

This is, I think, uniquely frustrating to a roguelike audience. It’s a form of output randomness that is pretty unusual and unexpected and does not offer a way to “solve it.” It’s ultimately a matter of “feel” more than “understand.”

Game Feel

Of all the ways I think GRIDLOCK over-stepped what I was capable of in 7 days, nailing game feel is the most important. If you’re going to have a real-time game that delivers the feeling of dynamic movement it really has to feel good. And GRIDLOCK just doesn’t feel great.

Game feel isn’t one big thing that’s wrong, it’s the whole ensemble. Among the bits that just feel off:

1. Camera movement is slightly off, especially when turning.
2. Collision. Movement is fundamentally discrete under the hood, so there are sometimes confusing visuals where you crash when you think you shouldn’t, or can move into a space that looks unoccupied.
3. Movement animation is not right. Too smooth and you amplify the collision issues and make it confusing where the input buffering boundaries are. Too jerky and it feels awkward.
4. Speed is communicated oddly, especially as it relates to turning. Your “momentum” direction changes at low speeds only, otherwise you drift. But the “tick rate” of your movement is coarser than that internal speed. This disconnect is probably wrong.
5. How your inputs translate to action confuse some players. Should you press and hold arrows? Tap them? What will happen in each case?

I’ve poked and prodded at all these issues throughout development. The way it shipped is … fine. But I think in a real-time game, fine is just not acceptable.

Plan for 2-5x more time when tuning real-time gameplay than turn-based.

As it is, the friction to develop mastery is too high, and the feeling of attaining mastery is not quite cool enough to justify getting there.

Audience & Context

There are plenty of games that violate these insights and make the new player feel powerless and ineffectual. I’ve been playing a lot of UFO50, and one of my most memorable moments is booting up Mooncat – a platformer with controls so unintuitive that I laughed out loud when I realized how they worked. Or with any Souls-like game; filled with under-explained stats, chunky movement, and regularly faced with obstacles you should not even attempt until later in the game.

What sets these experiences apart is the context of play. UFO50 creates a context for play where you expect to have to figure out the game as you play. And if you don’t, fine – there are 49 other games that might click for you. Souls-like games grew on word of mouth, and most of us entered them for the first time with a strong recommendation from a friend. Maybe having watched videos, maybe even with that friend over your shoulder helping you get going.

So while I was inspired by those kinds of experiences, and sought to channel some of that energy into GRIDLOCK, it was nonetheless a very awkward choice for a game jam. Players do not show up primed for the experience I’m offering. It violates their expectations immediately, on many dimensions. It makes them work hard to find the fun. That’s just not what people look for in a jam game with a relatively narrow theme.

Last year, my game was more or less unplayable by non-roguelike players. I failed to get really anyone in my life to play it successfully. But it was well received by many game jam players.

This year, my game was enjoyed primarily by non game jam players. People in my life who bounced off runner, or who don’t even play games much at all. Even my 8yo kid – who found turn-based runner to be too much for him – latched onto GRIDLOCK way more.

I knew, of course, that violating some core roguelike expectations like real-time, no equipment, no combat, limited resource management, and so on is a risk in a roguelike game jam. But then I doubled down on that violation by creating a “spiky” version of a barely-roguelike game that required you to push through some barriers to find the fun. That’s just not a good expectation for this audience.

Recognize the context your players bring to the game; violate at most a few of their expectations at a time.

This relaxes if you develop a reputation, or a distinct audience for your tastes as a game maker. That’s the souls-like and UFO50 lesson. If people trust you, it’s possible to parley they into much more challenging experiences. But I didn’t often have that trust with players and so it was easier to go “huh, this is not working for me…” and bounce.

Show what’s possible

It’s a true-ism that most players won’t choose to do a tutorial, and will simply load into the game and “work it out.” That’s especially problematic for the sorts of games I’m interested in, because I am always interested in doing something players haven’t quite seen before. Maybe I can manage to do it in a way that is an obvious extension of similar games, and it reveals itself purely through play. But I’ve done full-on tutorials in both my #7drl games and mostly players seem to appreciate it.

My error this time was, I think, that the tutorial did not demonstrate or even really reveal the depth of what is possible. My motivating experience with Titanfall 2’s tutorial is illustrative – FPS players expect to play through a basic tutorial. It may even be un-skippable, I don’t recall. In that tutorial, you are introduced (albeit obliquely) with clues that something “more” is possible.

But a player of GRIDLOCK’s tutorial gets no hints of that. And many players seem to load into the main game and experience their failures not as a stimulus for figuring out the inputs and gameplay. Rather, it comes across as more like an error in design. “I can’t move anywhere without crashing” versus “Hmm, what’s the secret to not crashing? I know it’s possible.”

I even built out my version of Titanfall’s speedrunning experience – a little race course that tracks (and saves!) your best lap times.

However, it’s not tied into the tutorial or the game itself. I haven’t heard from anyone who sought it out or learned anything useful in Practice mode. Even here, I’m not quite delivering on the Titanfall lesson. I needed to complete the analogy. Force players through it at least once, show them (with a ghost, or leaderboard) what GREAT looks like, and hopefully pick up a few more people willing to push through the awkward feel and find some mastery on the other side.

Leave nothing central to the game to imagination; if neither the tutorial nor the game leaves breadcrumbs to inspire players to explore, they are unlikely to explore just in case there’s something fun to find.

This is most acute in a game jam situation with hundreds of games waiting to be played. But I think it’s broadly important to create moments that suggest where mechanical complexity is available.

Conclusions

On the whole, I’m proud of the game. It didn’t deliver the experience I’d hoped for, but I did achieve a lot of my macro objectives:

1. Create a movement system with potential for mastery without explicit moves.
2. Expand my visual vocabulary significantly; make something that feels more like a “world” than a “level.”
3. Start a “personal game engine” that I can expand and reuse. There’s maybe one functional import in this whole game (FOV calculation) and everything else I wrote from scratch. It’s got issues, but it’s probably something I will continue to refine and iterate on for future events.

This was a very ambitious set of goals, and to not quite land all of them in 7 days is okay. Onward to the next jam!