Players complain about "wooden" controls, and developers don't understand why a mechanic that looks perfect on paper falls apart in practice. The problem lies in the details: a physics jump without coyote time, hit detection with race conditions, an inventory that lags with 50 items. Game mechanics development requires not only game design intuition but also architectural discipline. Over 5+ years, we have implemented 30+ mechanics for projects ranging from mobile platformers to multiplayer shooters and developed a system that minimizes risks.
How to Implement Gameplay Feel in Practice
Gameplay feel is the hardest part. A platformer jump feels "wooden" because of how gravity scales in the air. Standard Physics.gravity = new Vector3(0, -9.81f, 0) gives a physically correct but game-design-unfriendly jump. We use separate coefficients for the ascending and descending phases:
// Heavier fall — feeling of weight
if (rb.velocity.y < 0)
rb.velocity += Vector3.up * Physics.gravity.y * (fallMultiplier - 1) * Time.deltaTime;
// Cut jump short when button is released
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 are starting values that are later iterated with the game designer. Additionally, critical are coyote time (jump 80–150 ms after leaving a platform) and jump buffering (buffer of 100–200 ms). Without these details, the controls feel "unresponsive," even if technically everything is correct.
"Coyote time is a key technique for responsive controls, described in the GDC talk 'Juice It or Lose It'."
Why Mechanic Architecture Solves 80% of Problems
Physics and Controls
For character movement, we choose between Rigidbody (realistic physics but unpredictability with different FPS), CharacterController (predictable movement but limited collision physics), and a custom kinematic controller (full control but more code). For platformers, CharacterController is preferred; for simulators, Rigidbody; for fighting games, custom. According to our data, 60% of game bugs are related to incorrect mechanic architecture. Wrong choice leads to 40% rework in later stages.
| Approach | Predictability | Performance | Implementation Complexity |
|---|---|---|---|
| Rigidbody | Low | High | Medium |
| CharacterController | High | Medium | Low |
| Custom Kinematic | High | Low (more code) | High |
Combat Systems and Hit Detection
Frame-based hitbox activation via AnimationEvent + manual overlap checks is more reliable than OnTriggerEnter. For networked games, server-side validation is mandatory: the client predicts, the server confirms. Without this, every fifth hit can be canceled due to desync.
Inventory and Item Systems
An architectural mistake is storing inventory state in a MonoBehaviour on the scene. The correct approach is ScriptableObject as a data container + a separate manager with DontDestroyOnLoad. For complex RPG inventories, we build using ItemDefinition (static data) and ItemInstance (runtime state). This allows serializing inventory to JSON without references to Unity objects. More about ScriptableObject in Unity documentation.
How We Design and Implement Mechanics
Prototype Before Production
A new mechanic starts with an isolated prototype in a separate scene. The goal is to achieve gameplay feel in 2–3 days, before the mechanic becomes burdened with dependencies. We use game design parameters through ScriptableObject configs with [Range] attributes. The designer iterates values in the editor during Play Mode without stopping or rebuilding.
| Mechanic Type | Prototype Time | Full Implementation Time |
|---|---|---|
| Simple (jump, interaction) | 2–3 days | 1–2 weeks |
| Medium (inventory, dialogs) | 3–5 days | 2–4 weeks |
| Complex (combat system, AI) | 5–7 days | 3–6 weeks |
State Machine for Game Logic
For complex characters with dozens of states, we use hierarchical State Machines in code — they are testable and independent of the editor. The Animator Controller is only suitable for the animation part. We keep state logic in C# with explicit transitions.
Systems We Have Built
- Procedural dungeon generation via BSP tree + corridor connection (roguelike)
- Dialogue system with branching, conditions, and voice acting through Ink runtime + Unity integration
- Inventory + crafting + equipment slots with save/load support via JSON
- Combo systems for fighting games with frame data (startup / active / recovery frames)
- Stealth AI with cone of vision, alert levels, and memory of player position
- Vehicle physics based on WheelCollider with custom suspension tuning
Work Process
- Mechanic Analysis (1–3 days). Break down requirements, edge cases, interaction with other systems. For vague specs, we conduct a game design workshop.
- Prototyping (2–5 days). Minimal implementation to test feel. No final architectural decisions.
- Refinement to Production Quality (from 1 week). Clean architecture, edge cases, integration, optimization, tests.
- QA. Unit tests on logic, manual testing of edge cases.
Example ScriptableObject Config for Attack
[CreateAssetMenu(fileName = "AttackConfig", menuName = "Game/AttackConfig")]
public class AttackConfig : ScriptableObject
{
public float damage = 25f;
public float range = 2.5f;
public int startupFrames = 3;
public int activeFrames = 5;
public int recoveryFrames = 8;
}
Common Mistakes in Mechanic Development
- Relying on the physics engine where predictability is needed. Rigidbody with AddForce gives different results at different FPS. For platformers, a kinematic controller on CharacterController is more reliable.
- Not separating visuals from logic. Animation should not control state. AnimationEvent as a trigger is okay, but not as a source of truth.
- Hardcoding numbers instead of configs. ScriptableObject with attack parameters solves this and allows different configs for different enemies.
Our Experience and Numbers
Over our work, we have implemented 30+ mechanics, average prototype time is 3 days, share of projects without rework after release is 85%. Clients save an average of 30% of budget due to quality prototyping. Contact us for a consultation — we will analyze the requirements, propose an architecture, and create a prototype within a week.
What's Included in Development
- Technical specification with edge cases description
- Prototype to test feel (playable build)
- Source code with comments and tests
- Configuration files (ScriptableObject) for balancing
- Integration and API documentation
- Test plan and QA results
- Access to repository and developer chat
Order mechanic development — get a reliable implementation from the first prototype.