9.7 — Computer Systems: What Runs Your Game

60 frames per second means the machine has 16.67 milliseconds to run YOUR Update, the physics, and a million pixels. Today: the four organs of every computer — and why knowing them turns your tuning instincts into engineering. The specimen is your own project folder.

Break It Down~10 min

Your game runs at 60 frames per second in the lab and 25 on the school laptop — and "it is slow" is not one problem. It is four finite resources and one 16.67 ms deadline, and the work is finding out which of them ran out.

First, before anything else: cut that into parts small enough that you could look each one up on its own.

Name the four organs, and the one job each one doeswhat does this part do?Read: the four-organs table in this lesson's Concept Lab, and the Unit 9 systems overview
Turn a frame rate into a deadlinewhat does this part do?Read: the frame-budget paragraph in this lesson's Concept Lab, and the deltaTime lesson where the frame rate stopped being a constant
Work out which organ ran out, before you change anythingwhat does this part do?Read: the Profiler steps in this lesson's editor half, and the Update vs FixedUpdate row of the Unity + C# quick reference
Know what is in RAM and what is only on diskwhat does this part do?Read: the measured storage table in this lesson's Concept Lab, and 9.4 on what a scene file actually is
Say where in the frame a thing runswhat does this part do?Read: the pipeline list in this lesson's code half, and the lifecycle split you met in 1.3

The split is the answer to the ask. "It stutters on the other computer" is unanswerable; these five are five separate questions you can each go and measure. Four of them are about a resource running out — compute, pixels, memory, disk — and the fifth is about time. Notice what is not on the list: no new API, nothing to install, and no code to write. Every one of these is a number you read out of a window you already have open, which is exactly why this lesson has no walkthrough.

The test: could you answer this part by opening one window and reading one number? The Profiler answers the third, the Project window answers the fourth, and a stopwatch answers the second. A part that needs somebody else's hardware instead of your own is a part you have not finished splitting.

Your turn

Pick two of the parts above and say in one line what each one actually does.

Your answer

Your project folder holds 641,512 KiB of Unity import cache and 36,852 KiB of your own source. Which of those two would you hand to a classmate, and what would you tell them if they complained the download was huge?

Your answer

One sprite sheet in your art folder is 1632 pixels wide and 1536 tall, and its file on disk is 589 KB. Say, without multiplying, which of those two numbers the graphics card is holding — then multiply and check yourself.

Your answer

Name the one organ you would upgrade first for your own game, and the measurement that decided it rather than the price tag on the box.

Your answer

Concept Lab ~15 min

The four organs — and what your game asks of each:

Organ	Job	Your game's demand
CPU	Executes instructions — your C#	Every Update: input, Distance checks, cooldowns, and the scene search that runs on an E press
GPU	Draws pixels — massively parallel	The tilemaps, the 3,429 sub-sprites in your art folder, your camera view, 60 times a second
RAM	Working memory — fast, forgets at power-off	The loaded scene, every field, and every texture decoded out of its PNG
Storage (SSD/HDD)	Persistent — slow, remembers	The .unity files, the artwork, your whole project folder (9.4)

What your project actually costs. Open the folder you have been building in and these are numbers you can read yourself, not estimates:

Measured on the course project	Size	What it tells you
`Assets/` — your source: scripts, art, scenes, prefabs	36,852 KiB over 4,967 files	This part is yours, and it is the part a classmate actually needs.
`Library/` — Unity's import cache	641,512 KiB over 10,418 files	Seventeen times the source, and none of it is your work. Unity rebuilds it on the next machine, which is why it is not what you share.
Your nine scripts in `Assets/Scripts/`	277 lines across 9 files	Counted, this is the smallest thing in the project — a few pages of text beside the 23,336 KiB of artwork in `Assets/Artwork/`.
One sprite sheet: `Assets/Artwork/Platformer/Sliced/MainLev2.0.png`	589 KB on disk, 1632 × 1536 pixels	Its import settings say uncompressed, so the card holds 2,506,752 pixels at 4 bytes each — about 9.6 MB. Seventeen times the file.

The first table is measured with du -sk — run it on your own project folder and you will get your own numbers, because the cache grows every time you open the editor. The lesson is not the values; it is that they are finite and checkable.

The frame budget. 60 frames per second is not a speed, it is a deadline. 1000 milliseconds divided by 60 frames is 16.67 ms, and everything the machine does for one frame has to fit inside it. Ask for 30 fps and the deadline doubles to 33.33 ms, which is why half the frame rate is not half the work — it is twice the room. A machine 20% slower does not run 20% slower either: it either meets the deadline or misses it, and a missed deadline is a frame the player sees drop. Your deltaTime habits (1.5) exist because the frame rate is a NEGOTIATION with hardware, not a constant.

How one frame's 16.67 ms divides between the code, the physics and the draw is a MEASUREMENT, not a constant — it moves with the scene, the machine, and what the player is doing — and taking that measurement is what the Profiler is for. The code half below is the order those jobs run in, and why the order is a prediction rather than a list.

In the Editor ~20 min

Everything the Concept Lab priced is a number you can read out of a window you already have open. These six readings are the diagnosis this lesson exists for: which organ ran out, and how you know.

Window → Analysis → Profiler, and leave it attached while the game plays: one bar per frame, and the height of the bar is the 16.67 ms being spent. Profiler → CPU is where the bar is split into the bands that filled it, so your Update cost, the physics cost and the render cost are three bands on one bar.
Game view → press Play on a scene that is doing almost nothing, and read the frame time. On a simple scene most of a quiet frame is render. Then Scene view → let the turrets fire at once and watch the logic band jump: the spike is scheduled work, not a constant cost.
Hierarchy → drag the enemy prefab in and Ctrl+D until you have 200 of them, each running its own Update and a distance check to the player. Game view → read the frame rate fall, then Profiler → Hierarchy to see which method the milliseconds are being charged to.
Hierarchy → delete them, and spawn 200 large sprites instead — scaled up in the Scene view until they cover the camera. Game view → the frame drops again, and it drops differently: the cost is in draw calls rather than in logic, which is what the two bands on the same Profiler bar are there to tell apart.
Project window → Assets/_Scenes/Overworld, then Game view → Play. What RAM holds is the scene you loaded: eight tilemaps bounding 15,793 cells, of which the layer that actually stops you is 105 by 91 — 9,555 cells — and the rest are the cave and door alternates of the same level, kept in memory so that opening a door is a swap rather than a rebuild.
Hierarchy → the door's SceneSwitch from 5.3, then walk through it with the Profiler still open. The old scene UNLOADS — that is the hitch you sometimes see mid-door, and it is RAM being handed over — and the singleton survives it because DontDestroyOnLoad(gameObject) says this one is not scene-RAM any more.

In the Code ~15 min

The four stages above are the code half of this lesson: your C# occupies exactly one of them, and the API below is what decides which.

The frame pipeline, in order:

1. Input    → your GetAxis/GetKeyDown (Input System)
2. Update  → YOUR code runs (movement, cooldowns, AI ifs)
3. Physics → collision resolution, rigidbody integration
4. Render  → sprites sorted (7.2 layers!) and drawn

That order is not trivia — it is a prediction. It is why a sound played in Update arrives after that frame's physics, and it is why the turret's bullet is the clearest example in your own game. Turret_Projectile.prefab ships as a Transform, a Sprite Renderer and Projectile.cs and nothing else: no collider and no Rigidbody2D, so until 3.4 gave it a shape it was not in the simulation at all. Once you did, the hit arrives through OnTriggerEnter2D(Collider2D other) — and that is a physics callback, so a bullet born during one frame's Update cannot be tested against anything until a LATER frame's physics pass. Nothing is instant; everything is scheduled.

API	What it is	What you get	What it costs
`Update()`	The callback Unity runs once per rendered frame — the one every script you have written this year lives in.	Work that keeps pace with the frame, because the frame is what calls it.	Its cost is paid 60 times a second whether or not anything changed, so every check you add here is a per-frame check forever.
`FixedUpdate()`	The callback on the physics clock rather than the render clock — the clock `Time.fixedDeltaTime` measures.	A steady timestep, so a force applied here is not larger on a slow frame.	It does not run on every frame, so anything that has to look smooth — input, a cooldown, an animation — stutters if it lives here.
`Time.deltaTime`	The seconds the last frame took, from 1.5 — a measurement of the deadline being met.	A number that turns per-frame work into per-second work, which is why your movement does not change speed with the frame rate.	Nothing, except that it reports the past: it describes the frame that just finished, not the one you are in.

Architectural specification: which stage does this work belong in?

Name the stage each system you built runs in — movement from 1.4, the turret's cooldown from 3.3, the enemy's chase from 4.3, the jump from 6.1 — and the callback that puts it there.
The bullet's hit is reported in the physics stage of a LATER frame than the Update that spawned it. Name one thing in your own game that depends on that delay, and one bug that would appear if the delay were a frame longer.
Your frame rate is a negotiation with the hardware, not a constant. Which of the numbers in this lesson would change on a machine twice as fast — and which would not?

Socratic

Unity calls Update before physics and FixedUpdate on the physics clock. Why would physics need a FIXED timestep while your Update does not — and which of your systems (a cooldown counting Time.time vs. an AddForce() jump) would break if you moved it into the wrong one?

Your answer

Checkpoint — before moving on, you must be able to:

Name the four organs with your game's demand on each
Do the frame-budget arithmetic and say what a missed deadline is
Read the Profiler and identify CPU vs GPU saturation
Explain the frame pipeline order and a bug it predicts
Say what your project costs on disk and in memory, and why those two numbers differ
Explain volatile RAM vs persistent storage with your own coins
Break this question into parts small enough to look each one up on its own, and say in one line what each part does
Say which earlier lesson each part of it came from, and where you would reread it

Reference Docs

Need a deeper explanation? These pages cover the same concepts:

Unit 9: Data & Systems — computer systems in the CED
Unity + C# Quick Reference — Update vs FixedUpdate

Next: 9.8 — The Internet: Packets, Routing & DNS

Student name0/5 answered

Answers save on this device as you type. At the end of class, click Download and upload the file to the Canvas assignment.

I finished this lesson

Saved on this device only — the Dashboard tracks your progress.