Unneeded Realistic Designs

tim-cain game-design realism system-design cost-benefit weather time-of-day survival-mechanics

Abstract

Problem: Game developers often add realistic features — weather, time of day, eating, sleeping, disease — simply because they seem cool or immersive. When should you actually include them?

Approach: Tim Cain examines each realistic feature through a three-part lens: does it integrate into game mechanics, is it fun for the player, and is the implementation cost justified?

Findings: Realistic features that aren't woven into system mechanics become expensive window dressing. Every art asset spent on rain effects is an asset not spent on new content. Features only justified by realism tend to frustrate rather than engage.

Key insight: Never add a realistic feature just because it's realistic. It must serve your design goals, connect to game mechanics, and be fun to interact with — otherwise it's a net negative regardless of how cool it looks.

The Core Question

Tim's thesis is straightforward: realistic features in games are only worth adding when they serve a purpose beyond realism itself. A colleague asked him why his games rarely featured weather systems, which prompted him to articulate the reasoning he'd been applying throughout his career.

Weather Systems

Weather (rain, snow, fog) looks cool and provides visual variation — revisiting a location in rain or snow makes it feel different. But the costs are enormous:

  • 2D: Decals, swapped tiles, alternate wall textures for wet/snowy versions
  • 3D: Wet materials, pixel shaders, particle effects
  • Footprints and puddles: Additional decal systems with decay logic
  • Memory and CPU: Always a cost, regardless of approach

Tim's critical point: the time an artist spends making a rainy version of a town is time they could have spent building an entirely new neighborhood. You're trading content for cosmetics.

Unless weather integrates mechanically — fire spells weakened by rain, cold debuffs in snow, combat bonuses in certain conditions — it's just window dressing at a premium price.

Time of Day

Tim did implement time of day in both Fallout and Arcanum, but in Arcanum it was mechanically justified:

  • Day Mage / Night Mage traits made time of day affect spell power
  • Ranged combat factored in lighting — harder to hit targets in darkness
  • Stealth used ambient lighting conditions — sneaking was dramatically easier at night
  • Dawn and dusk had distinct color tints (blue for dawn, red for dusk)

The lesson: Arcanum's time of day earned its keep because it touched multiple game systems. It wasn't just a visual effect — it changed how you played.

Eating and Drinking

Consumables can be interesting when integrated properly. Tim points to The Outer Worlds, where eating and drinking only mattered on Supernova difficulty — tying survival mechanics to a difficulty setting rather than forcing them on all players.

But adding food systems for their own sake opens a can of worms:

  • Quantity, quality, and nutrition all become factors
  • UI burden — communicating hunger/thirst states clearly
  • Balancing — how fast does hunger accumulate? What are consequences?
  • Dietary restrictions — vegan characters, allergies, preferences

Before long, you're building an eating simulator inside your RPG. Is that what you set out to make?

Sleep

Sleep mechanics can work — they create pressure to find safe locations, can restore spells or health, and can interact with travel time on world maps. Games often tie sleep quality to location: a paid inn gives a buff, a bedroll on a dungeon floor risks interruption and gives lesser rest.

But the same question applies: is managing sleep quantity and quality fun for the player, or just another meter to babysit?

Disease

Disease can justify entire subsystems — D&D's mummy rot makes mummies genuinely frightening, and high Constitution becomes more valuable when disease exists. You can build perks, spells, and consumables around disease management.

But it also demands:

  • UI space for disease status and progression stages
  • Cure spells that exist solely to remove a status effect from another subsystem
  • Consumables for disease management cluttering inventory
  • QA testing for all disease interactions

If disease wasn't in your original design goals, adding it creates a cascade of costs for something players may find more annoying than engaging.

The Three-Part Test

Tim distills his approach into three questions for any realistic feature:

Is It Mechanically Integrated?

Does the feature connect to your game systems? Weather affecting combat, time of day affecting stealth, disease affecting character builds — these justify their existence. Pure visual effects don't.

Is It Fun?

Beyond challenge, does the player enjoy interacting with this system? If a feature only makes the game harder without being interesting, it creates frustration, not engagement. Challenge and fun are not synonyms.

Is the Cost Justified?

Consider the full implementation burden:

  • Art: New textures, effects, alternate versions of existing assets
  • Code: New systems, shaders, interactions with existing mechanics
  • Audio: Environmental sounds, modified footstep audio, ambient effects
  • Design: Balancing time, UX design for new status displays
  • QA: Testing plans for every permutation of the new feature

Every hour spent on a realistic feature is an hour not spent on core content.

The Bottom Line

Tim's advice is to revisit your design goals document. If "realistic simulation of a role-playing world" wasn't one of your stated goals, question why you're building simulation systems. Go back to what you set out to make, and spend your budget on that.

Source: Tim Cain — "Unneeded Realistic Designs"

References