Rogue-Like Games
- Justin Matheson
- Mar 30
- 4 min read
You are going to fail.
A lot.
When you fail (not if you fail), it is important to learn from those mistakes and to fail forward (cheesy teacher line).
Roguelike games take this concept and force it upon their players.
And the point is not to avoid failure. The point is to get good at learning from it.
That is why roguelikes have become one of the my favourite training tools, especially for anyone trying to build adaptability, resilience, and decision-making under uncertainty.
What a roguelike is
At a high level, roguelikes are games built around repeated runs where:
The world is partially randomized.
Failure is expected and you gain small improvements incrementally.
Progress comes from what you learn, and what you unlock as you progress.
Some people say “roguelike” and “rogue-lite” are two different things, which may be true from a technical standpoint, but the essence of these types of games is their cyclical nature.
Either way, the core experience is the same.
You start again.
But you do not start over (#inspo).
The roguelike loop is a learning design loop
You enter with imperfect information.
You make choices.
You get feedback quickly.
You fail.
You return and start over.
That looks suspiciously like how humans actually develop skill. By trying, missing, adjusting, and trying again.
Each run gives you slightly different constraints, then asks, “What are you going to do this time?”
Why roguelikes are so popular
People like to explain roguelike appeal by describing it as a Dopamine hit.
That is not wrong, but it is incomplete.
Roguelikes combine three things that players love and that make them great learning tools.
1. Fast feedback
2. Meaningful constraint
3. Clean consequences
With these types of games, you don't have to wait to figure out if what you're attempting worked. You don't have to submit anything and wait for feedback. The game gives you feedback immediately.
When it comes to constraints per level or per round, there's no way that you can switch your strategies in most of these games. You have to commit to one, push through it, and if it doesn't work out you might realize immediately, but you don't get to start over and try a new strategy until you've completed your run.
Finally when you lose, you know exactly why you lost. It's not anybody's fault but your own. There is no question of whether the game is fair or not because the mechanics are solid and the system is legible.
Work often fails here. Real workplaces have fuzzy feedback, politics, and delayed consequences.
Roguelikes strip that away and give you something you can actually learn from.
The skill roguelikes train
When people say roguelikes “train resilience,” they often mean “they make you tough.”
The better framing is that roguelikes train adaptive resilience.
They train your ability to:
Reset quickly after a setback.
Extract a lesson without spiralling into blame.
Try a new approach without needing perfect certainty.
Make trade-offs with incomplete information.
That is not just emotional grit, but an operational skill as well.
The thing roguelikes get right
Most training treats failure like a thing to avoid, but roguelikes treat failure like a form of data.
That is a very important shift.
In a good roguelike, failure is not personal, it is information.
“That build cannot survive this boss.”
“I over-invested in damage and ignored mobility.”
“I played too safe, and starved the run.”
Compare that to workplace learning.
“That presentation bombed, I am just bad at this.”
“That project slipped, this team cannot execute.”
Same outcome.
Totally different trajectory.
What roguelikes suggest for L&D
You do not need to run Hades in your next leadership program (unless you want to which would be a great idea).
But you can steal the design principles.
1. Design for multiple runs, not one big event
General insight: Skills rarely change after a single exposure.
L&D application: Run smaller cycles that repeat, with slight variation. Debrief, anyone?
Implementation detail: Micro-simulations, repeated case drills, short roleplays with shifting constraints.
Success indicator: People can name what they changed between runs.
2. Make the feedback legible
General insight: People improve faster when they can see the consequence of a decision.
L&D application: Stop hiding the scoreboard.
Implementation detail: Use observable outcomes, quick debriefs, and “here is what that choice caused” moments.
Success indicator: Teams shift from debating opinions to quickly testing hypotheses.
3. Treat failure as a normal part of practice
General insight: Low-stakes failure is what makes high-stakes performance possible.
L&D application: Create practice spaces where a miss is expected, analyzed, and another attempt is made.
Implementation detail: Short rounds, explicit reflection prompts, no shame language. This is particularly important for group dynamics. If someone stands behind their idea and it bombs, give them praise for sticking up for their idea and even more praise for thinking about where it went wrong and how it can be better next time. One idea failed spectacularly? Laugh it off and reset because you can do that in this situation and not always in the real world.
Success indicator: People take more intelligent risks over time, not fewer.
A roguelike lens for organizational change
This is the part that hits home for me.
Most organizations want “innovation,” but they do not want the repeated runs.
They want the successful run.
They want the highlight reel.
Roguelikes remind you that the highlight reel is paid for with dozens of ugly attempts.
If your culture punishes ugly attempts, you are not building innovation.
You are building performance theatre.
Bottom line
Roguelikes are not a productivity hack, they are a philosophy.
You get better by running the loop.
Try.
Fail.
Learn.
Run it again.
If more workplace learning looked like that, we would spend less time pretending we changed, and more time actually changing.
Also, I take back what I said before, you should definitely play Hades next time. The world would be a better place if that happened.
Comments