UX/UI Game Development: From HUD to Inventory
Designing UX/UI for games that meet strict performance and usability requirements is its own engineering discipline. Take a shooter HUD: information must be readable with peripheral vision without distracting from combat. Inventory in RPGs opens for seconds but is remembered for long. Different tasks, one solution: interfaces that work anywhere, from mobile devices to consoles. Our approach reduces draw calls by 20–30% compared to typical implementation, saving up to 15% frame time.
Why Game UI Is a Separate Discipline
Unlike web design, game interfaces work in real time. Every extra draw call can cause FPS drops. We account for this from the design stage: minimize Canvas count, use batching, and correct font atlases. 10+ years of experience in gamedev let us anticipate bottlenecks. For example, a typical mistake is using one Canvas for the entire UI, causing redraws of hundreds of elements when a timer updates. The solution is splitting Canvas.
How We Ensure Interface Performance
Canvas with Overlay on Mobile
A classic problem: Unity redraws the entire Canvas when any child element changes. Solution — separate Canvas into static and dynamic parts, place Canvas component on frequently updated elements separately. This reduces Canvas rebuild count by 3–4 times.
Scaling for Different Aspect Ratios
Canvas Scaler in Scale With Screen Size mode with Reference Resolution 1920×1080 and Match = 0.5 is standard but not a cure-all. On iPad (4:3) or foldable devices, UI breaks. We set anchors in RectTransform consciously for each element. For unusual resolutions, we add extra rules via Layout Group.
TextMeshPro and Dynamic Font Atlas
If a game has multiple languages with Cyrillic, Greek, Arabic — one atlas isn't enough. When characters are added at runtime, Unity repacks the atlas, causing a freeze of 2–5 ms. For critical screens, we use static atlases with an explicit character set. This completely eliminates atlas-related freezes.
Animation Performance
UI animations often become a bottleneck. DOTween and LeanTween work with transforms directly, bypassing Animator Controller, reducing CPU load. Comparison: scale animation of a button via Animator takes ~1.2 ms, via DOTween — 0.4 ms. On 20 simultaneously animated elements, the difference becomes critical. Order interface development with these optimizations in mind.
How to Measure UI Performance
We use Unity Profiler: look at CPU Usage → Canvas.BuildBatch and Canvas.SendWillRenderCanvases. Target for mobile devices is no more than 2 ms for UI rendering. Target metrics table:
| Category |
FPS budget |
UI budget |
| Mobile (60fps) |
16.7 ms |
2–3 ms |
| Console (30fps) |
33.3 ms |
4–5 ms |
| PC (60fps) |
16.7 ms |
3–5 ms |
Exceeding the UI budget leads to stutter.
How We Design Game UI
HUD: Information Without Distraction
A good HUD makes information available without requiring focus. We work on the ambient information principle: HP bar changes color when decreasing, pulses at critical level. For each element, we define update frequency: HP — every hit, minimap — 0.5 sec, timer — every second. Update with accumulator instead of direct per-frame update reduces Canvas rebuild load.
Menu Screens and Navigation
Navigation via NavigationGraph in Unity UI — for gamepad and keyboard support. We set explicit navigation for each button, not relying on automatic. Transition animations — via DOTween or LeanTween, not Animator for simple cases. For complex sequence animations, we use Animator with AnimationEvent.
Inventory and Drag-and-Drop
Drag-and-drop is implemented via interfaces IBeginDragHandler, IDragHandler, IEndDragHandler. The main issue is behavior when leaving ScrollRect. We manage events through EventSystem.current and separate scrolling and dragging by a threshold. Virtualization of long lists — via Pooling + ScrollRect, using ObjectPool<T> (built-in since Unity 2021 LTS). For console version, we add gamepad support via EventSystem.
What's Included in the Work
- UX audit of existing UI or design from scratch
- Component library in Figma with state variants
- Assembly in Unity with animations and gameplay integration
- Adaptation for all target platforms (iOS, Android, PC, consoles)
- QA on devices: safe zone notch, different densities, aspect ratios
- Implementation documentation and maintenance recommendations
Timeline and Cost
| Stage |
Timeline |
| UX audit |
3–5 days |
| Design in Figma |
1–2 weeks |
| Implementation in Unity |
1–3 weeks |
| QA and adaptation |
3–5 days |
Cost is calculated individually after analyzing the scope and platform requirements. A simple HUD — from a week, a full UI kit — from a month. Contact us to get a consultation and preliminary estimate for your project. We guarantee a transparent process and fixed deadlines.
For more details on technical aspects, read the official Unity Canvas documentation and TextMeshPro documentation.
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:
|
Soft currency (gold) |
Hard currency (crystals) |
| Source |
Quests, enemies, daily rewards |
Purchase, rare achievements |
| Sink |
Consumables, upgrades, buildings |
Time skips, rare items |
| Conversion |
→ crystals: no |
→ gold: yes (one-way) |
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
| Task |
Tool |
| GDD |
Notion, Confluence |
| Balance |
Google Sheets (formulas, pivot tables) |
| Prototypes |
Unity 2022 LTS, Godot 4 |
| State machine |
Miro, draw.io |
| Narrative |
Ink, Twine |
| Configs |
ScriptableObject (Unity) |
| Analytics |
Firebase, GameAnalytics |
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
-
Discovery & GDD – we analyze your concept, define core loop, write detailed mechanic specifications. (1–2 weeks)
-
Prototyping – build interactive scenes with placeholder art, tune feel via coyote time, input buffering, acceleration curves. (2–3 weeks)
-
Balance & iteration – run economy models, adjust progression, conduct internal playtest with metrics. (1 week per major mechanic)
-
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.