Game Mechanics Development
A mechanic that looked perfect on paper falls apart in a player's hands in three minutes. The reason is rarely the idea — more often it's how it's technically implemented. A physically incorrect jump, an inventory that lags with 50 items, a combat system with race conditions on the server side — all of this kills gameplay feel before the player can appreciate the design.
Where mechanics break down in practice
Physics and control feel
Gameplay feel is the hardest part. A jump in a platformer feels "wooden" not because of Rigidbody numbers, but because of how gravity scales in the air. A standard Physics.gravity = new Vector3(0, -9.81f, 0) gives physically correct, but game-design-wise inconvenient jumping.
The right approach — separate coefficients for ascent and descent phases:
// Heavier fall — sensation of weight
if (rb.velocity.y < 0)
rb.velocity += Vector3.up * Physics.gravity.y * (fallMultiplier - 1) * Time.deltaTime;
// Cut jump on button release
else if (rb.velocity.y > 0 && !Input.GetButton("Jump"))
rb.velocity += Vector3.up * Physics.gravity.y * (lowJumpMultiplier - 1) * Time.deltaTime;
fallMultiplier = 2.5f, lowJumpMultiplier = 2f — starting values that are then iterated with the game designer. This isn't a formula, it's a starting point.
For shooters and action games, coyote time (jump 80-150 ms after leaving a platform) and jump buffering (jump input buffer 100-200 ms) are critical. Without these details, control feels "unresponsive" even if technically correct.
Combat systems and hit detection
Hitbox vs. hurtbox — basic separation often ignored in early prototypes and later rewritten for release. Hitbox (attack zone) and hurtbox (damage zone) should live separately from the visual mesh and be managed through PhysicsScene or OverlapBox/OverlapSphere with proper LayerMask.
The problem with OnTriggerEnter for combat systems: at high animation speed or low framerate the trigger might not fire at all. More reliable — Frame-based hitbox activation via AnimationEvent + manual overlap checks in the same function.
For networked games, combat mechanics require server-side validation. The client predicts the result (client-side prediction), the server confirms. On mismatch — rollback. Without this, any cheat like speed hack hits unprotected opponents.
Inventory and item systems
Architecture mistake — storing inventory state in MonoBehaviour on the scene. When transitioning between scenes the object is destroyed or duplicated. Correct approach — ScriptableObject as data container + separate manager with DontDestroyOnLoad.
For complex RPG inventories with crafting, equipment slots and item stacking we build through ItemDefinition ScriptableObject (static data: name, sprite, weight, tags) + ItemInstance (runtime state: quantity, durability, modifiers). This allows serializing inventory to JSON without Unity object references.
How we design and implement mechanics
Prototype before production
A new mechanic starts as an isolated prototype in a separate scene. The goal — get gameplay feel in 2-3 days, before the mechanic accrues dependencies. If the jump doesn't feel right in a bare scene with a cube — it won't improve after adding animations and effects.
We use game-designer parameters through ScriptableObject configs with [Range] attributes. The designer iterates values in the editor during Play Mode, without needing to stop and rebuild.
State Machine for game logic
For complex characters with dozens of states (Idle, Run, Jump, Fall, Attack, Stagger, Dead and combinations) we use hierarchical State Machines. Animator Controller suits the animation part, but state logic is better kept in code through the State pattern with explicit transitions — this is testable and independent of the editor.
For especially complex cases — Unity Visual Scripting or custom graph based on GraphView API. But often clean C# with enum flags is sufficient.
Systems we've built
- Procedural dungeon generation via BSP tree + corridor connection (roguelike)
- Dialogue system with branching, conditions, and voice acting via Ink runtime + Unity integration
- Inventory + crafting + equipment slots with save/load support via JSON serialization
- Combo systems for fighting games with frame data (startup / active / recovery frames) and cancellation via buffer
- Stealth AI with vision cone, alarm levels, and memory of last known player position
- Vehicle physics based on WheelCollider with custom suspension tuning
Work process
Mechanic analysis (1-3 days). We break down what the mechanic should do, what edge cases exist, how it interacts with other systems. If the spec is vague — we run a game workshop, playing the mechanic without code.
Prototype (2-5 days). Minimal implementation to check feel. No final architectural decisions — just enough to experience the mechanic.
Polish to production quality (from 1 week). Clean architecture, edge cases, integration with other systems, optimization, tests.
QA. Unit tests for logic (damage, stat calculations, state transitions). Manual testing on edge cases (what happens when jumping and attacking simultaneously? when dying during dialogue?).
Timelines depend on mechanic complexity: simple jump with coyote time — 3-5 days, full combat system with networking — 3-6 weeks. Cost is calculated after analyzing requirements.
Common mistakes when developing mechanics
Relying on physics engine where predictability is needed. Rigidbody with AddForce produces different results at different framerates. For platformers, kinematic controller on CharacterController or fully custom movement without physics is more reliable.
Not separating visuals from logic. Animation shouldn't manage state. AnimationEvent as trigger — OK. AnimationEvent as source of truth about whether character is attacking — source of bugs.
Hardcoding numbers instead of configs. float damage = 25f right in attack code means every balance tweak requires recompilation. ScriptableObject with attack parameters solves this, plus allows different configs for different enemies.