Chapter 1: The Anatomy of a Game

The Anatomy of a Game 🎮

Read the loop and you can read any game.

Every game you have ever played, from a card game at a kitchen table to an open-world release built by a thousand people, is a machine made from the same parts. Players feel the whole thing at once. Developers see the parts. That shift, from feeling games to reading them, is the first skill this book teaches.

This chapter is the dissection. You will start with what designers actually mean by “game,” then follow a single frame through the game loop, out of the processor, through the graphics card and onto the screen, so that “lag” becomes a diagnosis instead of a complaint. You will survey who makes games and how studios pick their tools. Finally you will install Godot 4, build your first scene and put it under version control.

1.1 — What a Game Really Is 🧩

Ask ten people to define “game” and you will get ten answers that leak: “something fun” includes a roller coaster, and “something with rules” includes tax law. Three scholarly attempts are worth memorizing because each points at a different load-bearing part.

Bernard Suits (1978): playing a game is “the voluntary attempt to overcome unnecessary obstacles.” A golfer could carry the ball to the hole; the prohibition is the game.
Katie Salen and Eric Zimmerman (2003): “a system in which players engage in an artificial conflict, defined by rules, that results in a quantifiable outcome.” Note system, and note that the outcome is measurable.
Sid Meier, designer of Civilization: a game is “a series of interesting decisions.” No choices, no game.

Together: a game is a rule-bound system that presents voluntary obstacles, demands meaningful decisions and reports a measurable result. Every system you build in this book hangs on one of those clauses.

The MDA Framework

In 2004, Robin Hunicke, Marc LeBlanc and Robert Zubek published a short paper that gave the industry a shared vocabulary. The MDA framework splits any game into three layers:

Layer	What it is	Who controls it	In Among Us
Mechanics	The rules and systems as built: numbers, actions, limits	The developer, directly	Tasks, one-hit kills, emergency meetings, majority vote
Dynamics	Behavior that emerges when players use the mechanics	Nobody directly	Alibis, accusations, tailing someone to verify a task
Aesthetics	The emotional response the game produces	The player, in the moment	Suspicion, fellowship, the thrill of a successful lie

The key insight is that developer and player approach the game from opposite ends. You build mechanics and hope for aesthetics; the player feels aesthetics and slowly infers the mechanics. You cannot code “fun.” You can only code a vote timer and a kill cooldown, then playtest to see whether suspicion emerges. LeBlanc also proposed eight kinds of aesthetic pleasure that designers still use as a checklist: sensation, fantasy, narrative, challenge, fellowship, discovery, expression and submission (the comfort of a routine). A good game knows which two or three it is chasing.

Genre Is a Bundle of Mechanics

Players use genre labels as shopping categories. Developers use them as recipes, because a genre is a bundle of mechanics that has proven to work together.

Genre	The bundle
Roguelike	Procedurally generated levels + permanent death + short runs + unlocks that persist
Metroidvania	One interconnected map + abilities that unlock blocked paths + backtracking
Battle royale	Large lobby + a shrinking safe zone + scavenged gear + last player standing
Soulslike	Stamina-gated combat + lose your currency on death + recover it at the spot

Vampire Survivors (2022) bolted auto-attacking, roguelike upgrade choices and an ever-growing horde together and spawned a subgenre dozens of studios have since copied. New genres are recombined, not invented.

1.2 — The Engine and the Loop 🔁

Strip the art and story out of any video game and what remains is a program that does the same three things, over and over, for as long as the game runs. That program is the game loop. In pseudocode it fits on an index card:

while running:
    read_input()
    update(delta)       # physics, AI, scripts
    render()

You will almost never write the loop yourself. A game engine owns it and calls your code at the right moments. In Godot you attach a script to a node and implement callbacks: _input(event) fires when something happens on the controls, _process(delta) once per rendered frame, and _physics_process(delta) on a fixed schedule for physics and movement. The engine turns over on its own; your job is the vehicle around it.

Delta Time

Here is the first bug every new developer writes: move a sprite five pixels per frame. At 60 FPS it crosses the screen comfortably; at 30 FPS it moves at half speed; on a 144 Hz monitor it rockets. The game’s speed has become a function of the player’s hardware.

The fix is delta time, the elapsed time since the last frame, which the engine hands you as delta. Express speeds in units per second and multiply:

extends Sprite2D

var speed := 200.0   # pixels per second

func _process(delta: float) -> void:
    position.x += speed * delta

At 60 FPS delta is about 0.0167 and the sprite moves 3.3 pixels per frame; at 30 FPS delta doubles and so does the step. Either way it covers 200 pixels every second.

Fixed vs. Variable Timestep

Delta solves speed but not consistency. With a wildly varying delta, a fast bullet can pass through a thin wall because at no single frame was it touching. Physics engines therefore prefer a fixed timestep, advancing the simulation in identical slices no matter how rendering is doing.

	Variable timestep (`_process`)	Fixed timestep (`_physics_process`)
Runs	Once per rendered frame	60 ticks per second by default in Godot
Delta	Changes every frame	Constant (1/60 second)
Best for	Camera, UI, anything cosmetic	Movement, collisions, anything repeatable
Risk	Tunneling and jitter under load	Falls behind if a tick runs long

Godot lets you change the physics rate in Project Settings (Physics, Common, Physics Ticks per Second) and caps the catch-up ticks it will run in one frame, eight by default, so a slow machine degrades gracefully instead of spiraling. Godot 4 can also interpolate object positions between physics ticks, so a 60 Hz simulation still looks fluid on a 144 Hz display.

The 16.7 Millisecond Budget

A 60 Hz display shows a new image every 1/60 of a second: 16.67 milliseconds. That is your budget. Input, scripts, physics, animation, audio and rendering all have to finish inside it, or the frame misses its slot, the display repeats the previous one, and players see a hitch. At 30 Hz the budget is a roomy 33.3 ms; at 120 Hz it is a brutal 8.3 ms, so a game comfortable at 60 must do the same work in half the time. Professional developers ask of every feature: how many milliseconds does this cost, and is it worth them?

1.3 — From Hardware to Pixels 🖥️

The loop is software. To understand why it falls behind, follow a frame through the hardware, because the two chips involved are built for completely different jobs.

CPU vs. GPU

The central processing unit has a handful of powerful cores, typically four to sixteen in a modern PC or console. Each is a generalist that can run any code and make decisions quickly, which makes the CPU the right tool for game logic: enemy AI, collisions, your GDScript, the loop itself.

The GPU is the opposite design: thousands of simple cores all doing the same operation on different data at once, which is exactly the shape of coloring two million pixels sixty times a second. The division of labor is clean: the CPU decides what to draw and issues instructions called draw calls; the GPU decides what color every pixel ends up. Either one can be the bottleneck.

The Rendering Pipeline in Plain Terms

Between “the player is standing here” and “these pixels are lit” is a series of stages every real-time renderer shares:

Culling. The CPU works out what is actually on screen; objects behind the camera or hidden behind walls are skipped.
Vertex processing. Every model is a mesh of triangles with three corner points, or vertices. A vertex shader moves each vertex to its position on screen.
Rasterization. The GPU works out which pixels each triangle covers and turns them into fragments.
Fragment shading. A fragment (or pixel) shader computes each fragment’s color: texture, lighting, shadows. Most GPU time goes here, and the result goes to the display.

Godot 4 offers three backends for this pipeline: Forward+ for high-end desktop, Mobile for phones, and Compatibility for older drivers and web browsers.

Resolution and Frame Pacing

Resolution is the size of the framebuffer. A 1080p frame is 2,073,600 pixels; 4K (3840 x 2160) is 8,294,400, four times the work for the fragment shader. That is why console games often render internally at a lower resolution and upscale, and why pixel-art games pick something like 640 x 360 on purpose, leaving almost the whole budget for gameplay.

Frames per second is only half the story. frame pacing is the other half. A game that averages 60 FPS but stalls for 80 milliseconds twice a second feels worse than one locked at a steady 30, because the eye is far more sensitive to irregularity than to a lower constant rate. That is why benchmarks report “1% lows” beside averages, and why developers often cap the frame rate.

Why “Lag” Has Several Causes

Players use one word for at least five different failures, and the fixes have nothing in common.

What the player says	What is happening	Where to look
“It’s laggy” (low FPS)	CPU-bound: logic and draw calls miss the budget	Profile scripts, fewer objects, fewer draw calls
“It’s laggy” (low FPS)	GPU-bound: shading misses the budget	Lower resolution, simpler shaders, fewer lights
“It stutters”	Uneven pacing; loading or shader compilation mid-play	Preload assets, compile shaders up front, cap FPS
“My hits don’t register”	Network latency: the server is 100 ms away	Client prediction, lag compensation
“It feels mushy”	Input latency from press to visible result	Shorter render queue, lighter post-processing

A CPU-bound game runs just as badly on a faster graphics card, and no hardware fixes a 100 millisecond round trip to a server.

1.4 — The Industry 🏭

Games are made by people with specific jobs, inside businesses with specific models, using tools chosen for specific reasons.

Who Does What

Small teams blur these lines; large ones split each into specialties.

Discipline	What they own	Specializations
Design	The rules, levels and experience	Systems, level, narrative, UX
Engineering	The code that makes it run	Gameplay, engine, graphics, tools, networking
Art	Everything you see	Concept, 3D, animation, VFX, technical art
Audio	Everything you hear	Sound design, composition
Production	Schedule, scope, budget	Producer, project manager
QA	Finding bugs before players do	Functional, compliance, localization
Publishing	Getting the game to players	Marketing, community, analytics

Indie, AA and AAA

The industry sorts studios by budget and team size. The labels are fuzzy but useful.

Indie studios work without a large publisher and range from one person to a few dozen. Stardew Valley (2016) was built almost entirely by Eric Barone over four and a half years; Balatro (2024) was made by a solo developer known as LocalThunk and sold millions of copies in its first year. Indies trade budget for creative control and speed.
AA studios are mid-sized, often 50 to 200 people, on budgets in the tens of millions.
AAA is the blockbuster tier: hundreds or thousands of developers, multi-year schedules and budgets that for the largest titles run well past 100 million dollars before marketing. That scale brings spectacle and enormous risk, one reason 2023 and 2024 saw widespread layoffs at large studios.

Live Service

A premium game is finished when it ships. A live service game is never finished on purpose. Fortnite and Genshin Impact run on seasons, battle passes and regular content drops, with teams whose entire job is operating a game that launched years ago. The appeal is revenue that continues instead of a single launch spike; the risk is that a live service game needs a large, engaged player base to justify its running costs. Sony’s Concord (2024) was taken offline two weeks after launch when that base did not appear.

Engines and How Studios Choose

Three general-purpose engines dominate, alongside proprietary engines that large publishers build for themselves.

Engine	Languages	Cost (2026)	Known for
Godot 4	GDScript, C#, C++ via extensions	Free, open source, MIT license, no royalties ever	2D, rapid iteration, full source access, growing 3D
Unity	C#	Free Personal tier under 200,000 dollars annual revenue; paid tiers above	Mobile, 2D and 3D, the largest hiring pool (Hollow Knight, Among Us)
Unreal Engine 5	C++, Blueprints (visual scripting)	Free; 5 percent royalty on gross revenue after a product’s first 1 million dollars	High-end 3D (Fortnite, Black Myth: Wukong)
In-house	Varies	Owned by the publisher	Capcom’s RE Engine, EA’s Frostbite, Guerrilla’s Decima

Studios choose by asking practical questions. Which platforms do we ship on? What does our team already know, and who can we hire? What will licensing cost at the revenue we hope for? Do we need source access to fix engine bugs ourselves? CD Projekt announced in 2022 that its next Witcher would move from its own REDengine to Unreal Engine 5, and Halo Studios made the same move in 2024, both citing the cost of maintaining and hiring for a custom engine. Godot, meanwhile, has grown fastest among indies since Godot 4 arrived in 2023, because it costs nothing and cannot change its terms on you.

1.5 — Setting Up Your Studio 🛠️

This book uses Godot 4 because it is free in every sense, runs on almost any computer, and teaches concepts that transfer directly to Unity and Unreal.

Installing Godot 4

Download the standard build of Godot 4 for your operating system from the official site. There is no installer: it unzips to a single executable of roughly 100 megabytes that runs from a folder or a USB drive without administrator rights, on Windows, macOS or Linux. (A separate .NET build exists for C#; this book uses GDScript.)

Launch it and you land in the Project Manager. Click Create, give the project a name and an empty folder, and choose a renderer: Compatibility is the safest choice for older hardware and web export, Forward+ is for desktop 3D. Leave Version Control Metadata set to Git so Godot generates the .gitignore you will need shortly. Godot writes a project.godot file (the settings, in plain text) and an icon.svg, then opens the editor. The Scene dock shows the tree you are building, the Inspector shows the selected node’s properties, and the Node dock lists its signals, the events it can announce to other nodes.

Nodes and Scenes

Godot rests on two ideas. A node is a single-purpose building block: Sprite2D draws an image, CollisionShape2D defines a physical outline, Camera2D decides what the player sees, Timer counts down. There are hundreds of node types, each doing one thing well.

Nodes form a tree. A child inherits its parent’s position, rotation and scale, so a Sprite2D and a CollisionShape2D under a CharacterBody2D move with the body. A scene is a tree of nodes saved to disk as a .tscn file, short for text scene, and it can be a character, a level, a bullet or a menu. Scenes can be instanced inside other scenes, so Level.tscn might hold twenty instances of Coin.tscn; change the coin scene and every instance updates. Because .tscn files are plain text, version control can track exactly what changed:

[gd_scene format=3]

[node name="Player" type="CharacterBody2D"]

[node name="Sprite2D" type="Sprite2D" parent="."]

Press F5 to run the project from its main scene (set in Project Settings) and F6 to run only the scene you are editing.

Your First Script

Behavior comes from scripts attached to nodes. GDScript is Godot’s own language: indentation-based like Python, typed when you want it, and built around the engine’s callbacks. Right-click a node, choose Attach Script, and fill in the skeleton:

extends Node2D

func _ready() -> void:
    print("Studio is open.")

func _process(delta: float) -> void:
    rotation += 1.0 * delta   # one radian per second

extends names the node type the script controls. _ready() runs once when the node enters the scene tree. _process(delta) is the variable-timestep callback from section 1.2. Press F6 and the node spins at one radian per second regardless of frame rate, while “Studio is open.” appears in the Output panel.

Saving Work with Git

A project folder with no history is one accidental save from disaster. version control fixes this. Git records a snapshot, called a commit, whenever you ask; you can compare commits, roll back to any of them and, on a team, merge everyone’s changes. Hosting the repository on GitHub adds a free off-site backup.

Godot is unusually friendly to Git because almost everything in a project is text: project.godot, every .tscn, every .gd. The one folder you must not commit is .godot/, the editor’s local cache, which the generated .gitignore already excludes. A first repository takes three commands (a client such as GitHub Desktop does the same with buttons):

git init
git add .
git commit -m "Create project"

Describe each commit honestly (“Add player scene and movement script”); the log is a diary your future self will read.

Chapter 1 Activity: Dissect a Game 🔬

Pick one digital game you have played for at least ten hours and take it apart with the tools from this chapter. You will reuse this work in Chapter 2.

Part 1: Mechanics, Dynamics, Aesthetics

Write down eight mechanics as precisely as the developer would state them: exact numbers, timers, limits and costs where you can find them. Describe three dynamics that emerge from those mechanics and that you have seen players do, such as a strategy, a social behavior or an exploit. Name the two or three aesthetics from LeBlanc’s list the game is chasing, and close with the genre written as a bundle of mechanics rather than a label.

Part 2: The Loop Under Load

Play for fifteen minutes with a frame counter on (most PC launchers have one). Note the steadiest frame rate you see and the worst hitch. For each hitch, use the table in section 1.3 to make a specific diagnosis, CPU, GPU, pacing, network or input, with one sentence of evidence. Then compute the frame budget the game is targeting and list three things happening inside it every frame that you cannot see.

Part 3: The Studio and the Engine

Research the game’s studio: approximate team size, indie, AA or AAA, premium or live service, and which engine it runs on (credits, the studio’s site and engine showcase pages are reliable sources). Write a short argument for why that engine was a sensible choice given the platforms, genre and team, using the questions from section 1.4. If you cannot determine the engine, explain what evidence you looked for and what you would expect.

Part 4: Open Your Studio

Install Godot 4 and create a project named after the game you dissected. Build a scene with at least three nodes of different types, attach a script to one that uses delta, and run it with F6. Make an initial Git commit, then change something in the scene, commit again, and view the difference between the two commits in the .tscn file. Submit a screenshot of the running scene and your commit log.

Key Concepts Checklist

I can state a formal definition of a game
I can separate mechanics, dynamics and aesthetics with MDA
I can describe a genre as a bundle of mechanics
I can explain the three steps of the game loop
I can use delta time and choose between fixed and variable timesteps
I can compute a frame budget and explain what the CPU and GPU each do
I can diagnose at least four causes of “lag”
I can create a Godot 4 project, build a scene from nodes, attach a script and commit with Git