To someone outside the industry, making a game can look like one job: programming. In reality, game development is several distinct crafts working in tight coordination, and understanding what actually goes into it makes you a far better client — better at scoping, budgeting, and knowing where a project’s real risks live. Here’s the honest anatomy of building a game, from idea to launch.
It Starts With Design, Not Code
Before anything is built, the game has to be designed: what the player does, why it’s fun, how the systems interact, how difficulty and reward are paced. This is the foundation, and it’s where the most important decisions are made. A game that’s technically flawless but not fun failed at the design stage, not the engineering one. Good studios prototype early — a rough, ugly, playable version — to find the fun before committing to expensive production.
The Crafts That Come Together
- Art and animation. Characters, environments, effects, and UI — the entire visual identity, whether 2D or 3D.
- Programming. Gameplay systems, physics, AI, networking, and the engine work that makes it all run smoothly across devices.
- Audio. Music and sound design — quietly responsible for an enormous amount of how a game feels.
- Level and content design. Turning the systems into actual places, challenges, and progression a player moves through.
- QA and testing. Finding the bugs, balance problems, and rough edges before players do — not an afterthought, an ongoing discipline.
Production Is Iteration
Games aren’t built in a straight line; they’re built by playing, feeling what’s off, and adjusting — over and over. A mechanic that sounded great on paper turns out to be tedious; a level that seemed fine is too hard; something no one planned turns out to be the most fun part. This iteration is not a sign of poor planning; it’s how games are found. Budgeting and scheduling that leave no room for it produce games that shipped on time and aren’t fun.
Launch Is a Milestone, Not the End
Shipping is the beginning of a game’s life, not the finish line. Players find issues, balance needs tuning, and a game that’s supported after launch — fixes, updates, responsiveness to its community — holds an audience far better than one abandoned at release. Plan for the life of the game, not just its debut.
SoftwareSplash handles the whole of game development — design, art, engineering, audio, and testing — through the iteration it takes to find the fun, and the support that keeps a game alive after launch. Tell us about your game idea and we’ll help you build it properly.
The Engine Choice Comes With Its Own Terms
The engine is picked early and it is expensive to reverse. It decides what language the programmers write, the shape of the asset pipeline, which platforms you can export to without involving a third party, and what you owe when the game sells. A prototype can be thrown away; the engine chosen to build that prototype usually survives to ship, because the tooling, the build system, and the hires all end up sitting on top of it.
No engine is generally better than the others, only a better fit for a given project. The differences that decide a project are license terms, platform export, and what the engine does well without being fought.
- Unity. C# scripting, compiled ahead of time through IL2CPP for iOS and console targets. Three render pipelines (Built-in, URP, HDRP) that are not interchangeable: switching after production has started means reauthoring every material and most custom shaders. Licensing is per seat above a free Personal tier with a revenue and funding ceiling; that ceiling has moved more than once, so it is worth checking at the time rather than remembering.
- Unreal Engine. C++ alongside Blueprints for visual scripting, both compiled into the same game, and mixed codebases are normal rather than a compromise. Epic takes a 5 percent royalty on gross revenue past the first $1 million per product, lifetime. Nanite and Lumen assume a hardware floor and are not supported on standalone headset hardware.
- Godot. MIT licensed, with no royalty and no per-seat fee, scripted in GDScript or in C# through the .NET build. It has no first-party console export, so console releases go through third-party porting houses. Its 2D renderer is a real 2D engine working in pixel coordinates rather than a 3D scene viewed head on, which shows up in sprite, tilemap, and pixel-art work.
Frame Time Is the Real Budget
Rendering, physics, animation, and gameplay all spend from one number: the milliseconds available per frame. Sixty frames per second gives 16.67 ms, thirty gives 33.3 ms, a 90 Hz headset gives 11.1 ms, and a 120 Hz one gives 8.33 ms. The work has to finish inside that window on both the CPU and the GPU, on the weakest device you promised to support, not on the workstation the art was made on.
Headsets are the unforgiving case. Miss the window in a flat game and a player sees a stutter; miss it in VR and the runtime covers for you with reprojection, synthesizing an intermediate frame from the last one, which smears on fast motion and is felt physically rather than seen. VR also draws the scene once per eye. Single-pass instanced rendering shares the culling and the draw submission between the two eyes, but not the pixel work, so fill rate stays roughly doubled.
This is why art is authored against a technical spec instead of to taste, and why the spec is written before the first production asset rather than after the first performance panic. The spec fixes:
- Triangle budgets per character and per environment section, derived from the target device rather than from the source sculpt.
- Texture resolution and texel density, so surfaces at the same distance from the camera hold the same detail.
- Draw calls per frame, which is driven by material count more than by mesh count; batching only merges meshes that share a material and its parameter values.
- Real-time light and shadow caster counts, with everything else baked into lightmaps or light probes.
- Skinned mesh bone counts and LOD chains, since GPU skinning has a per-draw bone limit and blend shapes cost memory per vertex.
The Asset Pipeline, and What Holds It Together
Between the file an artist saves and the bytes on a player's disk sits a conversion step that is easy to underestimate. Source art is not what ships: a layered source file, a multi-million-triangle sculpt, and a 48 kHz WAV are inputs. The engine imports them and then bakes, compresses, and packages a separate per-platform version of each one.
Texture compression is platform-specific. ASTC covers mobile and standalone headsets, the BC formats cover desktop and current consoles, and the same texture therefore exists in several encodings by the time it ships. Build size and build time grow faster than the raw asset count suggests, and a clean multi-platform rebuild on a large project is measured in hours, which is why teams put that on a dedicated build machine early and stop doing it on a person's laptop.
Source control is the other load-bearing piece, and it fails differently for games than for software generally. Binary assets do not merge: two people editing the same scene, prefab, or texture produce a conflict no tool can resolve, so one of them loses a day's work unless the file was locked while they had it. Git handles code well and binaries poorly, and Git LFS moves the binaries out of history without giving you locking on its own. Perforce is common in games for that specific reason: exclusive checkout plus one source of truth for a very large binary tree. Whichever is chosen has to be running before the first artist starts, because migrating a project's history later is a project of its own.
Multiplayer Is an Architecture, Not a Feature
Whether other people are in the game is decided at the beginning or paid for later. Server-authoritative play means the server owns the true state while clients send inputs, predict the outcome locally, and reconcile when the server disagrees, with lag compensation deciding whose view of a moment counts. Deciding this after a year of single player code means rewriting every system that mutates state, which is most of them.
The models differ in what they cost to run rather than only in how they feel. Peer to peer or a listen server has no server bill, but the host gets a latency advantage, host migration is awkward, and cheating is hard to contain because a client owns the truth. Dedicated servers are authoritative and fair, and they cost money for every concurrent match for as long as the game lives, with someone on call to operate them. Deterministic lockstep, common in strategy games with large unit counts, sends only inputs and requires every client to compute a bit-identical result, which rules out floating point divergence across platforms and any unsynchronized randomness anywhere in the simulation.
Engine support is uneven, and that shifts where the work lands. Unreal ships replication and a dedicated server build target inside the framework, so its actor model already assumes a network exists. Unity is unopinionated by default: Netcode for GameObjects, Mirror, and Photon are separate choices with different authority models and different hosting assumptions. Godot provides high-level multiplayer nodes with RPCs and scene replication, and no hosted backend of its own.
Platform Certification Is Its Own Project
Consoles are closed platforms. Registered developer status with each platform holder, an NDA, and dev kits all have to exist before you can build for the hardware at all, and each approval is a business process with a queue you do not control.
Certification is a compliance test, not a quality or fun test. Each holder publishes its own requirements (Sony's TRC, Microsoft's XR, Nintendo's Lotcheck) covering behavior most players never consciously notice: correct handling of suspend and resume, a controller disconnecting mid-match, a user signing out or switching accounts, storage filling up during a save, the exact wording and placement of platform trademarks, and limits on load and boot times. A build can be finished, stable, and enjoyable and still fail on any one of these, and a failure means a fix plus a resubmission that re-enters the queue behind everyone else.
Age ratings run on a separate track. Regional boards issue them, ESRB in North America and PEGI across much of Europe among others, and digital storefronts mostly accept the IARC questionnaire, which produces several regional ratings from one self-declaration and can be revised if the board disagrees with what was declared. Store pages, localized metadata, capsule art, and screenshots are their own deliverables with their own review, and the content of the game constrains the rating rather than the other way around.
Frequently Asked Questions
What counts as game development, and what sits outside it?
Development is the work that produces a build, including the platform work that gets it through submission. Publishing is a separate function: storefront presence, pricing, platform relationships, funding, and marketing. Live operations is a third: running the servers, shipping seasonal content, moderation, and community response. One team can cover all three, but they are staffed and scheduled differently, and a plan that budgets only for the first runs out exactly when the other two begin.
How is an engine actually chosen?
Start from the platform list and the people you can realistically hire, then compare features. Platform export and license terms eliminate options before any feature comparison begins, and an engine nobody on the team has shipped with converts a known cost into an unknown one. Feature reels are the last input to that decision, not the first.
What has to be in place before full production starts?
A fixed platform list, a technical art spec derived from the weakest target device, and source control that handles binary files with locking. An automated build that produces a running package on every target should exist before the first production asset is made, because a pipeline problem found in month one costs one asset and the same problem found in month ten costs the library. The single player or networked decision belongs here too, since it determines how every gameplay system is written from the first line.
What does the client have to provide or decide?
The platform list, the target age rating, the monetization model, and whether the game is networked. Any brand, IP, licensed music, or existing art has to arrive with documented rights and in editable source form rather than as flattened exports, since flattened files cannot be re-authored to a technical spec. Approvals need one named person who can make a design call, because a change requested after an asset is final means redoing finished work, while the same change at the gray-box stage is a small edit.
What do you need from the platform holders, and when?
The console build of an engine is not in its public download. Once a platform holder approves you, its engine module comes through that platform's own developer portal, and the editor is rebuilt with it before you can produce a console build at all. Store setup, the rating questionnaire, and release date scheduling run alongside development rather than after it, because each has a queue on someone else's calendar.
Can multiplayer be added after launch?
Parts of it, yes. Features that sit next to the simulation rather than inside it can land late: leaderboards, asynchronous ghost data, cloud saves, friend lists, and sharing of user-generated content all read or write data outside the frame-by-frame game state. Shared authoritative state, meaning two people in the same world at the same time seeing the same events, is the part that is not additive.
When is a full game not the right build?
When the goal is a short marketing beat, a web interactive or a playable ad is a far smaller build than a full game and is usually the right shape for that goal. When the goal is teaching a specific procedure and showing whether it was learned, that is a training simulation, with assessment, scoring, and reporting requirements a game does not carry. And when a game already works and only needs to reach another platform, that is a port, which starts from a shipped codebase instead of an empty one.