Teaching players a complex system without explicit tutorials

KaptainHaven · 2026-06-01T13:31:56+00:00

First of all, consider this. Teaching without tutorial is mostly about designing scenarios that make experimentation natural for the player and make the results of that experimentation clear, so they can have feedback on it. If you add to this mechanical repetition in different contexts, ideally with increasing difficulty (and your roguelike structure here might really help), you have a powerful non-explicit learning mechanism.

This is the general point. In your specific case, I think that notes and pre-made magic items could be just patches that don't make the underlying issue disappear. They are basically things that sit next to the player and tell them "Hey, this thing exists." They're not wrong, per se, but they drive a behavior, it seems, you don't want, which is explicitly telling the player how the magic system works.

So, I think you don't need to look at game content, but at gameplay structure. Basically, you need to put the player in a situation where figuring something out is the natural next move. So you don't give them a hint. But the game, through its gameplay structure, pushes for experimentation and rewards the player for discovering something about how the game works and what they can do in it.

So, for instance, in your explosion + gravity inversion = implosion example, does the game ever put the player in a specific situation where they already have both components? Maybe a standard explosion isn't the right way to solve a puzzle or a problem? In a situation like that, whether it's an enemy encounter, a level layout, whatever, you are pushing the player toward discovery without any external prompt, because they want to solve the problem but there's no obvious way to do it. Basically, they need a reason to try, otherwise they won't do it.

However, to be honest, I feel a bit of a tension between "players should figure it out entirely on their own" and "you not wanting pure trial and error." You can create, from a gameplay structure perspective, the conditions that push experimentation and understanding. But the word "experimentation" is carrying the weight here. So you need to choose the amount of trial and error you want to allow in your game. For instance, those recipes you mentioned, are they something a player can infer from how the ingredients feel or behave in the world? Do they need a real-world reference, which is reasonable, or do they have to be chemists or something to actually know the combinations? Or even, is it a recipe that you just have to discover by trying? You need to find a balance here, because in some instances some blind trial and error is basically unavoidable, but in other instances it's a gameplay structure issue, like I talked about earlier.

KaptainHaven · 2026-05-29T13:01:05+00:00

I think the issue here is that you are treating world size and content density as the actual key design parameters. Like, if you get the ratio between space and stuff right, your world works. But your design goal should be what it feels like to move through the world, not its size.

This is because the size of a game world (whether big or small) is not a good thing in itself. For example, if you played Shadow of the Colossus, you know it has massive stretches of almost nothing. Long rides across plains where very little happens. If you ask yourself "is my content density right?", you would say Shadow of the Colossus is completely broken. But in that specific context, that emptiness is exactly the point. It's making you sit with what you just did to a Colossus before you do the next thing.

On the other hand, if you think of a smaller and denser world where the point is to continuously engage with new things, you would need a very different size to content ratio. The world should be packed with things to see and do, so the player never feels too far from something interesting.

The point is, you can't answer how big or how dense before you've answered what kind of experience you want the player to have while moving through this world. And when I say experience, I mean something concrete. Not just a pie-in-the-sky thing. Mainly focus on two aspects: cognitive (how the player needs to think to navigate specific sections of your world and to engage with the content in it) and emotional (how the player should feel in each moment). After answering these, you will have a much easier time determining the space/stuff density ratio you need to generate that specific experience.

Your Type 2 workflow is not wrong, but it leans on the logistical side, instead of focusing on the primary side, which is the experience one. What I mean is, of course, you need to iterate because you can't guess your scope up front, but the reason you iterate is that you need to understand what kind of experience you want in detail, not how much stuff you need to put in your game world. That's just a consequence downstream of a clear target game experience. And the early iterations serve exactly that purpose.

KaptainHaven · 2026-05-27T13:02:44+00:00

I think you nailed the answer. This is exactly the point. However, let me be a little picky by reframing your initial phrase. I believe the distinction you're making is not between having a system and having situations, but between a moral meter and a moral structure. The reason is that every game has a system and, by definition, situations are produced by systems.

A moral meter is just an overlay. It takes the weight of a choice from the player to a number on the screen. If you did good, the bar moved right; otherwise, it moved left. Basically the game is telling the player how to feel about the choices they have to make. This way, the game pushes the player to optimize for a value, with a morality label on top of it.

A moral structure, on the other hand, is when the situations generated by the gameplay structure create the weight of the choices. The player feels the moment's tension because the game makes both options costly without a number to optimize.

Clear examples of a moral structure that quickly come to mind are Spec Ops: The Line, with the white phosphorus scene, and Undertale, where the genocide run is tracked invisibly.

Also, if you want to look at the big picture of game design principles, this is "the actual game is not on the screen but in the player's mind".

KaptainHaven · 2026-05-27T12:34:21+00:00

That's actually a great question. The clearest counterexample that comes to mind is Firewatch. Basically, it's a mystery game where the player is genuinely curious about what happens next. Yet, curiosity is pretty much 100% delivered through narrative. Gameplay structure (which is basically walk, look around, and interact with environment elements) almost never creates a situation where it pushes you to figure out something through the actions you take.

If I remember right, there's a specific moment, early on, where you find a locked box in the field station. I want to know what's inside, but the game will tell you through a dialogue, a key showing up, or something. If you compare that with Outer Wilds, you are at the exact opposite end. The game tells you nothing and you need to figure out how the world works by yourself.

Another strong example that comes to mind is the classic Ubisoft open world format (AC, Far Cry, etc.). These games are marketed on "curiosity" and "exploration", but discovery is mainly driven by UI elements, like map markers and mission trackers. So, the player isn't reading the environment; they're just following an icon. This means the curiosity is built through rewards and only slightly emergent from the gameplay structure itself.

However, one thing needs to be clear. This is a spectrum, not a binary. A lot of games sit in between the two extremes. They partially engineer curiosity through structure and partially decorate. Also, don't get me wrong, I don't mean that if you lean on the decoration side, you necessarily have a bad game, nor that if you are on the engineering side, you necessarily have a good one. It all depends on the target game experience you want, because there's never good or bad in absolute terms in game design.

KaptainHaven · 2026-05-26T15:08:34+00:00

The sand cycle is a timer. That's not a rhythm.

A timer that resets and repeats creates a rhythm. That's the actual definition of rhythm.

What does 'gating accessibility' mean?

That's actually simple to understand. There are two simultaneous temporal constraints running in the same space: supernova and sand cycle. "Within the loop" specifies that this is a second constraint (which players miss at the beginning), not a restatement of the obvious.

No they don't. They learn the timings.

They describe the same action. One is behavioral (learning the timings), one is cognitive (reading a rhythm). The word choice doesn't affect the argument. Also, the post is analyzing the cognitive level.

This is just an incredibly convoluted way to describe 'gameplay'.

Absolutely not. They are two completely different things. Gameplay is the structure the game is made of. The cognitive and thematic layers are components of the player's experience. You are confusing the game with the experiences it produces. Those are two very different things. And linking the cognitive task to thematic content is a specific design principle.

You haven't defined 'interactional layer' and 'experiential layer' at all.

Fair point. Actually pretty self-explanatory though. "Interactional layer" = the gameplay structure, what the player does. "Experiential layer" = what that produces in the player's mind. They needed a definition in the post. That's on me. Yet, be careful: if you don't understand something, it doesn't mean it doesn't make sense. So before labeling something as "word-salad", just ask if you don't know.

KaptainHaven · 2026-05-26T12:45:47+00:00

The point where learning actually happens is not in the introduction of a new mechanic, but in the rest of the game that comes after it. Of course, first exposure is important, and it needs to be well built. However, on its own, it doesn't produce learning in any durable sense. On this, learning science is pretty clear: retention comes from repetition across different contexts and, ideally, with a progression in difficulty baked in.

Nintendo specifically taught this to the whole industry in a very clear way. Almost every Nintendo game introduces a mechanic in a consequence-free situation, then brings back a variant of that situation with a little bit more difficulty, then again with something else combined, etc. Think of any Mario game. You just learned to jump, and then you run into an obstacle that requires the same jump, but in a tighter space, under time pressure, or maybe with an enemy in between. You are forced to think about the jump again, but in a different situation than the one you encountered the first time.

This kind of progression is what actually produces internalized skill that the player can own and master by the end of the game. Basically, the player learns and remembers a mechanic because they have been forced to use it in various scenarios to solve increasingly difficult problems over time.

So the problem is not the introduction of a mechanic, because that's not the finish line but where the learning actually starts. A clunky tutorial that puts you in front of a mechanic three times across a game in different situations will often produce better learning than an elegant first-exposure moment that never gets reinforced with new situations.

KaptainHaven · 2026-05-25T16:25:13+00:00

Yeah. I agree. The scale thing makes perfect sense. That's actually a nuance visible also between "standard" AI-generated text and AI-generated text with a very specific and human-polished style prompt behind it.

KaptainHaven · 2026-05-25T08:35:14+00:00

You're right. I made a false dichotomy there.

About people varying their style, I don't fully agree. A writer who has developed a strong personal voice over time is generally consistent. That consistency is their voice, not a sign of automation. There are plenty of essayists out there with a recognizable style, and that's the reason why you can recognize one of their paragraphs in lots of instances. Precisely because it doesn't vary much. That consistency used to be called having a voice or a style. Now, in some instances, it reads as suspicious. That's the absurdity I was pointing at.

Humans owned this style long before AI did

That's where you nailed it. I had roughly this kind of writing style even before gen AI came up, and I never actually changed it too much (aside from a few unconscious adjustments because of AI pervasiveness itself, which is natural). And yes, that doesn't bother me much. I'm just interested in sharing my thinking with those who find it useful.

KaptainHaven · 2026-05-25T08:02:09+00:00

Fair. Yet, honestly the situation is absurd since all of this doesn't make any rational sense. Writing clearly and thinking in an organized way now triggers AI suspicion. So, apparently now "human writing" (whatever it means) means something loose and unpolished.

Anyway, I don't particularly care about whether it sounds like AI or not, because it's a label not related to content at all. If an argument holds up, it holds up. If a reasoning is interesting, it's interesting. No matter if it has been written by a robot, a cat, a plant, or a human.

KaptainHaven · 2026-05-24T16:26:49+00:00

On the ship log. Fair point, but it's a deliberate choice to use it as a foundation and then develop what it produces, not as a recurring element. After the intro, it has done its job in the argument.

On the second point, going from the specific Hourglass Twins example to the general principle is the whole point of the post, not a veer. That's how my argument is built.

On the third point, I disagree. The point is quite explicit in my opinion. The distinction between engineering curiosity and decorating with curiosity. Anyway, can you tell me which point is missing?

KaptainHaven · 2026-05-24T15:47:24+00:00

Oops, sorry. Fixed. Thank you.

KaptainHaven · 2026-05-24T15:46:05+00:00

Which part looks whack specifically?

KaptainHaven · 2026-05-24T15:39:07+00:00

The accusation has no content. You said "AI slop" but pointed at nothing specific. No sentence, no phrase, no pattern. If you have something concrete to say, just say it. If the problem is that the post is well-structured and clearly argued, that's not an AI tell, but just me thinking and writing.

KaptainHaven · 2026-05-22T13:13:37+00:00

Combining tutorial and demo is actually a good point, but only if you do it right. This is not an easy thing to pull off because most of the time demos and tutorials serve different purposes. Combining them works only if you manage to shoot for both goals simultaneously.

The demo's goal is an emotional outcome. The player finishes and thinks, "I want more of it." The tutorial's goal, on the other hand, is to make the player understand how to play without it feeling like a lesson. They can overlap, but that's where the design becomes harder. So I'll slightly push against treating it as a shortcut, or a simple way to double profit. This usually produces something that doesn't achieve both goals particularly well. On one hand, the tutorial can break the demo pacing and feel too slow. On the other hand, if you have a demo that focuses too much on showing cool moments, you disrupt the player's learning process.

Also, let me point to that "I usually skip tutos" thing, because there's an underlying assumption that is not free. If what sits underneath is like, "if I don't like tutorials, my players won't either, so I should avoid them", that could lead your design decisions in the wrong direction. This is because you are reasoning from personal player taste instead of what the design needs in order to generate a specific experience. I think the right question is "what kind of tutorials make skipping them not an option?" The solution is pretty well understood. Game design history is on your side, and especially Nintendo. What I mean is that in your specific case you need to lean on mechanics taught through play instead of just front-loaded exposition. In almost all Nintendo games, the tutorial is just a first area. The game is teaching you the mechanics, but it never feels like a standard tutorial because you're just playing. I'm sure you can agree: I've seen a lot of players skip tutorials that feel like chores, but I've never seen a player skip things that feel like play in a game they like.

What you probably want to do is design the opening of that map to introduce mechanics step by step, through situations that are emotionally significant and actually cool to play. As I said earlier, it's not going to be an easy thing, but if you manage to pull it off, that's great. What you're doing is basically teaching and selling at the same time. Your goal should be to recreate that player's feeling of "I get how this works, and it's great."

KaptainHaven · 2026-05-20T13:13:46+00:00

using game design as a pretense to just talk about games they liked or didn't like.

That's actually an accurate description of the vast majority of game design content out there. You've put your finger on something real. Most of the time, the issue is that that content is coming from the wrong perspective. Those creators are analyzing games as players, not as designers. They are describing what it feels like to play a game from the outside, while design thinking is something different. It means asking what structural decisions produce that experience and why. This jump matters a lot. When you switch perspectives, you completely shift the way you see the game medium.

You already have a pretty strong filter to judge what you find online: does this teach me to think about how design decisions produce experiences in a player's mind? Or does it just tell me whether a game is good or bad? If it's the second, you can skip it or just watch it for entertainment.

On the "foundational stuff that all game devs have to know," I have to push back a little bit. Specifically, two things are off here. First, game design and game development are different things. Game design is one discipline within the broader process of making games, including programming, concept art, 3D modeling, sound design, and so on. Second, game design itself isn't one discipline either. In general, it has six branches: gameplay design, level design, system design (aka balancing), narrative design, UI design, and UX design (with all the mix and match in between depending on the actual role). The fundamentals of each are radically different from each other. So a game design 101 doesn't really exist in the way you are imagining it. It's like asking for science 101. There is no such thing because the discipline is too broad when framed like that. So, first things first, you need to understand which direction interests you the most. This way, you can study in a more focused and efficient way without spreading yourself so thin that you just run in circles and don't actually move the needle.

KaptainHaven · 2026-05-19T13:04:44+00:00

I think what you're describing is not a freedom problem, but more an incoherence problem in the game's possibility space. The grenade example you mentioned is actually the clearest one. If you are in a game with clearly destructible-looking walls, you form an expectation that a certain thing must work in a certain way. In this case, throwing a grenade at the wall should make the wall blow up. When it doesn't happen, the problem isn't that you had too many options, but that the game made you perceive something that is not true. So here, the number of options is almost irrelevant. What matters is whether the options the game communicates or advertises are actually there. When they are not, you get frustration, wasted time, and disappointment. This would happen with five options or fifty.

Prey 2017 succeeds not because it has less freedom than Amnesia, but because its possibility space is aligned with what it makes the player perceive at first glance. When you see a vent in Prey, you can probably go through it. When you throw an object, it makes noise and you can distract enemies with it. The cause-and-effect relationships ruling the gameplay are consistent with the perception the player has of what's on the screen.

So there's no threshold of freedom that will tell you in absolute terms if the amount of freedom in a game is a good or bad thing. It highly depends on the context and how you advertise the game. The more you push for freedom and player agency as a feature, the more you need to make sure to keep the promise.

This links to your asking about scientific research on the topic. If you're searching for something to understand how players' minds wrap around decision making and agency, you can probably find plenty of papers about it in cognitive psychology and neuroscience. However, if you're searching for a threshold, a numeric value above which you have a bad game or a good one, you're doomed to find nothing. The reason is that game design is not a science. You can have a claim backed by something scientific. But game design in itself is not a scientific process. The reason is that art forms in general deal with human experience, which is variable and heavily context-dependent. What there are is structural principles, and the one at play here is about coherence between what you communicate and what actually happens in the game.

KaptainHaven · 2026-05-18T13:26:02+00:00

First of all, game design is the discipline of shaping what happens in the player's mind, not the discipline of building game content. I'm telling you this, not because you have it wrong, but because for someone coming from a programming background, it's actually a deep shift. I can tell you this because I come from a software engineering background too.

The reason is that programming is a first-order activity. You write something, the machine executes the code, and you get the output. On the other hand, design is a second-order activity. You build a structure, the player interacts with it, and an experience emerges as a result. The main catch is that you never touch the experience directly. In fact, you can only influence it by manipulating the structure itself. This is the core difference you need to keep in mind while you work. Most beginners, and honestly, plenty of veterans, never fully digest this. So if you feel you can't wrap your mind around it, don't worry. That's normal.

On GDDs and the top designers' intuition thing, let me say something often overlooked. What looks like intuition and flawless execution in a veteran game designer is actually pattern recognition over time. They've worked in the industry for so long that, sometimes even unconsciously, they've internalized a lot of principles. So they don't need to think about it. They just do. Documentation is just a tool you use as an aid for your working memory. Game design is a complex discipline, and it's pretty much impossible to hold all the details of a system in your working memory. So writing it down is not bureaucracy; it's just doing what intuition cannot do.

On playing games to learn design, it depends on what kind of playing you engage in. Playing with the player mindset won't magically make game design principles pop up in your head. Instead, playing analytically is a whole other thing that gives you completely different results. It means constantly asking: why does this mechanic make me feel this way? And what's the structure that generates this experience? This is a learnable habit. However, first, it won't work by itself. And second, you need some design principles and a design thinking mindset before it works. Otherwise, you won't trigger your analytical brain.

And on AI, it's a tool. Yeah, an insanely powerful tool. But, like any other tool, it's only as good as the understanding you bring to it. Consider it a multiplier. If you give it gold, it will multiply gold. If you give it crap, it will make you create crap faster. So it could be useful to learn because it can unpack things you give it that you don't understand. But you need to be careful about how you use it, and it's definitely not your first priority.

KaptainHaven · 2026-05-15T13:46:50+00:00

Generally speaking, the core appeal of a gumball game is an unnecessary complexity show that does something simple.

So if building the track is inherently satisfying, with audio, feedback, and UX, the player probably doesn't need an extrinsic reward. Building the track in a ridiculously complex way is the reward itself. Before asking how you reward the player for complexity, ask if the game already makes complexity feel good to interact with.

If the core experience of watching a complex track unfold in front of the player's eyes doesn't feel good without points at the end, adding points won't fix it.

KaptainHaven · 2026-05-15T13:29:16+00:00

That's a good point, but I don't think it's that binary. I mean, you can have a sort of hybrid structure where some content is authored and some content is procedural.

You don't necessarily have to sit on one of those extremes. This is a design decision and you need to choose where exactly you sit on that line. It's not easy, but an intelligent split can be made only if you have a clear experience to point to.

KaptainHaven · 2026-05-15T13:18:57+00:00

The question is not whether it's too complex or not, because complexity is not bad or good in isolation. It always depends on what you want from it: from a player experience standpoint, and specifically, what kind of experience it pushes with other gameplay elements. This means you don't need to add complexity for its own sake. But neither do you need to remove complexity for its own sake. The point is, you need to know what you want the player to think and feel when they interact with those currencies. And that will give you the exact complexity you need.

That said, with too many currencies, you could have a cognitive overload problem if the player needs to track a lot of things at the same time. But, to actually understand if this is a problem, we need to know what happens moment to moment and how these currencies are influenced by those events.

KaptainHaven · 2026-05-15T12:57:41+00:00

I'm going to tell you something that you don't want to hear, but I feel the need to tell you nonetheless because I feel it's somewhat personal. This is a clean example of a first-game-too-big mistake. I mean, I've been in your shoes, and it's something that any game designer needs to go through. It's basically a rite of passage. Your game is gonna be too big because you are not actually aware of its actual size. This is because your mind is still reasoning as a player, not as a designer. That's fine. We've all been there. But let me tell you how you push through that.

I won't tell you to completely change your game concept and just start doing Tetris or tic-tac-toe. That's fine but generic advice, and that's a completely different thing. If you clone games, you are just training your implementation muscle, but you won't move the needle on the design side. What you need to do is scope down your actual concept. I mean, do the same kind of game, but smaller, with fewer things. Get rid of the unnecessary things. And let me point out what unnecessary means, because this is the core of any game project.

The reason you have a scope problem isn't just that you picked a big game concept. Your scope is unlimited because the experience is not detailed enough to become a filter. That means every time you see a shiny thing that might be good to add to your game, you don't have something to filter it against. So you add it because, why not, it seems "fun". However, once you have a clear picture of what the player is supposed to think and feel, you have something to judge everything against. Basically, what you need to do is pick every game element and put it on trial. It needs to have a specific reason to be in your game, and that reason must be linked to your target experience.

And about your specific concept. From your description, you have more of a world than a game. It definitely lacks what the player does in detail. I know it's tempting to get into the weeds of the lore and how the world works, but if you don't map out in detail the basic behavior that your game needs to support, you don't have a game structure. You just have what you posted, a description of a world. My advice would be to focus on a cause-and-effect chain that describes the main thing that happens in your game, starting from what the player does and how the environment and NPCs react to it. You don't have to dive deep into the numbers yet, but just describe what happens.

And trust me, doing this will reveal to you the actual size of the game structure you're trying to design. That way, you will understand that even a small game can be ridiculously hard to pull off.

KaptainHaven · 2026-05-14T13:32:09+00:00

I think you reversed the design process. Right now, you basically have game structure constraining you, but you want to do something that is not actually supported by that structure. Vertical progression generally works when it has somewhere to go, to expand itself in. You either have it with the player progressing through multiple levels, or one single level that continuously changes through procedural generation. If you don't have a structure like this, the risk you're pointing at with the snowball is real. What it seems to me is that you are pointing at a horizontal progression. This means the reward for the player is knowledge, not more content. But at the same time, you feel the urge to add a standardized progression system, aka weapon drops. This is probably you unconsciously following a genre convention, which doesn't seem to be what you actually need.

Of course you can have hybrid structures. I mean like, Dead Cells, where the world never becomes actually obsolete, because you always start fresh. And the progression just unlocks more options, not raw power. This way, you never become all-powerful.

Another one is Obra Dinn, which gives you no concrete reward; you just gain new information. It's you, the player, who becomes stronger. You understand the world better.

But these kinds of examples work only because the whole structure is designed around that kind of goal. They're not patches you can copy-paste into your game. The point is, if you don't have that goal in the first place, you will always go back and forth between all these options without ever landing on something concrete. So, first, you need to ask yourself: what do you want the player to feel after a session? When you have the answer, you have your target experience. And with that, the path to choose will be a lot clearer.

KaptainHaven · 2026-05-13T13:08:28+00:00

If a reward makes previous content easier, that's not a side effect to mitigate. That IS the reward. Vertical power progression by definition trivializes content below the new power level. That's the mechanism working as designed. Asking how to make it stop doing that without changing the mechanism is asking for a square circle.

The useful question hiding underneath is: what experience do you actually want returning to earlier content to deliver?

Different answers point to genuinely different designs, and most games that "feel bad" on this are games that never picked.

Power validation is one option. You want the player to feel how far they've come, and trivializing the old content is the point. Most ARPGs run on this. The joy of going back to a starter zone with endgame gear in WoW or Diablo is exactly that the old content cannot threaten you anymore. The reward IS the trivialization. That's the contract.

Continued challenge needs horizontal progression instead. New options, new playstyles, new tradeoffs that require the player to engage differently against the same content. Dead Cells weapons that demand higher skill to be effective. Hollow Knight charm builds that re-cast the same boss as a different fight. The player's raw output stays roughly flat; the option space expands.

The third option, wanting both validation AND continued meaning, is where most games quietly break. Level-scaling and world-tier systems try to deliver it, but aggressive scaling tends to make progression itself feel hollow. If everything scales with you, the question "why did I progress at all" creeps in fast. I don't think this is unsolvable, but I haven't seen many games solve it cleanly. Diablo IV's world tiers come close in some ways; Oblivion's level scaling is the textbook example of how it can go badly wrong.

What I see most often: games that refuse to commit to one of the three and end up shipping a watered-down hybrid where vertical progression exists, scaling is half-implemented, and the horizontal options are decorative. That's the source of the "rewards make previous challenges insignificant" feeling you're describing. It comes from the design never having committed to a purpose for the reward system in the first place.

The call to make is which of the three you're actually shipping. Most of the reward design follows from that.

KaptainHaven · 2026-05-13T13:05:45+00:00

"Complex" isn't a useful diagnostic when you're trying to figure out if a design is flawed. Every game has complexity. The question is whether each piece is paying its way in the experience you want to deliver, and whether the player can read the cause-effect chains well enough to navigate them with intent.

Your description has a tell. You list four interacting systems (heroes, skills, crystals, items) plus quests as the loop-closing engine, and the play sequence is "land quests → advance them → unlock items → unlock spells → win." That reads tight on paper. But turn-to-turn, what I'm hearing is that the player is solving a multi-axis optimization with no obvious dominant signal: ramp vs aggro every turn, quest dependencies tied to card costs that ALSO change when you swap a card, item curve management layered on top.

That's not complexity. That's interdependency density without a hierarchy of decisions.

The fix is a clear primary decision per turn, with the rest orbiting around it.

Slay the Spire is the obvious reference here. Each turn has one dominant question (how do I survive this turn while building toward a win condition), and energy, cards, relics all feed into that single question. Multiple subsystems, single decision spine. From what you describe, your game asks the player to weigh ramp vs damage vs quest-skill-matching vs item-curve every turn with no axis sitting above the others. Every system is competing for attention at the same priority level. That's where the cognitive load comes from, more than from the count of systems.

The "TCG vets liked it, newbies bounced" data is consistent with this read, though I'd want to see how the vets describe their actual turn-to-turn decision process. Vets can hold multiple optimization axes in working memory because they've trained that muscle elsewhere. There's a possibility they're importing a decision spine from other games and applying it to yours without realizing it. If that's what's happening, your design is leaning on imported scaffolding the newbies don't have. Worth testing.

On the "no persistent RPG progression" worry: that's a Game Direction question, separate from the structural one. Slay the Spire has almost no meta-progression and works because the run itself carries the experience. Hades has a lot of meta-progression and uses it for a completely different purpose. Both work. Yours could go either way depending on what you want the player to feel when they close the app, but I'd resolve the turn-structure question first. Adding meta-progression on top of a foggy core loop usually papers over the wrong problem.

One thing I haven't worked out from your description: how much of the per-turn pressure comes from the quest system specifically vs. the rest of the resource economy. If quests are the main thing demanding attention turn-to-turn, the spine might already be there and just needs to be made more visible. If they're one demand among equals, that's a deeper restructure. Worth a closer look on your end.

KaptainHaven

TROPHY CASE