Currently working on game onboarding, and wrote about the design philosophy behind how I'm approaching it in Kegs of Eternity - it's more of a gamedev article then a gamer article, but posting the full thing here for anyone who wants to peek behind the curtain.

We've all played that game. The one where you're stuck in a tutorial mission for forty-five minutes that should have been three. A wise mentor character whose first three lines of dialog are 'Press W to walk' / 'Press W to walk' / 'Now press W to walk.' Pulsing arrows you have to click in a specific order because the tutorial won't let you do anything else. Walls of text. Forced clicks that blur out the entire screen. By the time you actually reach gameplay, you've been treated like an idiot for so long you're not sure you trust this game with your time.

Most onboarding sequences are bad. Some are good. I'm going to walk through a design philosophy for the good ones, using the onboarding I'm currently building for Kegs of Eternity as a worked example.

I'm not claiming to invent anything. I'm saying most games don't do this right, some do, and here's how to do it so we can all make better games.

The principle:

The best onboarding lets players feel like they figured it out themselves.

Quick note on the word "onboarding": I'm calling it that, not "tutorial." That's a deliberate choice. Tutorial missions are usually a separate thing the player has to get through before the real game starts - ignored as soon as possible, with no real connection to the campaign that follows. Onboarding is the first hour of your game, integrated into both the gameplay AND the story, where the player learns what the game is by playing it.

That mental shift - from "tutorial" to "onboarding" - changes how you build it.

I learned this approach working on Batman: Arkham Shadow at Camouflaj. Ryan Darcey called it "Show, not tell", which is usually a narrative technique, not a game-design technique, but it's perfect for this.

VR onboarding HAS to nail visual-only teaching: controllers map to too many varied actions for text prompts to scale, and players wearing a headset find walls of text genuinely uncomfortable to read. So Camouflaj couldn't fall back on the usual onboarding crutches even if we wanted to.

By the way, if you have a Meta VR headset and haven't played Arkham Shadow yet - go play it, it's good shit.

Yes, it's a fart joke. It's also a deliberate onboarding choice. Starting the player naked in a cell strips them of all gameplay systems - no inventory UI, no skill bar, no minimap, no map controls - and lets us introduce each system naturally, one by one.

After the player picks up their starting shield and axe when leaving the cell, I animate the equipment and stats panel in from the side.

Animation works better than fading or instant-toggling for revealing UI. Human eyesight is drawn to movement, so animating UI in is more noticeable than fading or toggling. We're literally just exploiting evolution here. Mostly matters for smaller UIs that live in a corner of the screen. (For something this big, the player can't miss it regardless, but the principle scales.)

It's a significant amount of stuff to take in. But I trust the player to either hover over things to figure them out, or - if they don't - to skim and move on. Your players aren't five year olds (probably). They'll still take away the right high-level lesson: "Equipment affects my stats, seems important." That's enough. They'll have plenty of opportunities later to figure out what the stats actually do, if that's how they want to learn them. (Curious about those stats? I'll have a separate post detailing what each does later. Follow Lone Piggy on X and Kegs of Eternity on Steam to know when it drops.)

You'll also notice the WASD doodles drawn on the floor (yes, ripped straight from The Binding of Isaac. Edmund, if you're reading, I owe you a beer). The last thing players need is for a tutorial to dialog-box them on how to move around with WASD and run with shift. You're treating them like idiots at that point. Some players will be confused for five or ten seconds, sure, and that's fine. The alternative - a forced "Press W to walk" prompt - treats every player like an idiot to protect against the rare confused one. That's the wrong tradeoff. Don't make your onboarding annoying for the 99% to handhold the 1%.

If a confused player gets stuck and leaves a negative review about your unclear onboarding, so be it. That review will be outweighed by the positive reviews you'll get from players who appreciated being treated like grownups.

Quick playtesting warning, though: yes, playtesting is great for finding genuine trouble spots. But resist the urge to panic when a tester gets stuck on something for thirty seconds.

Players actually enjoy figuring things out for themselves. What's unbearable is watching someone be stuck on something live, especially if it's a recorded test where you both know you're observing. It's like watching your mom try to find the right HDMI input on a smart TV - pure secondhand pain. But that live discomfort is not how players will experience your game. They play alone, in the comfort of their chairs, and they don't mind spending a few minutes hovering over tooltips and figuring things out at their own pace.

Players don't necessarily "hate to read." They can read tooltips just fine. They just hate to read tutorial walls and do forced clicks when they'd rather be exploring the game on their own.

(One genuine exception: if you're making a Demo build for a physical festival, then yes, add handholding on short delays for spots players might get stuck. No one wants to feel stuck for even ten seconds when there's a line of people behind them wanting to play your game. Just remember to turn that crap off later for the online Demo build.)

Further along, the player is given a few coins in a "random" event room and told they need to buy a key from the nearby shop to unlock a shortcut and avoid a fight.

I do NOT then use blurred zones and forced clicks on the shop so players see the key and buy it. They're perfectly capable of figuring that out on their own. So I let them explore the shop at their own pace and work it out. That makes them ACTUALLY understand how the shop works, instead of clicking the non-blurred areas to get the tutorial out of the way.

And yes, I let them mess up. Spend the coins on something else. End up in a situation where they can't take the shortcut and have to enter a fight they aren't prepared to win.

Allow your players to die in your onboarding if they really want to do dumb things (frequently intentionally so just to see what happens). That makes them understand the onboarding isn't a safe sandbox they can mostly ignore. They have to actually engage with the systems to get through. Make it plenty easy and give them room for mistakes - but don't make it failsafe. The risk of failure makes them pay attention to what we're trying to teach them.

It's another reason I call it onboarding instead of a tutorial. A tutorial is something you survive. Onboarding is something you play.

What changes about the design process when "trust the player" is the default?

You stop writing "Press X to do Y" prompts and start asking "what visual cue can replace this prompt?" You stop adding force-blur-and-click flows and start asking "what animation can call attention without locking the screen?". And the mindset propagates - you start trusting players elsewhere too, with more freedom in dungeon exploration, less hand-holding on combat encounters.

Once you start trusting the player in the onboarding, you start trusting them everywhere else. The whole game gets better for it.

Now, before you go screaming at the screen saying your game can't do it: The full-diegetic approach I just wrote about is a high-craft, high-cost end of a spectrum. Not every game can afford it everywhere, and not every system is well suited to it. That's not a failure - it's a tradeoff worth understanding.

There are roughly three points along the onboarding-design spectrum:

What KoE and Arkham Shadow do (yes, I'm putting my tiny game in the same tier as Arkham Shadow - sue me). The world itself teaches the player. UI animates in when relevant, environmental cues guide attention, the fiction carries the lesson. Inscryption is another good cross-genre example - card mechanics introduced one at a time, in-fiction, by the dealer character. The fiction IS the onboarding.

The cost: requires custom onboarding-mission scope, dedicated UI animation work, and willingness to test it with players and tune it. Most indies can't budget for this everywhere.

The middle ground. Genome Guardian II is a great example. While my game starts you on a literal toilet, GG2 takes the more dignified path of just letting you play and showing you stuff when relevant. The pattern: let the player free-play from the start, no upfront tutorial barrage. When a system becomes relevant - the player encounters something they need to do - the forced-prompt-blur kicks in to teach that one thing.

It works because:

1. Timing matches motivation. Forced prompts are tolerable when the player wanted information, intolerable when the player just wanted to play.

2. It reduces onboarding scope dramatically. No custom mission needed. Just-in-time prompts can be bolted onto regular game systems. Affordable for tight indie budgets.

3. Players retain better. Information acquired at the moment of need is encoded with context. Information dumped upfront becomes tutorial slog the player skims and forgets.

4. It's slightly annoying, but not in a way that creates rejection. Players accept "the game showed me a thing I needed" much better than "the game forced me through something I didn't ask for."

This is what UX designers call progressive disclosure - introducing features when they become relevant rather than all upfront. I know, the name sounds like something an HR consultant would say at a Slack offsite. The pattern itself is genuinely useful though.

The catch: the moment of forced-prompt-blur is still slightly annoying, even when timed well. Just-in-time isn't free. It's just much cheaper than full diegetic AND much better than upfront tutorial barrage.

Some games genuinely need text. Deep simulation games (Dwarf Fortress, RimWorld, Factorio). Complex strategy titles (Crusader Kings, EU4, Stellaris). Educational games where text supports the explicit pedagogical goal. Localization-budget-constrained titles where text translates cheaply but visual storytelling doesn't.

KoE doesn't need this. The mechanics CAN be taught visually within reasonable scope. The principle scales to similar games. It doesn't scale to titles where the system count exceeds visual-introduction capacity.

The takeaway: push toward the diegetic end of the spectrum where your scope allows. Fall back to just-in-time / progressive disclosure where full custom onboarding scope isn't affordable. Only use full text reference when system density genuinely exceeds what visual storytelling can carry.

Most games will sit somewhere along the spectrum, and that's fine. The failure mode is forced upfront tutorial barrages, not picking the wrong point on the spectrum.

(Personal honesty note: even KoE will probably need just-in-time fallbacks for deeper systems being added in Early Access. Full diegetic for the opening, progressive disclosure for the more complex systems later, or stuff that would make changing the original onboarding too costly. I live the spectrum too.)

And yes, I'm a guy with one game and zero shipped tutorials writing 2,000 words on how to do them. I'm aware. The alternative is being too humble to write the article at all, and the article is good enough that being too humble would be worse. Roast me anyway.

Onboarding people don't hate is doable. Most of the work is in the mental shift from "tutorial" to "onboarding": treating the first hour of your game as part of the actual game, not something to survive before the actual game starts. After that shift, the design moves follow naturally - environmental cues over prompts, animation over instant-toggle, trust over hand-holding, willingness to let players fail.

I'm not trying to invent anything new. I'm just applying patterns we already know work to a part of games we usually phone in.

What other games get onboarding right that I didn't cover here? Where do you disagree with my "when this doesn't work" framing? Tell me on X / Steam / wherever you found this. Onboarding design discussions in indie circles are weirdly thin, and I'd love more pushback and more examples to learn from.

— Petrucio, Swine Overlord at Lone Piggy