How to Learn Unity with This Handbook

The big picture#

The handbook is two libraries that cover the same ground from two directions.

• TopicBased/ has 73 chapters, from this one to the capstone. Each chapter covers one subject (physics, UI, shaders, multiplayer) and merges what every relevant course teaches about it, removes the repetition, and fills the gaps none of them cover. The chapters are in learning order, and together they're the backbone: if you read only one library, read this one.
• CourseBased/ has 129 files, one for every course, book, channel or tutorial series in the source list. Each file follows that course's own arc (its projects, its order, its level), so you can "take" the course by reading it, with or without the videos.

The two are linked both ways. Every chapter ends with the course files that cover its subject, each with a line on that course's angle. Every course file links to the chapters that go deeper on what it teaches. You can start from either side and always find the other.

Both libraries are split into eight phases, P0 to P7. A phase is a stage of skill, and each one assumes the ones before it.

The middle phases aren't completely independent. Shaders (P5) use the maths from T06 · Game Maths: Vectors, Trigonometry, Matrices, Quaternions & Interpolation, and the mobile chapter (P6) assumes you know UI from P3. Each chapter lists its real prerequisites at the top, so you never have to guess.

How the handbook is organised#

Phases and what's in them#

P5 has far more course files than any other phase because the source list has a whole list of 50 entries just for VFX and shaders. The chapter count there (13) is what matters for your study plan; most of those 50 files are second angles on the same few chapters.

Topic chapters#

Every chapter has the same shape, so after two or three you'll know where to look:

1. Header card: the study time, the prerequisites, and what you'll be able to do afterwards.
2. The big picture: the mental model, usually with a diagram. If you read nothing else, read this.
3. Core sections, one per subtopic. Each explains the idea, shows a minimal example, then a realistic one, then the pitfalls, then any Unity 6 changes.
4. Guided build: a small original project that uses everything in the chapter, step by step, with all the code.
5. Going further: advanced techniques, performance, and how studios do it.
6. Common mistakes & debugging: what goes wrong, why, and the fix.
7. Exercises, graded from easy to challenge, with solutions folded away.
8. Quiz: ten questions that score themselves.
9. Cheat sheet: one screen of APIs, shortcuts and rules of thumb, for later.
10. Courses that cover this, and a glossary of the terms the chapter introduced.

A chapter is long, typically 8,000 to 14,000 words plus code. Don't read it in one sitting. The study-session section below shows how to split it.

Course files#

A course file starts with a course card (where the course lives, its rating in the source list, its level and length) and a verdict: who it suits, what it does well, where it's weak, and how current it is. Then comes the syllabus map: the course's own modules, in its own order, summarised in my words. After that the file teaches each module in writing, with original code and an original project in the same genre as the course's. It ends with upgrades (the modern Unity 6 version, better architecture, and what the course leaves out), a capstone challenge, a quiz and a cheat sheet.

Not every entry in the source list is a video course, so some files have a slightly different shape:

IDs, links and "planned" labels#

Every page has a short ID: T00 to T72 for chapters, C001 to C129 for course files. IDs never change, so they're the quickest way to refer to a page in your notes ("see T08, the raycast section"). That's why the chapters added after the plan was made, T54 to T72, have the highest numbers but sit inside their phases in the reading order: T54, the second 2D chapter, comes after T38.

The handbook is written over many sessions, and you'll be studying while later phases are still being written. When a page links to one that doesn't exist yet, the link shows as a dotted label instead of a real link. Hover over it (or long-press on a phone) and the tooltip tells you which writing session will produce it. Like T53 · Capstone: Planning and Building Your Own Complete Game in this sentence. On the next build after that page is written, every dotted label pointing at it becomes a normal link.

★ Core picks#

31 of the 129 course files are marked ★ core. They're the strongest project-based route through each phase. The chapters already teach everything; the core course files add the practice of building a bigger project from start to finish, which chapters can only do in miniature. If your time is short, read the chapters of a phase and at least its ★ files. Use the rest as second opinions when something doesn't click, or when you want a genre the core files don't cover.

Anatomy of a page#

Every page is one self-contained HTML file. It needs no internet connection and no server, so you can copy one to a phone, email it, or print it to PDF and it still works. Here's what the parts do.

Header card, contents and progress#

The header card at the top of each page gives the study time (an honest estimate including exercises, not just reading), the reading time (worked out from the word count, at 200 words a minute for prose and 12 lines a minute for code), the prerequisites and the outcomes. Read the outcomes before you start and again when you finish: if you can't do one of them, that's the section to go back to.

The contents sit in a column beside the text on a wide screen. On a phone they're behind the Contents button in the top bar, and Esc closes them. The section you're reading is highlighted as you scroll.

At the end of each section is an I've learned this checkbox. Tick it when you could explain that section to someone else without looking, not when you've merely read it. The ticks fill the progress bar in the contents and in the header card, and the home page adds them up per phase.

Callouts#

Boxes in the margin of the text flag a particular kind of information. There are seven, and each always means the same thing:

Code blocks and their badges#

Every code block has a caption with the file name, the language, and a Copy button. Some also carry a badge that tells you how far the code has been checked:

• Unity sandbox: the file is copied into the handbook's Unity project (_sandbox/) by the build, so Unity's own compiler checks it at each phase review. These are complete files you can drop into a project.
• .NET console: pure C# with no Unity in it. The build compiles it, runs it, and checks the output matches the block printed under it.
• legacy: an old API shown on purpose, always next to the modern version. Don't copy it into new code.
• No badge: a snippet, a terminal command or a config excerpt. Read it in context.

Some lines in a block may be highlighted. They're the lines the text around the block is talking about.

Exercises, quizzes and cheat sheets#

Exercises come in four levels: easy (do it to check you followed), medium (apply the idea in a new situation), hard (combine it with earlier chapters) and challenge (open-ended, often a small project). Solutions are folded. Some exercises also have a separate Hint fold, so you can get a nudge without seeing the answer.

The quiz at the end of each page scores itself. Pick an answer and it tells you right away whether you're right and why. Reset quiz clears it so you can take it again in a week (and you should; see spacing below).

The cheat sheet is for later. It's no use on first reading, but very useful a month later when you remember that a thing exists and not what it's called.

The home page#

The home page (Handbook home) lists both libraries side by side. You can filter by library, phase, type and ★ core, and the search box looks through the full text of every written page, not just the titles. Press / anywhere on the home page to jump to search. The progress panel shows how many sections you've ticked in each phase, and has the export, import and clear buttons for your progress.

How a skill like Unity is actually learned#

Unity is a skill, not a body of facts. Knowing that Rigidbody exists is easy. Being able to sit down with an empty project and make a ball roll the way you want, then find out why it tunnels through walls at high speed, is the skill. Cognitive science has studied how skills and knowledge stick for over a century, and a few findings are solid enough to build a study method on.

Watching and re-reading feel like learning, but aren't#

When you follow a tutorial, everything makes sense. The instructor's code compiles, the next step is obvious, and you feel you're learning fast. That feeling is the problem. Recognising something when you see it is much easier than producing it from nothing, and the brain mistakes the first for the second. Researchers call this an illusion of competence: the material feels familiar, so you assume you know it.

A large review of study techniques by Dunlosky and colleagues (2013) rated re-reading and highlighting as having low usefulness, despite being what most students do. Following a video step by step is the coding equivalent of re-reading: you're recognising, not producing. The techniques that review rated highest were practice testing and spreading practice out over time.

Retrieval practice: recall before you re-read#

Pulling something out of memory strengthens it far more than putting it in again. In a well-known study by Roediger and Karpicke (2006), students who read a text once and then tested themselves on it remembered much more a week later than students who spent the same time re-reading it, even though the re-readers felt more confident. This is the testing effect, and it has been replicated many times since.

For you, this means:

• Before re-reading a section, close it and try to write down its main points, or sketch its diagram from memory. Then check.
• Take the quiz before reading a chapter as well as after. Getting questions wrong before you've learned the material is not wasted effort: it primes you for the answers.
• When an exercise says "write a script that…", write it without scrolling back up. Only look when you're truly stuck, and then look for the one thing you need, not the whole answer.

Spacing: the same hours, spread out#

Ten hours spread over two weeks beats ten hours in one weekend, by a wide margin, for anything you want to remember a month later. This spacing effect is one of the oldest results in psychology, going back to Ebbinghaus in the 1880s, and a large meta-analysis by Cepeda and colleagues (2006) confirmed it across hundreds of studies. The best gap grows with how long you want to remember: revisiting after a day, then a few days, then a couple of weeks works well.

In practice: the day after you finish a chapter, retake its quiz. A few days later, rebuild the smallest example from the chapter without looking. Two weeks later, read its cheat sheet and see what you've forgotten. Each review takes ten or fifteen minutes. The study plan you'll write in the guided build schedules them for you.

Interleaving: mix things up once you know the basics#

When you practise one kind of problem over and over (ten raycast exercises in a row), you get good at that block of exercises, but you never practise the hard part: working out which tool a problem needs. Mixing different kinds of problem, called interleaving, feels slower and harder, but it leads to better results on tests that mix problems, which is what real projects are.

The handbook does some of this for you: the hard and challenge exercises deliberately pull in earlier chapters. You can do more by mixing your review: when you revisit old chapters, pick two or three at random instead of going in order.

Worked examples first, then fade them out#

Beginners learn faster from studying a worked solution than from solving the same problem cold. This worked-example effect comes from John Sweller's work on cognitive load: a novice solving a problem from scratch spends all their attention searching for a way forward and has none left to notice the pattern. But the effect reverses as you get better. Once you know the basics, worked examples hold you back and solving problems yourself teaches more. This reversal is called the expertise reversal effect.

That's why chapters go from fully worked examples (the minimal and realistic examples in each core section), to a guided build where you type each step, to exercises where you write the code, to challenges with no code at all. And it's why tutorials are a fine way to start a subject and a poor way to keep going. A tutorial is a worked example that never fades.

Practise at the edge of what you can do#

Building the fifth platformer that's like your first four feels productive, but you're practising what you already know. Skill grows fastest when the task is just beyond what you can do comfortably, you get quick feedback on what went wrong, and you try again. Anders Ericsson called this deliberate practice. You don't need a coach for it. You need tasks that are slightly too hard, and a way of finding out how you did: the compiler, the Console, the Profiler, a playtester, the solution to the exercise.

Small steps, and one new thing at a time#

Working memory holds only a few new things at once. A beginner's first Unity session asks it to hold the Editor's windows, C# syntax, the idea of components, and vector maths all together, which is why it feels overwhelming. That doesn't mean you're bad at this. It means too many new things arrived at once.

Two habits help. First, change one thing at a time: add one feature, press Play, check it works, then add the next. When something breaks, you know exactly what caused it. Second, move things out of your head: keep the cheat sheet open, write notes, and let the IDE complete names for you. Memory you don't spend on remembering an API name is memory you can spend on the problem.

Choose your route#

You don't have to read all 202 pages, and almost nobody should. Pick a route by what you want to be able to do, then adjust it as you learn what you enjoy. Every route starts with P0 and the parts of P1 it needs, because nothing else works without them.

A route isn't a cage. If you're on route C and a combat game catches your interest, read T25 · Combat & Game Feel: Hitboxes, Feedback, Juice & Camera Work. The prerequisites at the top of each chapter will tell you if you've skipped something it needs.

Testing out of a chapter#

If you already know a subject (you've written C# for years, say), you don't need to read its chapter from the top. Instead:

1. Take the chapter's quiz cold. If you score 8 or more out of 10, go on to step 2. Below that, read the chapter.
2. Do its two hardest exercises without looking at the text. If both work, read only the big picture, the Unity 6 notes and the common mistakes, then move on.
3. If either exercise beats you, read the sections it needed. That's usually a small part of the chapter.

How long it takes#

Honest numbers help you plan, and they stop you thinking you're slow when you're normal. These are estimates, worked out from the length of the material and the time the exercises and builds usually take. Your own pace will vary.

Five steady hours every week will take you further than twenty hours one week and none for the next three. Spacing works in your favour when the hours are spread out.

A study session that works#

Here's a 90-minute session built on the ideas above. Shorten each block in proportion if you have less time, but keep all of them. The first and last blocks are the ones people drop, and they're the ones that make the middle stick.

1. Recall (10 min). Before opening anything, write down from memory what you covered last session: the main ideas, an API or two, the thing that went wrong. Then glance at your journal or the page to check. If it's a review day, this block is the quiz or cheat sheet of an older chapter instead.
2. Read and type (35 min). Read one or two core sections. Type every code example yourself, in the sandbox or a scratch project, and run it. Don't paste.
3. Break, change, build (30 min). Break the example on purpose and read the error. Change one thing and predict what will happen before you press Play. Then do the section's exercises.
4. Quiz and journal (10 min). Take any quiz questions on what you covered, and write three or four lines in your journal: what you learned, what confused you, what you want to try.
5. Plan the next session (5 min). Write the first thing you'll do next time. Starting is the hardest part of any session, so make it easy for yourself.

Type the code, don't paste it#

Pasting is faster, and for a two-hundred-line file you've already understood, it's fine. While you're learning, though, typing does three things pasting can't. It makes you read every character, so you notice the parts you'd skim. It produces typos, and fixing them is practice at reading errors. And it trains your fingers in the shape of the language, so [SerializeField] float speed = 5f; eventually comes out without thought.

Break it on purpose#

Errors are information, and the best time to meet one is when you know exactly what caused it. After an example works, try:

• deleting a semicolon, a brace or a using line, and reading the compiler error;
• leaving a field unassigned in the Inspector, and reading the runtime error;
• renaming a method Unity calls (Update to update), and noticing that nothing happens, with no error at all;
• setting a value to zero, a negative number or something huge, and watching what the game does.

Each of these is an error you'll meet for real later, in a project where you don't know the cause. Meeting it first in a controlled setting turns a frightening hour into a two-minute fix.

Keep a dev journal#

A journal is a plain text file (or a notebook) with a short dated entry after each session. It costs five minutes and does three jobs. It's your recall prompt for the start of the next session. It's a record of what you got stuck on and how you got out, which you'll want again. And months later, it shows you how far you've come, which matters on the days you feel you're getting nowhere. The guided build below gives you a template.

Getting unstuck#

You'll get stuck many times. Everyone does, at every level: professionals just have a faster routine for getting out. Here's a routine that works, in order. Most problems are solved by step 2.

1 · Read the whole error#

Unity's Console tells you a surprising amount, if you read all of it. A compile error looks like this:

Assets/Scripts/Coin.cs(14,13): error CS0103: The name 'scroe' does not exist in the current context

That one line gives you the file (Coin.cs), the line and column (14,13), a code you can search for (CS0103), and the message. Here, a variable name is misspelt. Double-click the error in the Console and your IDE opens at that exact spot.

A runtime error, one that happens while the game runs, adds a stack trace: the chain of method calls that led to it, most recent first.

NullReferenceException: Object reference not set to an instance of an object
Coin.OnTriggerEnter (UnityEngine.Collider other) (at Assets/Scripts/Coin.cs:18)

Read it as: "On line 18 of Coin.cs, inside OnTriggerEnter, the code used something that was null." Now look at line 18 and ask which reference on it could be null:

using UnityEngine;

public class Coin : MonoBehaviour
{
    [SerializeField] int value = 1;
    [SerializeField] ScoreBoard scoreBoard;   // forgot to drag it in, in the Inspector

    int score;

    void Start()
    {
        score = 0;
    }

    void OnTriggerEnter(Collider other)
    {
        Destroy(gameObject);
        scoreBoard.Add(value);                // scoreBoard is null here
    }
}

The answer is scoreBoard, which was never assigned in the Inspector. Almost every NullReferenceException in a beginner project is one of three things: a field not assigned in the Inspector, a GetComponent that found nothing, or using something before the method that sets it has run. T05 · Scripting in Unity: Lifecycle, Serialization, Coroutines & Awaitable covers all three.

2 · Give it twenty minutes, then change approach#

Struggling with a problem is how you learn, up to a point. After that you're just tired. A good rule is: twenty focused minutes on your own, trying things and reading the error, then move to the next step. If you've been stuck for an hour on the same thing, something in your approach has to change, not just your effort.

During those twenty minutes, say the problem out loud or write it down: what you expected, what happened instead, and what you've ruled out. Programmers call this rubber-duck debugging, after the idea of explaining your code line by line to a rubber duck on your desk. It works surprisingly often, because putting the problem into words forces you to notice the step you'd been assuming.

3 · Shrink it to a minimal reproduction#

If the bug is buried in a big scene, make a new empty scene with only the objects and the script needed to show it. Then remove things one at a time until removing anything more makes the bug disappear. What's left is a minimal reproduction. Very often, building it shows you the cause. If it doesn't, you now have exactly what you need to ask someone else.

4 · Search well#

• Search the exact error text, in quotes, with "Unity" in front. Take out your own names (scroe, Coin.cs) first.
• Check the date and version of every answer you find. A 2016 answer may use an API that's gone (see the next section).
• Search the Scripting API for the class you're using and read the whole page, especially the description and the example. Many "bugs" are documented behaviour.

5 · Ask a question people can answer#

When you ask on a forum or a Discord server, the speed and quality of the help you get depends almost entirely on the question. A good question includes:

1. What you're trying to do, in one sentence ("make the player jump only when grounded").
2. What you expected and what happened instead ("expected one jump; the player jumps again in mid-air").
3. The exact error text, copied, not retyped or summarised.
4. The smallest code that shows the problem, as text in a code block, not a screenshot of code.
5. Your Unity version and any relevant package versions.
6. What you've already tried, so nobody suggests it again.

Unity's official forum is Unity Discussions. Many of the courses in CourseBased/ have their own community servers too; the course files say where.

Using AI assistants without losing the learning#

AI coding assistants are very good at producing Unity code, which is exactly why they can stop you from learning it. If the assistant writes the script, you've practised asking, not scripting. But used well, they're an excellent tutor. Some rules that keep the learning on your side:

• Ask for explanations, not answers. "Why does my raycast never hit anything?" teaches you more than "write me a raycast". Better still: "Don't give me code. Give me three possible causes and how to check each one."
• Say your version. Start with "I'm using Unity 6.3 LTS with URP and the Input System package". Assistants were trained on years of old tutorials and often produce pre-Unity 6 code (see the next section).
• Check every API name against the Scripting API. Assistants sometimes invent methods that sound right but don't exist.
• Type what you keep, rather than pasting it, and make sure you can explain every line.
• Use it to quiz you. "Ask me five questions about Rigidbody interpolation, one at a time, and tell me what I got wrong" is retrieval practice on demand.

Reading Unity's own documentation#

The handbook explains, but Unity's documentation is the final word on what an API does in your exact version. Learning to read it quickly is a skill in itself, and every chapter links into it.

Always check the version#

Every Manual and Scripting API page is written for one version of Unity, shown in the version picker at the top of the page. Search engines often land you on an old version or the newest beta. Before trusting a page, check that it says 6000.3 (Unity 6.3), the handbook's baseline. For a package, check that the version in the address matches the one in your project's Package Manager.

How to read a Scripting API page#

Take Rigidbody.AddForce as an example. Its page has, in order:

1. The signature(s): the method's declaration, and its overloads (other versions with different parameters). This tells you the types to pass and what you get back; here void, nothing:

   public void AddForce(Vector3 force, ForceMode mode = ForceMode.Force);

2. Parameters: what each argument means, including the units. Here mode decides whether the force is applied as a continuous force, an impulse, an acceleration or a velocity change.
3. Description: what it does and, more importantly, the conditions: how each force mode treats the vector, which modes take the body's mass into account, and when the call has no effect at all. Most surprises are explained here.
4. Example: a short script. Read it, but write your own version rather than copying it, since the examples often take shortcuts.

Two more things to look for: an Obsolete warning at the top, which means the API is on its way out and names its replacement; and the inherited members further down, which list what the class gets from its parents (Component, Object).

Old tutorials and Unity 6#

Unity has been around since 2005, and the internet is full of tutorials, forum answers and videos for versions that are long gone. Much of that material is still excellent, but its code may not compile, may compile with warnings, or may use a system Unity has since replaced. The handbook is written for Unity 6.3 LTS (editor version 6000.3.27f2), and every chapter has Unity 6 notes wherever an older course does things differently.

How Unity releases versions#

Since Unity 6, version numbers start with 6000 (Unity 6), then the minor version, then the patch: 6000.3.27f2 is Unity 6.3, patch 27. The letter after the patch says what stage the release is at: a for alpha, b for beta, f for final. The last number is a rebuild of that patch.

• LTS (long-term support) releases are the stable ones. They get bug fixes and no new features for about two years. Unity 6.3 is the current LTS, supported until December 2027. This is what studios ship games on, and what the handbook uses.
• Supported Update releases (such as Unity 6.6, from September 2026) bring new features between LTS releases and are supported for a shorter time. They're fine for learning, and a good way to try new features, but not what you'd start a long project on.
• Beta and alpha releases (Unity 6.7 beta and Unity 7.0 alpha, as of this writing) are previews. Don't use them for anything you care about.

What changed, in the code you'll meet most#

Here are the changes you'll run into most often in older tutorials, with what to use instead. You don't need to understand them all yet. Come back to this table when an old tutorial's code won't compile.

Using the course files#

There are three good ways to use a course file, depending on whether you have the course.

• Instead of the course. Read the file's lessons in order and build its project. The project is original: same genre and same skills as the course's, but its own design and code, written for Unity 6. You don't need the videos.
• Alongside the course. Watch a module, then read the file's lesson for that module. Pay most attention to the Upgrades and the Unity 6 notes, which fix what has aged in the video, and to the exercises, which the video probably doesn't have.
• Before deciding to buy. Read the verdict and the syllabus map, which tell you who the course suits, what it does well and where it's weak, so you can decide whether it's worth your money and time.

What the files can and can't be#

The handbook is honest about how it's made, and you should know too:

• No video is transcribed and nothing is copied. Each course file is built from the course's public outline (its curriculum page, official description and free previews), plus original lessons, code and projects that teach the same skills. The order and depth follow the course; the teaching is the handbook's own. The real course is always linked, so you know where it lives.
• Code is checked, but not every line by Unity yet. Pure C# is compiled and run during writing. Unity code is checked against the Scripting API and then compiled in the sandbox project at each phase review. If you find a sample that doesn't compile, that's a bug worth reporting.
• Ratings are a snapshot from the source list in October 2026, and aren't re-checked.
• Where something couldn't be verified, the page says so, rather than stating it as fact.

Guided build: your personal study plan#

Every chapter has a guided build, a small project that uses everything in it. This chapter's project isn't a game. It's the plan you'll study by, and the journal you'll keep while you do. It takes about thirty minutes, and it's the difference between "I'm learning Unity" and knowing what you'll do on Tuesday evening.

You'll make two plain text files. Keep them in a folder of your own, outside the handbook: once T01 · Setting Up: Unity 6, Hub, IDE, Packages & Version Control has you set up with Git, put them in a repository so they're backed up and versioned like everything else you make.

Step 1 · Write your goal as something you could ship#

"Learn Unity" is not a goal you can finish. "Release a small 2D platformer with three levels on itch.io by the end of March" is. A good goal names a thing (a game, a tool, an effect reel, a job application), a size and a date. It can change as you learn; that's fine. Having one at all is what matters, because it decides which chapters are worth your time.

If you don't know yet what you want to make, use this as your first goal: "Finish P1 and build one small complete game from the guided build in T10 · Your First Complete Game Loop: States, Scenes, UI, Audio & Builds, with a change of my own, by [date]."

Step 2 · Count the hours you really have#

Look at an ordinary week and write down the times you could actually study: "Tuesday and Thursday 19:30–21:00, Saturday 10:00–12:00". Be honest. Everyone overestimates. A plan built on hours you don't have fails in the second week and makes you feel you've failed, when only the plan did. It's better to plan four hours and do five than to plan ten and do three.

Step 3 · Pick a route and estimate the time#

Choose the route from the table above that's closest to your goal, and write down its chapters. Use the time table to estimate how many weeks the first stage will take at your weekly hours. If the date in your goal is impossible, move the date or shrink the goal now, rather than finding out in three months.

Step 4 · Turn it into a schedule with reviews built in#

Plan new material for most sessions, and put review sessions in the calendar too, otherwise they never happen. A simple rule: when you finish a chapter, schedule a short review of it one day later, a week later, and a month later. Each review is the first ten minutes of a normal session (quiz, cheat sheet, or rebuilding the smallest example from memory), so it doesn't cost you a whole session.

Here's a template for the plan file. Copy it, then fill it in.

# My Unity study plan

## Goal
Release a small 2D platformer (3 levels, menu, sound) on itch.io by 2027-03-31.

## Weekly hours
Tue 19:30–21:00 · Thu 19:30–21:00 · Sat 10:00–12:00   (= 5 h/week)

## Route
A · Complete beginner → first finished game
2D variant: T00, T01, T02, T03, T04, T05, T06, T07, T09, T10
Core course files: C001, C009, C012

## First stage (P0 + P1 chapters): estimate 60–90 h → about 14–18 weeks at 5 h/week
Target: finish T10 by 2027-02-28

## Reviews (fill in as you finish chapters)
| Chapter | Finished   | +1 day     | +1 week    | +1 month   |
|---------|------------|------------|------------|------------|
| T00     | 2026-11-03 | 2026-11-04 | 2026-11-10 | 2026-12-03 |
| T01     |            |            |            |            |

## Check-ins (every 4 weeks)
- 2026-11-28: on schedule? still the right goal? what should change?

Step 5 · Start the dev journal#

Make a second file, journal.md, and write your first entry now. Keep each entry short: if it takes more than five minutes, it won't survive a busy week.

# Dev journal

## 2026-11-03 · T00 (how to learn) · 1 h 20
Learned: recall before re-reading; spacing reviews; type, don't paste.
Stuck on: nothing yet.
Surprised by: how little re-reading actually helps.
Next time, start with: T01, install Unity Hub and the 6.3 LTS editor.

## 2026-11-05 · T01 (setup) · 1 h 30
Learned: .meta files hold the GUIDs, so never move assets in Explorer.
Stuck on: VS Code didn't autocomplete Unity types.
How I got out: set External Script Editor, then Regenerate project files.
Next time, start with: the Git section, first commit.

The most valuable lines are Stuck on and How I got out. Six months from now you'll meet the same problem in a different project, and your own journal is the fastest search engine you have.

Step 6 · Track skills, not pages#

At the bottom of the plan, keep a list of the outcomes from each chapter's header card, and mark each one only when you can do it without the page. Pages read is a poor measure of progress; outcomes you can perform is a good one. When an outcome stays unmarked after you've finished a chapter, that's exactly what your next review should target.

## Skills (mark [x] only when you can do it without looking)
### T00
- [x] Choose a study route that fits my goal and hours
- [x] Run a study session: recall, read and type, break and build, quiz, plan
- [ ] Spot pre-Unity 6 code and name the Unity 6 replacement   ← review this

Step 7 · Pick your first small project now#

Decide now what you'll build at the end of P1, even though you can't build it yet. Having a project in mind changes how you read: every chapter becomes "how would I use this in my game?", which is exactly the kind of thinking that makes knowledge stick.

Keep it small. A first project should have one core mechanic, fit on one screen or in one short level, and be finishable in about twenty hours. Good examples: a one-screen arcade game where you dodge falling objects; a ball-rolling game with five short levels; a top-down game where you collect ten things before a timer runs out. Bad examples: an open-world RPG, an MMO, "like Minecraft but…". Those come later, if you still want them, built on several small finished games.

Step 8 · Put the first check-in in your calendar#

Every four weeks, spend fifteen minutes on the plan: Are you on schedule? Is the goal still right? Which outcomes keep slipping? Change the plan rather than abandon it. Plans that get adjusted survive; plans that are only judged don't.

That's the build. You now have a goal, a schedule with reviews in it, a journal with one entry, a skills tracker, and a first project in mind. Check that you can answer these from your files without thinking: What do I study next session? When is my next review? What am I building at the end of P1?

Going further#

Game jams#

A game jam is an event where you make a game in a short, fixed time (usually 48 to 72 hours, sometimes a week or a month) around a theme announced at the start. Jams are the best training there is for finishing, because the deadline forces you to cut scope. Well-known ones include Ludum Dare, the Global Game Jam (held in January at local sites worldwide), and the GMTK Game Jam, plus hundreds hosted on itch.io every month. Once you're through T10 · Your First Complete Game Loop: States, Scenes, UI, Audio & Builds, enter one. Your jam game will be rough, and that's the point: you'll have shipped something, and you'll know exactly which chapter to read next.

Study games, not just tutorials#

When you play a game you like, play it once for fun and then once as a developer. Pick one small thing and work out how it's built: how far the character moves per button press, how long the jump lasts, what happens on screen in the half second after you're hit, how the camera follows. Write it down, then try to rebuild just that one thing in a scratch project. This trains your eye for exactly what makes games feel good, which tutorials rarely teach. T25 · Combat & Game Feel: Hitboxes, Feedback, Juice & Camera Work and T28 · Game Design Fundamentals: Loops, MDA, Lenses, Balancing & Playtesting give you the vocabulary.

Teach what you learn#

Explaining something is a strong form of retrieval practice, and it finds the gaps in your understanding very quickly. Write a short post about something you figured out, answer a beginner's question on a forum, or explain a chapter to a friend who doesn't know Unity. If you can't explain it simply, that tells you which section to go back to.

Build your portfolio from day one#

If you might want a job in games one day, keep everything you build, in Git, with a short note on what you made and what you learned. A portfolio doesn't start when you feel ready; it's the trail of finished small things you leave behind while you learn. T51 · Careers, Portfolio & How the Games Industry Works covers what studios look for. For now, make a habit of recording a short clip or screenshot of each thing you finish.

How studios onboard new developers#

When a studio hires a junior developer, nobody gives them a 40-hour course. They give them a small, real task in the real project, a more experienced person to ask, and code review on everything they submit. That's deliberate practice with feedback, and you can copy most of it: work on real small projects, find a study partner or community to review your work, and read other people's code, such as the sample projects on Unity Learn and the handbook's own guided builds, as seriously as you write your own.

Common mistakes & how to recover#

These are the patterns that stop people learning Unity. Each comes with the symptom, so you can recognise it in yourself, and the fix.

• Tutorial hell. Symptom: you've finished many tutorials, but freeze in front of an empty project. Why: tutorials are worked examples that never fade, so you practised following, not building. Fix: for every tutorial or guided build you finish, make one change of your own that the tutorial didn't cover, then build one tiny thing from scratch that uses the same idea.
• Skipping the exercises. Symptom: chapters feel clear while you read them and gone a week later. Why: reading is recognition, exercises are production. Fix: do at least the easy and medium exercises of every section before ticking "I've learned this".
• Copy-pasting code. Symptom: your projects work, but you can't explain why, and small changes break them. Fix: type it, then explain each line to yourself in a comment. Delete the comments once you can.
• A first project that's far too big. Symptom: months in, the dream game is a character that walks around an empty level. Why: scope grows faster than skill. Fix: park the dream game in a notes file, and finish three small games first. The dream game will be better for it.
• Learning from out-of-date material. Symptom: code from a tutorial gives obsolete warnings, or won't compile at all. Fix: check the date and Unity version of every source, and use the Unity 6 table in this chapter to translate.
• Binge and quit. Symptom: a twelve-hour weekend, then three weeks of nothing, then starting again from the beginning. Fix: fewer hours, more often. Put sessions in the calendar like appointments, and make the next session's first step tiny.
• Perfectionism. Symptom: rewriting the same player controller for the fifth time instead of moving on. Fix: give each feature a time limit. "Good enough for now" with a note on what to improve beats perfect and unfinished.
• No version control. Symptom: a change breaks everything and there's no way back, or a project is lost with a disk. Fix: T01 · Setting Up: Unity 6, Hub, IDE, Packages & Version Control sets up Git. From then on, commit at the end of every session.
• Comparing yourself to others. Symptom: someone online made a beautiful game in their first month, and you feel slow. Why: you're seeing their best result, not their hours or their background. Fix: compare yourself with your journal from a month ago, never with someone else's highlight reel.
• Studying without a goal. Symptom: reading chapters in order with no idea why, and losing interest by P2. Fix: write the goal from step 1 of the guided build, and let it choose your route.

Exercises#

using UnityEngine;
using UnityEngine.UI;

public class OldPlayer : MonoBehaviour
{
    public Text scoreText;
    Rigidbody body;
    GameManager manager;

    void Start()
    {
        body = GetComponent<Rigidbody>();
        manager = FindObjectOfType<GameManager>();
    }

    void Update()
    {
        float x = Input.GetAxis("Horizontal");
        body.velocity = new Vector3(x * 5f, body.velocity.y, 0f);

        if (Input.GetKeyDown(KeyCode.R))
            Application.LoadLevel(0);
    }
}

using TMPro;
using UnityEngine;
using UnityEngine.InputSystem;
using UnityEngine.SceneManagement;

public class Player : MonoBehaviour
{
    [SerializeField] TextMeshProUGUI scoreText;
    [SerializeField] GameManager manager;          // assigned in the Inspector, not searched for
    [SerializeField] InputActionReference move;
    [SerializeField] InputActionReference restart;
    [SerializeField] float speed = 5f;

    Rigidbody body;
    float moveX;

    void Awake() => body = GetComponent<Rigidbody>();

    void OnEnable()
    {
        move.action.Enable();
        restart.action.Enable();
    }

    void Update()
    {
        moveX = move.action.ReadValue<Vector2>().x;   // read input every frame
        if (restart.action.WasPressedThisFrame())
            SceneManager.LoadScene(0);
    }

    void FixedUpdate()
    {
        // apply it on the physics step
        body.linearVelocity = new Vector3(moveX * speed, body.linearVelocity.y, 0f);
    }
}

NullReferenceException: Object reference not set to an instance of an object
EnemySpawner.SpawnWave () (at Assets/Scripts/EnemySpawner.cs:42)
EnemySpawner.Update () (at Assets/Scripts/EnemySpawner.cs:27)

Check yourself#

Cheat sheet#

Courses that cover this#

No single course in the source list covers this chapter; it is original to the handbook.

Glossary#

Phase

One of the eight stages (P0 to P7) the handbook is split into. Each assumes the ones before it, except the four middle phases, which mostly stand alone.

Topic chapter

A page in TopicBased/ (T00–T72) that teaches one subject, merged from every course that covers it.

Course file

A page in CourseBased/ (C001–C129) that follows one course's own order and projects, in writing.

★ Core pick

One of the 31 course files marked as the strongest project-based route through its phase.

Planned label

A dotted cross-reference to a page that isn't written yet. Its tooltip names the session that writes it.

Illusion of competence

The feeling of knowing something because it looks familiar, when you couldn't yet produce it yourself.

Retrieval practice

Recalling something from memory (a quiz, writing it out, rebuilding it) to strengthen it. Also called the testing effect.

Spacing

Spreading study and review over time instead of massing it into one session. Remembered much longer for the same total hours.

Interleaving

Mixing different kinds of problem in one practice session, so you practise choosing the right tool as well as using it.

Worked example

A fully solved problem you study before solving similar ones yourself. Best for beginners; less useful as you improve (the expertise reversal effect).

Deliberate practice

Practising tasks just beyond what you can do comfortably, with quick feedback and repeated attempts.

Tutorial hell

Being able to follow tutorials but not build anything without one. The way out is changing and making, not more tutorials.

Stack trace

The list of method calls that led to a runtime error, most recent first, with file and line numbers.

Minimal reproduction

The smallest project or scene that still shows a bug. Building one often reveals the cause.

LTS

Long-term support: a Unity release that gets bug fixes, not new features, for about two years. Unity 6.3 is the current LTS and the handbook's baseline.

Dev journal

A short dated note after each session: what you learned, where you got stuck, how you got out, and what to do next.