Writing a Game Design Document (GDD) for Mobile Games
Without a GDD, your mobile game team works blind. The artist draws, the developer codes, the marketer plans—each with their own version of the game. A month later, mechanics don't align, UI doesn't fit in the Safe Area, and monetization doesn't cover CPI. We write a Game Design Document that solves these problems before development starts. Our experience: over 5 years in mobile game development and dozens of GDDs for projects ranging from hyper-casual to midcore. Each document is reviewed with your team and adapted to your tech stack (Unity, Godot, Cocos Creator) and target platform (iOS, Android).
A bad GDD: 40 pages of inspiring text with no numbers or diagrams. A good GDD: the artist understands the style from the moodboard and color table, the developer from state diagrams and numeric parameters, QA from the acceptance criteria checklist for each feature. That's a working document, not a marketing brochure.
What is a GDD and why is it indispensable?
A Game Design Document (GDD) is the single source of truth for the entire team. It captures all key decisions: from genre and mechanics to monetization and technical constraints. In mobile development, where iterations are short and budgets limited, a GDD protects against misunderstandings. Fact: a 4-person team without a GDD lost 2 weeks on rework because the artist, developer, and marketer worked with different visions. A GDD written in 2 days would have saved 2 weeks—that's 7 times faster.
How is a mobile game GDD structured?
The mobile game GDD differs from a PC/console document—it's more compact, focuses on touch interaction and mobile constraints, and includes a monetization section from the first page (that's not shameful, it's market reality).
Overview and Concept
One paragraph: genre, target audience, USP (unique selling point). References: 2–3 existing games with specific indication of what we borrow and what we do differently. Moodboard: 10–15 images of visual style.
Not "an adventure game in a fantasy world." Instead: "a match-3 with RPG progression in the style of Puzzle & Dragons, but with asynchronous PvP and no energy mechanic."
Core Mechanics
For each mechanic: name, 2–3 sentence description, user story ("as a player, I want X to Y"), state machine diagram, input events (tap, swipe, hold), parameters with default values and allowed ranges.
Example of parameters for a "throw" mechanic in a physics puzzle:
throw_power_min: 200 [100-400] throw_power_max: 1500 [800-2500] gravity_scale: 1.2 [0.8-2.0] bounce_factor: 0.6 [0.3-0.9] max_trajectory_points: 20 [10-40] These parameters are ScriptableObject in Unity. The game designer can change them without a programmer.
UI/UX Specification
Wireframes for each screen—not final design, but element layout, tap target sizes (minimum 44×44pt per Apple HIG), information hierarchy. Navigation map: all screens + transitions.
For mobile separately: behavior on interruption (call, notification), behavior on connection loss, orientation (portrait only, landscape only, both), Safe Area for iPhone with notch.
Monetization
Specific model with numbers: free-to-play + IAP, premium ($2.99 upfront), rewarded ads (target: eCPM $8–15 for casual). Description of each IAP: what we sell, pricing, where in the interface we offer it. Soft currency vs hard currency—sources (earning) and sinks (spending).
Energy mechanic if present: initial stock, regeneration time, maximum, ways to replenish. Specifically: 5 lives, regeneration 1 life/30 minutes, max 5, full regeneration 100 gems, 1 IAP of lives—20 gems.
Technical Requirements
Target platforms: iOS 15+, Android 8.0+. Engine: Unity 2023 LTS / Godot 4.x / Cocos Creator 3.x. Target FPS: 60 on iPhone 12+, 30+ on Android mid-range (Snapdragon 665+). Build size: up to 100 MB for first download (App Store / Play Store recommendations for cellular download). Asset streaming if needed.
Comparison of GDDs by Genre
| Aspect | Hyper-casual | Casual | Midcore/Hardcore |
|---|---|---|---|
| Document length | 10–15 pages | 20–30 pages | 40–80 pages |
| Mechanics | 1–2 core mechanics | 3–5 mechanics with progression | System of mechanics, recipes, crafting |
| Monetization | Rewarded ads + IAP | IAP + ads + subscription | IAP, DLC, battle pass |
| Technical requirements | Single build, low specs | Multiple platforms, medium specs | Optimization, server-side |
Level of Detail
A GDD is a living document. You don't need to describe every particle before development starts. You do need to describe:
- Core mechanics — fully, down to numeric parameters
- First-hour experience — in detail
- Content plan (levels, chapters, events) — structure without details for each level
- Monetization — fully
Level design for specific levels goes into separate Level Design Documents (LDD) when you get to level creation.
Formats and Tools
GDD in Notion or Confluence — convenient for collaboration, versioning, comments. Alternative: Google Docs with table of contents. Diagrams: Miro or draw.io (FigJam). Balance tables: Google Sheets (not in GDD, but linked from GDD).
We don't write GDD in Word without version control — a month later no one knows which version is current.
What's Included in Our Work
- Concept interview (1–2 hours)
- Overview and concept document with references and moodboard
- Description of all core mechanics with diagrams and parameters
- UI/UX wireframes for key screens
- Navigation map of the app
- Monetization specification
- Technical requirements
- Content plan (levels, events, DLC)
Timeframes
3–5 working days — GDD for a hyper-casual or casual game. For a midcore/hardcore project with complex systems — 7–14 days. Cost is calculated individually.
We guarantee: after delivery, you receive a document ready to hand over to the development team. Contact us to discuss your project and order a GDD.