Game Planning & Project Design Services

Game Project Planning

Common scenario: a team arrives after three months of development asking "why does our repository have 40 gigabytes and Git crashes every time we pull?" The answer is almost always the same: PNG textures and FBX files committed directly without Git LFS, repository history bloated to unusable state. This can be fixed, but rewriting history on an active project is painful—and completely preventable.

Game development planning isn't about Gantt charts. It's about ensuring technical decisions in the first two weeks don't become problems three months later.

Documentation: GDD as a Living Tool

A poorly executed GDD is an 80-page PDF nobody reads after the second sprint. A well-executed GDD is a structured knowledge base the team actually uses every day.

What Must Be in a GDD

Minimum requirements to start development:

Gameplay Systems — precise description of each mechanic with parameters. Not "the character jumps," but "jump: height 2.4 units, air time 0.6 sec, 150 ms coyote time available, double jump allowed, landing blocks attack for 200 ms." Numbers may change during balancing, but they must be documented and versioned.

Technical Constraints — target platforms, minimum hardware requirements, memory and draw call limits. If the game must run at 60 fps on iPhone 11, this constraint affects all art decisions from day one.

Scope and Features — explicit list of what's in the MVP and what comes later. "Maybe we'll add crafting" isn't planning—it's a source of feature creep.

References — specific games with specific mechanics taken as baseline. "Like Dark Souls, but faster" is a working reference for a combat designer.

How We Maintain the GDD

We use Notion or Confluence—the GDD lives as a wiki, not a file. Changes are tracked in history, comments are possible, mechanics cross-reference each other. Technical design and art design are separate sections but reference each other.

Core principle: every mechanic in the GDD has a status—in development, ready, on review, frozen. This lets you understand real project state anytime without phone calls.

Technical Architecture

Stack Selection — Not Religion

We detail Unity vs. Unreal extensively in the main catalog section. But at the planning stage, several related decisions are equally critical:

Render Pipeline in Unity. URP (Universal Render Pipeline) for mobile and VR. HDRP for PC/consoles with cinematic visuals. Built-in (Legacy) only if taking over an old project. Changing pipelines mid-development means rebuilding all materials. The decision is made on day one.

Game Object Architecture. Classical MonoBehaviour approach versus ECS (Entity Component System via Unity DOTS). ECS delivers orders of magnitude performance improvement with large object counts, but sharply increases code complexity. For hypercasual games—overkill. For strategies with thousands of units—necessary.

Network Architecture. If the game plans multiplayer, this decision is made before writing the first game mechanic. Single-player code and networked code are fundamentally different: in networked games, every state change must be explicit and synchronizable.

ScriptableObjects as Configuration Layer

In Unity we use a ScriptableObject-oriented approach for game data storage. Weapon configuration, enemy parameters, level settings—all stored as ScriptableObject assets, not hardcoded values. This lets game designers adjust balance without programmer help and without rebuilding.

Asset Versioning and Management

This is where most small teams lose time in the most painful way.

Git + Git LFS

Standard Git isn't designed for binary files. A 4K PNG texture weighs 20–50 MB, and committing it directly bloats repository history catastrophically.

Git LFS (Large File Storage) stores binary files separately, keeping only pointers in Git history. Configure once in .gitattributes:

*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

This must be set up before the first asset commit. After—painful migration.

Perforce — alternative for large Unreal projects. Epic Games uses it themselves. Better for very large repositories (hundreds of gigabytes), native Unreal Editor support. Higher infrastructure costs and setup complexity.

Branching

For game projects we use simplified Git Flow:

• main / master — stable build, always works
• develop — active development
• feature/* — individual features or mechanics
• release/* — release preparation, bug fixes only

Rule: nothing uncommitted to main that hasn't passed QA. Sounds obvious, but this is what turns "the last stable version" into a meaningless phrase.

CI/CD for Game Projects

GameCI

GameCI is a set of GitHub Actions for Unity. Automatic building for all target platforms on every push to develop. This solves a specific problem: "it builds on my machine but not yours."

Typical pipeline:

1. Unity license activation (headless)
2. Run tests (Unity Test Runner — EditMode and PlayMode tests)
3. Build for Android (APK/AAB)
4. Build for iOS (Xcode project)
5. Build for PC (Standalone)
6. Upload artifacts to S3 or directly to Firebase App Distribution

Build time: 15–40 minutes depending on project size. The team gets a fresh build link without manual work.

Unity Cloud Build

Unity-hosted solution. Easier setup, more expensive with high build volume. Convenient for small teams without DevOps engineers. Integrates with Unity Dashboard and allows automatic TestFlight and Google Play Internal Testing submission.

Jenkins

For large projects or teams with non-standard requirements. Full control over hardware and process, but requires administration. We use Jenkins when projects need specific build machine configuration or when GameCI doesn't cover the scenario (e.g., console platforms).

Planning Timeline

Total before full production: 4–6 weeks. Not bureaucracy—insurance against rewrites.