Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Game Developer

A game developer designs and builds interactive games, combining programming, real-time graphics, and gameplay systems, which is a perfectly reasonable vocation until you remember that frame rate is a religion, the physics engine disagrees with reality and the customer, the asset pipeline's mood is weather, and the NPC walked through a wall because the wall was not in its worldview. You learn to translate "make it fun" into engines, shaders, input, state, audio, networking, and a build that must arrive at sixty frames per second on a machine whose owner has strong opinions about background applications. A game is not a program; it is a real-time loop with a deadline every sixteen milliseconds, a simulation that must agree with itself across clients, and a folder of textures whose import settings are somebody's thesis. This guide travels from making one sprite move to shipping a multiplayer title across storefronts, with practical stops at engines, gameplay, graphics, maths, performance, networking, and the recurring discovery that a build marked " playable" is merely playable on the machine that built it. The grand objective is a game that runs smoothly for as long as anyone wants to play it; the daily evidence is usually a frame spike that names its cause, a shader that compiles on three platforms, and a certification submission that fails for a reason someone once anticipated in a checklist now considered prophetic.

Things to recognise

• A scene marked "playable" in the editor is playable in the editor and on the machine that built it; it is not volunteering information about the target console, the retail disc, or the player's aversion to background apps.
• Editor time and frame time are not the same currency, since the editor runs with debug overhead, the profiler, and a build the developer trusts, while the shipping build runs with a player who does not.
• Confirm the platform target, input scheme, and build settings before adding features, because a correct scene on the wrong platform remains impressively slow and surprisingly persistent.

Take the useful exit

Level 1 · Novice

Read the engine before asking the editor to spawn civilisation

You inspect a game engine, run sample projects, move a sprite, and read gameplay scripts, learning how a perfectly polite editor can spawn a small fortune of untested scenes before you finish reading its prefabs.

You begin with read-only artifacts: an engine's project view, sample builds, scene hierarchy, scripting reference, and a frame counter expressing recent opinions. A game engine is a framework that provides rendering, input, physics, audio, and scripting for building games; a scene is a collection of objects the engine loads and ticks; a script is a piece of code the engine calls each frame to change those objects. You review these with designers, artists, and an experienced developer so everyone can trace how input, logic, and output connect before anyone presses play whose confirmation dialog is also a build.

Suppose a team wants to make a character jump "in the engine." In a sandbox project with no shipping target, you read the input API, inspect the existing controller script, add a vertical velocity when a button is pressed, and note that the character either floats or snaps, because gravity is a value nobody documented. You record the jump curve, the gravity value, and the single line that exceeded all others in making the jump feel correct. One brisk script is an anecdote with good posture, not a game; but it prevents the team from commissioning an animation system for a jump that runs four frames a second on the target hardware.

Words from the spaceship manual, translated

Game engine: A framework that provides rendering, input, physics, audio, and scripting for building games, priced per seat and configured through an editor. The engine handles the boilerplate; you handle the consequences of having asked it to simulate a world.
Scene: A collection of objects the engine loads and ticks each frame, often edited in a visual editor. A scene is welcoming on the way in and very particular about its load order on the way out.
Frame: A single pass of the game loop, ideally completed in under sixteen milliseconds. A frame that takes twenty milliseconds does not run at sixty frames per second; it runs at fifty and tells the customer a story about hardware.
Prefab: A reusable object template the engine instantiates in scenes, with overrides that may or may not agree with the original. The prefab is a promise the instance keeps, until an override silently breaks it in a build the QA team has not yet seen.