People imagine game development as artists drawing characters and programmers making them move. That happens, but it is a small share of what a studio spends its attention on. Most of the work is a particular kind of problem-solving that does not exist in ordinary software: making something that has to be fun, which is not a requirement you can specify, only discover.
The part that cannot be written down
In business software, you can describe correct behaviour. An invoice either totals properly or it does not, and everyone can agree in advance. Games have no equivalent. "The jump should feel good" is a real requirement, it is the most important one in a platformer, and there is no document that settles it.
So the studio's central loop is different. Instead of build-to-spec, it is build-something-playable, play it, notice what is wrong, change one variable, play it again. A jump has a height, a rise time, a fall speed, a moment of hang at the peak, a forgiveness window after leaving a ledge, and a buffer that remembers a button press made slightly too early. None of those numbers can be reasoned to. They get found.
This is why core mechanics dominate the schedule of almost every game project. It is not that the code is hard — a jump is a handful of lines. It is that the code has to be written in a form that lets someone change those numbers a hundred times without a rebuild, and then somebody has to actually change them a hundred times.
Pipelines beat assets
The second thing that surprises people is how little of the art effort goes into any individual asset, and how much goes into the machinery that gets assets into the game.
A character is not finished when it is drawn. It has to be rigged so it can be animated, exported in a format the engine reads, brought in at the right scale, given collision that matches its visible shape, hooked to the animation states the code expects, and checked on the lowest-spec device you intend to support. Do that once by hand and it is an afternoon. Do it for two hundred assets by hand and the project is now an asset-processing job with a game attached.
So a studio's real output early on is a pipeline: the automated path from an artist's file to a thing running in the build. Teams that skip this ship a beautiful vertical slice and then slow to a crawl, because every new asset costs the same manual effort as the first one. Teams that invest in it look slower at first and then add content at a rate that seems impossible.
The same is true of levels, audio, localisation and UI. The question is never "can we make one of these". It is "what does it take to make the two hundredth one".
Platforms have opinions, and they are binding
Every target platform brings requirements that are not negotiable and not obvious. Console holders have certification checklists covering how your game behaves when a controller disconnects, when storage fills up, when a user signs out mid-session, how quickly you respond to a suspend request, and what your error messages are allowed to say. Mobile stores have their own rules about payments, data collection, age rating and background behaviour.
None of that is game design and all of it is mandatory. Worse, it is retroactive: a save system built without thinking about suspend-and-resume will fail certification, and fixing it late means touching everything that writes state. The studios that handle this well read the requirements before the architecture, not after the game is fun.
Device range is the other binding constraint, especially on mobile. A game that runs beautifully on a current flagship and stutters on a mid-range phone from a few years ago has excluded most of its potential audience. That is a design constraint as much as a technical one, because the fix is usually fewer things on screen rather than better code.
Playtesting is the specification
Because fun cannot be specified up front, playtesting is not a quality-assurance step at the end. It is how the requirements arrive, in pieces, throughout.
What makes it useful is watching rather than asking. Players are poor at explaining why something felt bad and excellent at demonstrating it — they hesitate at a door, they miss a jump the same way four times, they never notice a mechanic the designer thought was obvious. None of that shows up in a survey.
The practical discipline is to change one thing at a time between tests. When five things change and the game feels better, the studio has learned nothing it can reuse. This is the same reason the tuning values need to be adjustable without a rebuild: the cost of a single experiment determines how many experiments happen, and the number of experiments largely determines whether the game is good.
The bottom-right quadrant is where troubled projects live: a great deal of content built on a loop nobody proved. Everything in a well-run studio's process is arranged to avoid ending up there — prototype the feel first, build the pipeline second, and treat content as the thing you scale only once the loop has earned it.
That sequencing is not unique to games, incidentally. It is the same instinct behind our free prototype approach on mobile and web projects: build the uncertain part first, in a form you can actually try, before anything gets built on top of it.
Top comments (0)