Conflating Player Skill With Character Skill

tim-cain game-design system-design rpg action-rpg player-agency combat-design fallout outer-worlds vampire-bloodlines

Abstract

Problem: In action RPGs, when should the outcome of an action depend on the player's real-time skill (e.g., aiming) versus their character's stats? Conflating the two creates frustrating moments where a player does everything right but the game overrides them with a dice roll.

Approach: Tim Cain shares his evolved design philosophy, drawing on mistakes made in Vampire: Bloodlines and lessons applied in The Outer Worlds, explaining how he now categorizes every player-facing action as either a "player skill" or a "character skill."

Findings: The solution is to cleanly separate what the player directly controls from what the character's stats govern — and never let them overlap on the same action. Character skills should affect secondary properties (recoil speed, damage, information quality) rather than override direct player input (aiming, hitting).

Key insight: If the player feels like they're in direct control of something, don't let a stat roll contradict that feeling. Instead, route character progression into complementary channels the player doesn't feel they personally control.

Source: https://www.youtube.com/watch?v=3s7IBpFTaKY

1. The Core Problem

Tim addresses a viewer question about the tension in action RPGs like Fallout 3 and beyond: the original Fallout games were entirely about skill checks and dice rolls, but as the series shifted to first-person shooters, a conflict emerged. If a player has their crosshair perfectly on an enemy and pulls the trigger, but the game says "you missed" because of a low skill stat, that feels terrible. The player did their job — the game punished them anyway.

This is what Tim calls conflating player skill with character skill: using a character stat to override something the player believes they are directly controlling.

2. Tim's Design Rule

Tim now categorizes every action in his games into two buckets:

  • Player skills — things the player directly controls (aiming, positioning, choosing when to swing a melee weapon, clicking on objects in the world)
  • Character skills — things governed by stats, attributes, perks, or skill points that the player invests in on their character sheet

The rule: character skills should only govern areas the player doesn't feel they have direct involvement in. The two categories must not overlap.

3. Practical Examples From Combat

3.1. Recoil Recovery (The Outer Worlds approach)

Instead of making a gun skill affect whether your shot hits where you aimed, Tim routes the skill into recoil recovery speed:

  • Low shotgun skill → after firing, the gun kicks up and takes a long time to come back down
  • High shotgun skill → the gun barely moves, and you're ready to fire again almost immediately
  • Max shotgun skill → minimal recoil, nearly instant recovery

The mathematical result is the same — higher skill means more damage per second — but the player never feels like aiming was taken away from them. They always hit where they point. The skill just determines how quickly they can fire again.

3.2. Melee Weapons

In The Outer Worlds, melee hitting is entirely player-controlled: if you're in range, facing the enemy, and your swing arc passes through them, you hit — no roll, no check. But how much damage that hit deals is governed by your melee skill. More points means more damage per swing, not more hits. The player controls the action; the character controls the potency.

3.3. Critical Hits

Critical hit damage should also be a character skill — something you invest points or perks into. The player doesn't directly cause a critical; the character's build determines how much bonus damage crits deal.

4. Beyond Combat: Non-Combat Skill Design

Tim emphasizes this principle applies equally to non-combat skills. His example: you enter a room with a puddle of blood on the floor.

Bad design: If your observation/medical skill is too low, you can't interact with the blood at all. The player can clearly see it — blocking interaction feels arbitrary and frustrating.

Good design: You can always click on the blood and get a response. What changes is the quality of information based on your skill:

  • Low skill → "That's blood."
  • Medium skill → "That's blood, and it's still wet — hasn't coagulated. It's been here less than an hour."
  • High skill → "That's more blood than a person can lose and survive. Someone died here, within the last hour."

Similarly with lockpicking: don't prevent interaction with a lock entirely. If there's a lockpicking minigame, let the character skill control how difficult the minigame is. If there's no minigame, then yes, there's a minimum skill threshold — but the player should still be able to attempt the interaction.

5. Abstraction Matters

Tim notes this conflation problem is far worse in first-person action games than in turn-based isometric RPGs. In a turn-based game, there are so many layers of abstraction that players already accept that hitting depends on character stats — nobody thinks the characters are literally standing still waiting for their turn. The abstraction gives permission for stat-based resolution.

But in first-person games, the player feels physically present. They're aiming, moving, swinging. The more immediate and visceral the game feels, the less tolerant players are of stats overriding their direct input.

The spectrum: The more abstracted your game is, the more you can conflate player and character skill. The more action-oriented and immersive it is, the more rigorously you need to separate them.

6. The Vampire: Bloodlines Lesson

Tim admits to making this exact mistake in Vampire: The Masquerade – Bloodlines. In that game, low combat skill gave you a larger reticle, and shots would land randomly anywhere within that circle — even if your crosshair was dead-on the enemy. This felt bad. He also mentions a system where the reticle itself would move around based on skill, which was equally unsatisfying.

These experiences directly informed his later approach in The Outer Worlds, where aiming is always player-controlled and skills affect everything else around the shot.

7. Testing and Validation

Tim recommends listening to QA testers and focus groups to detect conflation problems. Watch what players feel when they play — if they express frustration at actions they thought they controlled, you've likely conflated a player skill with a character skill. Then figure out how to separate the two.

8. References