Game Parameter and Item Stats Balancing

Balancing Game Parameters and Item Stats

Often after release, players pick only one character while other classes sit idle. We've encountered this dozens of times when balancing projects on Unity and Unreal. Each time, we build a DPS matrix per class, calculate Time to kill (TTK) for every pair, find outliers, and explain their cause. With 10+ years of experience and over 50 completed projects, we guarantee mathematically sound balance that retains users and keeps the game engaging.

What Metrics Do We Calculate Before Tweaking Numbers?

DPS (damage per second) — the basic attack metric. Calculated with attack speed, critical chance, and critical multiplier: DPS = baseDamage * attacksPerSecond * (1 + critChance * (critMultiplier - 1)). If the mage has DPS = 450 and the warrior has DPS = 280, but the warrior has 3x HP, their EHP/DPS ratio needs to be examined in pair.

EHP (effective hit points) — HP accounting for armor and evasion: EHP = HP / (1 - damageReduction). With damageReduction = 0.4 and HP = 1000, we get EHP = 1667. This is an honest comparison of survivability across different archetypes.

TTK — for PvP and encounter design. TTK = EHP_target / DPS_attacker. Target TTK for PvP is 8-15 seconds according to game design guidelines. If TTK for all class combinations falls within this range, fights are interesting. TTK < 3 seconds means one class simply annihilates another before the first reaction. The TTK matrix reveals imbalance 5x faster than manual testing.

These three metrics are built into a table for all classes, levels, and key equipment sets — and updated with every change to base parameters.

How Does Item Budget Work?

Each item in Unity is described by an ItemDefinition ScriptableObject with stat fields. We don't tweak numbers directly in the editor — data is exported to CSV, opened in Excel/Google Sheets, where pivot tables and charts are built.

Budget system — a standard approach to item balancing. Each item has a "budget" of stat points proportional to its rarity and level. For example:

Stats inside the item spend this budget according to a "cost per stat" table: 1 point of damage = 2 budget, 1 point of HP = 1 budget, 1% critical chance = 3 budget.

This allows quick verification: if a Legendary sword of level 20 exceeds 220 budget, it's broken. If it's far below, it's useless. After tuning coefficients, new items can be added without individual checking — they automatically fit the balance.

How to Balance Procedurally Generated Items?

In games with procedural generation, balance is defined by ranges, not fixed values: damage: [min, max] for each level. The spread shouldn't be too wide — an item with damage: 10-90 with average 50 gives the player too much lottery feeling and blurs progression. A spread of ±20-30% from the average is a working range for most RPGs.

Affixes on random items are also pulled from a pool with weights. An AffixPool ScriptableObject stores List<AffixDefinition> with a weight for each — the rarer the affix, the lower the weight. WeightedRandom selection during generation. Important: sum of weights does not have to equal 100 — the algorithm calculates probability as weight / totalWeight.

Why is PvE Encounter Balance Important?

Encounter design is also math. For each encounter, an encounter budget is calculated: sum of "costs" of enemies placed by the designer. Enemy cost = HP * (1 + damageModifier) using a simplified formula scaled to the group's DPS at that level.

If the DPS of a 4-player group at level 15 totals ~800/sec, and an encounter with three enemies has a total EHP of 12000 — that's 15 seconds of combat with zero losses. Add a mechanic like interrupt or area attack — and TTK for the group becomes longer. This is designed in a table before placing enemies in the level.

Tools and Process

Balancing work is always iterative. Standard cycle:

1. Edit table in Excel/Google Sheets.
2. Export to CSV.
3. Auto-import into ScriptableObject via an Editor script.
4. Playtest with automated metric collection.
5. Analyze data and re-edit table.

Manual number entry is excluded from day one. For online games, hot-update capability for balance without redeploying the build is critical. In that case, balance data is stored on server in JSON/CSV and loaded at session start. Unity client reads it via Remote Config (Unity Gaming Services) or a custom endpoint.

What Our Work Includes

• Full DPS/EHP/TTK matrix for all classes and levels
• CSV export with auto-import into ScriptableObject
• Budget System and Affix Pool configuration
• Documentation of current balance and recommendations
• Test run on a build with metric capture
• Support during patching and hot-update cycles

Additionally, we provide a per-class report and iteration recommendations. Our methodology reduces balancing time by 30% — saving project budget.

Estimated Timeline

Five Things to Check Before Final Balance

• Are there any TTK pairs with TTK < 3 sec (instant kill situations)?
• Is the entire level range covered by items with correct budget values?
• Is there a stat with zero or negative "usefulness" (that players always ignore)?
• Are edge cases checked: max crit stack, max attack speed, zero damage from armor?
• Does each class have at least one dominant role in encounters, so none is "strictly worse"?

Get a consultation on balancing your project — we'll estimate the scope and propose a work plan. Contact us to order full balancing with import tools and analytics.

What makes our game design services comprehensive?

Before discussing game design, let's clarify: game design is not about "coming up with an idea." Anyone can do that. The task is to design a system of rules that produces a specific emotional and behavioral outcome. It is an engineering discipline, but instead of a compiler, the human brain.

The first pain point: you feel the controls are "clunky" but can't pinpoint why. Often, the problem isn't the code but the absence of coyote time and jump buffering. Or linear acceleration that doesn't convey weight. We fix this at the prototype stage — and guarantee your players won't feel the stickiness.

Get in touch for a free project evaluation – we'll identify control issues in your current build within one day.

Game design services: from GDD to polished build

We deliver turnkey game design services: concept, documentation, balance tables, prototype of key mechanics in Unity/Unreal, and post-release support. Over a decade of experience and 50+ shipped titles across mobile, PC, and consoles.

Deliverables included:

• Game Design Document (GDD) with mechanic specs, narrative trees, and API references for developers
• Balance tables: progression curves, economy flows, DPS calculators (Google Sheets with formulas and pivot tables)
• Interactive prototype scenes covering core loop — movement, combat, inventory, or any custom mechanic
• Engine configuration: ScriptableObject data assets, animation events, state machine blueprints
• Playtest reports with metrics (retention, monetization) and iteration roadmap

Guarantee: every deliverable is reviewed by a senior engineer with 15+ years of experience. No template work — each solution is custom-fit to your genre and platform.

How do our game design services improve combat system tuning?

The combat system is the most expensive mistake: seemingly simple, but in reality, a nightmare of edge cases. Let's break down melee combat.

Choosing a hit detection method

Hitbox — colliders on weapons. Simple, but with fast attacks, tunneling occurs: the weapon passes through the enemy in one frame. Continuous Collision Detection (Physics.CCD) fixes this but costs CPU. Raycast/spherecast — cast rays along the weapon's trajectory. More accurate, less framerate-dependent. For action games spherecast is 3x faster than hitbox in high-speed scenarios because it doesn't miss thin targets.

Setting up attack windows

Each attack has three phases: startup, active, recovery. Long startup creates "heavy" hits. Short recovery gives an aggressive style. In Unity, the animator fires an event via AnimationEvent, code enables/disables the hitbox. Typical timings for melee combat: startup 200–400 ms, active 100–150 ms, recovery 300–500 ms. Tuning these windows reduces feel complaints by 60% in playtests.

Building the state machine

The character is a finite state machine. Basic states: Idle, Moving, Jumping, Attacking, Hurt, Dead. Business logic in C#, animator handles only transitions. Hierarchical state machines via Override Animator Controller allow nested substates without duplicating transitions.

Why is a mathematical economic model critical?

Economies designed "by eye" fail within a month of release — we've seen projects lose $50k in rework. Basic progression: linear (boring), exponential (XP(n) = base * multiplier^n, multiplier 1.5–2.0), polynomial (a * n^b, b 1.5–2.5). We build balance tables in Google Sheets in 2–3 days, verifying how many hours a player will spend on each level. Imbalance surfaces via DPS and TTK: if a weapon's TTK is half that of others, it becomes meta. Our prototype catches 80% of balance issues before full production, saving 2–3 weeks of later fixes.

Currency flows

Each currency must have a clear source (tap) and sink. Example of a two-currency system:

One-way conversion protects monetization. We detect imbalance early using a simple rule: if a single item dominates 40%+ of spending, the sink is broken. This approach reduces post-launch balancing costs by up to $15k.

How does environmental storytelling work in game design?

Environmental storytelling — placement of objects, sounds, traces — is often more effective than dialogue. For dialogue we use Ink (integration with Unity). Ink scripts are editable by a narrative designer without a programmer. Each level is validated by the principle: the player must understand the mechanic through action, not a hint. This approach improves first-time clarity by 30% in our playtests.

Our tech stack for game design

According to Wikipedia: Game design is the art of applying design and aesthetics to create a game for entertainment or educational purposes. We apply this principle from day one.

Process: how we work in 4 steps

1. Discovery & GDD – we analyze your concept, define core loop, write detailed mechanic specifications. (1–2 weeks)
2. Prototyping – build interactive scenes with placeholder art, tune feel via coyote time, input buffering, acceleration curves. (2–3 weeks)
3. Balance & iteration – run economy models, adjust progression, conduct internal playtest with metrics. (1 week per major mechanic)
4. Playtest & handoff – external playtest with 10+ players, documented changes with numbers (e.g., "startup 400ms → 250ms"), deliver final GDD and configuration files.

Iteration and playtesting: 2-week cycle

The first prototype is always uncomfortable — that's normal. Our cycle: playtest every 2 weeks. After that, a list of changes with numbers: "startup 400 ms → 250 ms". Opinions without numbers are not accepted. We record feelings, change numbers, repeat. Clients save 2 to 3 weeks on iterations thanks to this process.

Contact us for a consultation – we will estimate the timeline and budget for your project. Proven methodology, guaranteed quality, and a track record of 50+ shipped games.