Giving Good Feedback

Know What They're Making

The first and most fundamental step before giving feedback is understanding what game the team is actually trying to make. This sounds obvious, but Tim emphasizes it requires real homework:

• Read all design docs — at minimum the General Design Document (GDD), which covers setting, story, tone, mechanics, planned encounters, creatures, and items
• Find their design pillars — if they don't have formal pillars, ask someone to verbally summarize their three or four core goals for the game
• Everything you evaluate should map back to those pillars — pillars become the yardstick for all feedback

Tim rarely gets pushback on asking for pillars. The one time a studio said "we're fast and loose, we play things by gut," he responded: "Okay, then my design feedback will also be fast and loose and based more on feeling than comparison to design pillars." The implication was clear — without pillars, feedback loses its anchor.

Attend Meetings and Get in Early

Tim makes a point of attending team meetings and level design meetings, listening more than talking:

• Team meetings reveal high-level status — what's complete, what's coming up, what to look for when playing
• Level design meetings are where the real actionable feedback lives, especially during the gray-level (blockout) stage

Why Early Feedback Matters

At the gray-level stage — rough layouts with cubes and untextured objects — you can talk about:

• Sight lines to points of interest
• Whether combat spaces are large enough for planned encounters
• Whether alternative paths (stealth routes, etc.) actually exist
• Where lore dumps and environmental storytelling could go

Once art, lighting, and narrative have made their passes, suggesting layout rearrangements wastes enormous amounts of work. Give structural feedback when changes are cheap.

Tim praises Bethesda's approach to environmental storytelling — the level layout and props themselves tell a story — and notes that early level reviews are the perfect time to identify where similar techniques could be applied.

Study Comparable Games

Before giving feedback, Tim researches games similar to the one being developed:

• Ask the team what they consider comparable titles
• Play those games (even a few hours helps), or watch thorough reviewers like Mortismal Gaming who complete 100% of a game before reviewing
• Use comparisons in feedback: "You're doing this thing — they did it too, and it led to this problem. Do you have a plan to avoid that?"

This grounds feedback in evidence rather than personal opinion.

Craft Actionable Feedback

This is Tim's central principle. Actionable feedback means the recipient can immediately do something with it.

What to Avoid

• "I like this feature" / "I hate that feature" — this is not relevant and not helpful
• Tim notes this describes 99% of online game criticism: people who fancy themselves game critics saying "I hate this" with no constructive direction

What to Do Instead

• Match features against design pillars: "You say NPC conversations are important, but there's an entire level with no NPCs to talk to"
• Identify gaps between stated goals and execution: "You say your game is strong in lore, but I see ruins and magic items with absolutely nothing written about them"
• Flag things that need to be done: When told "that'll come later," respond with "Okay, but mark that as something that has to be done — if you don't, it'll feel lacking. Either do it, or change your design pillar."
• Highlight novel features — both for morale and for strategic direction. Tim once told a studio: "You could make a whole game around this one feature." That's both a compliment and a warning — if that feature isn't their intended focus, it may need to be scaled back or the game will become known for it whether they want that or not.

The "Double Down or Remove" Principle

Sometimes a feature is so good it threatens to overshadow everything else. The feedback becomes: "You either need to double down on this or get rid of it, because this is going to make or break your game."

Use Your Gut — Then Explain Why

Tim does rely on intuition while playing prototypes, but he always translates gut feelings into explanations:

• Is there a particular area you're drawn to?
• Is there something confusing? (While accounting for features that are simply unfinished)
• If something is fun, say why it's fun: "It matched your pillar. I loved crafting — it gave me useful items and it was fun to hunt for ingredients." That's far more useful than "your crafting is good."

Ask Questions, Don't Just Prescribe

At early development stages, teams don't always expect you to provide the solution — but they expect you to point in the direction of one.

Tim illustrates with an overpowered weapon example: rather than just saying "this weapon is too strong," ask productive questions:

• "What are you going to do to balance this?"
• "Will you nerf damage, range, or accuracy?"
• "Could you lock some of its power behind perks so players have to specialize?"
• "Could you make its ammo expensive or tie ammo drops to aspirational content?"

The goal is pointing out that the weapon, as designed, is all anyone will ever use — then offering directions rather than dictating a single solution.

Balancing: QA and Tracking Data

Tim admits balance is not his strong suit ("if you don't believe me, go play some of my games") and that he usually prioritizes fun over perfect balance. He doesn't mind if some builds or weapons are overpowered — what he watches for is whether a particular build can't finish the game.

Lean on QA

• Build a strong relationship with the QA lead
• Ask where the game feels too easy or too hard
• Find out which weapons, perks, or traits QA always takes — and which they never touch
• "That's a dump stat" from QA is a signal worth investigating, even if the answer turns out to be build-dependent

Use Tracking Data

Tim's favorite balancing tool. If you have a programmer willing to implement it, tracking data records what players actually do:

• Which weapons and armor are used most/least
• Where players die frequently
• Which content gets engaged with

The key advantage over QA opinions: tracking data is guaranteed to be objective. QA might say they love a weapon — tracking data shows whether everyone gravitates to it. If every tester keeps picking the same shotgun, that's a signal to investigate why.

Tim notes this infrastructure may already exist if you have an achievement system — Outer Worlds tracked player behavior for both achievements and the flaw system.

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=-72btgrwKzA