🧭

Can You Build From Scratch?

Eight scenarios that don't have a tutorial. Each one tests how you'd actually think about a real problem — planning, decomposing, debugging, deciding what to cut. Following step-by-step instructions all term doesn't train these skills. This quiz finds out which ones you've still got gaps in.

How to use this honestly No tutorial would help you with these. Don't look anything up. Pick the answer you'd actually choose on a Monday morning with a blank Unity scene in front of you and no AI assistant. The point is to find your weak spots so you know what to practise — not to score 8/8.

Question 1 of 8

Your first hour on a new project

Skill: Planning

You've been assigned to build a simple top-down shooter as a 2-week solo project. You open Unity to a blank scene. What's your best first step?

Pick the option you'd actually do

A.Search the Asset Store for a shooter template that matches the brief, then customise it to fit.
B.Write down the smallest version that would still count as "a top-down shooter" — and build only that today.
C.Set up the project's folder structure, import a character asset, configure the camera, then create a tilemap for the floor and walls before any coding begins.
D.Open last week's tutorial project and modify it into the new game.

The Reasoning

B is correct. The single biggest predictor of finishing a solo project is whether you defined "the smallest playable version" before opening Unity. A top-down shooter at its minimum is: a thing you control that moves, an enemy that exists, and a way to make the enemy go away. That's it. Build that today.

C is the trap most students fall into — it feels productive because you're configuring lots of things, but you've spent the day on infrastructure for a game that doesn't exist yet. By the time you start the gameplay code, you've burned 30% of your budget on a folder structure.

A delays the problem; you'll spend the next week fighting someone else's architecture. D guarantees your new game looks like your old one.

PrincipleScope before structure. Always.

Question 2 of 8

Breaking down a behaviour

Skill: Decomposition

You need an enemy that wanders, spots the player from a distance, then chases until in melee range. You've never built this exact thing before. Where do you start coding?

Where would you actually start?

A.Use a state machine pattern with three states from the start — you'll need it anyway.
B.Find a free enemy AI script on the Asset Store and adapt it by reading through its existing methods and removing what doesn't apply to your game.
C.Write the full Enemy class with all three behaviours, then test the whole thing once it compiles.
D.Build wander first. Get it working in the scene before adding anything else.

The Reasoning

D is correct. The three behaviours are independent. Build them one at a time, and you always have a working enemy. Build them all at once (C), and the first thing you discover is a bug — but it could be in any of the three systems, in their interactions, or in your assumptions about Unity. You can't isolate it.

A is the "sounds professional" trap. State machines are useful, but committing to one before you understand the problem locks in a structure that often doesn't fit. Build the behaviours first; if they end up looking like states, then refactor into a state machine.

B trades one unknown (your enemy code) for two (your enemy code + someone else's enemy code, which you also have to understand).

PrincipleOne behaviour at a time, always with a visible working result before adding the next.

Question 3 of 8

Reading an error

Skill: Diagnosis

The Console shows: NullReferenceException on the line health.TakeDamage(10);. The script compiled fine. What's the most likely cause?

First place to look

A.The health reference is null — most likely an Inspector field is unassigned, or a GetComponent call returned null.
B.The TakeDamage method has an internal bug that throws when health drops below zero.
C.A race condition where two scripts call TakeDamage on the same frame.
D.Unity's physics system raised the exception because the collision happened before FixedUpdate ran.

The Reasoning

A is correct. The error literally says "Null Reference" — something on the left of the dot is null. Either health itself, or whatever's behind it. The fix is to figure out which, not to invent new theories.

Beginners reach for sophisticated explanations (B, C, D) because nullref feels too simple. But 95% of the time it really is just "I forgot to drag this into the Inspector slot" or "GetComponent didn't find what I assumed was there." Always check the simple cause first.

PrincipleRead the error literally before inventing theories. The error usually means exactly what it says.

Question 4 of 8

45 minutes on the same bug

Skill: When to step back

You've been trying to fix the same bug for 45 minutes. You've reread the code three times. You're tired and frustrated. What's the best next move?

Pick what you'd actually do

A.Add Debug.Log statements throughout the function to trace which lines execute and what every variable contains at each step before drawing any conclusions about where the bug is.
B.Push through — you're close, giving up now wastes your investment.
C.Take a break, then explain the problem out loud step by step.
D.Rewrite the section from scratch without looking at the existing code.

The Reasoning

C is correct. Once you've reread code three times without finding the bug, more rereading won't help — you're seeing what you expect to see, not what's there. Two things break this:

Distance. A 15-minute break genuinely changes how your brain processes the problem. People solve bugs walking to lunch surprisingly often.

Articulation. Explaining the problem out loud — to a person, a rubber duck, or even a piece of paper — forces you to verbalise assumptions you've been holding silently. The bug is almost always in one of those silent assumptions.

A (more logging) is what you do when you have a fresh hypothesis to test, not when you're stuck. B (push through) is sunk-cost thinking — past time spent doesn't make the next hour more productive. D (rewrite) sometimes works but is overkill at 45 minutes.

PrincipleIf you're stuck, the next debugging move isn't more code — it's more distance or more articulation.

Question 5 of 8

Halfway through the lab

Skill: Scope management

You have a 4-hour lab session to prototype a feature. After 90 minutes, you realise your approach is more complex than expected — finishing means working through lunch and probably staying late. What do you do?

Your move

A.Skip lunch and push through to finish what you started.
B.Refactor your current approach into something cleaner before continuing — clean code is faster code, and you'll move quicker after the cleanup.
C.Cut scope. Pick the simplest version of the feature that demonstrates the idea and ship that.
D.Switch to an asset-store solution to save time.

The Reasoning

C is correct. Once you discover your approach is more complex than expected, the budget you originally set is wrong — every estimate after this point is wrong by the same factor. The professional move is to reduce what you're delivering, not to extend the time you're spending. A shipped 60% feature beats an unshipped 100% one every time.

B is the "sophisticated-sounding wrong answer." Yes, clean code is sometimes faster — but mid-project, with a deadline, refactoring is premature optimisation. The right time to refactor is after the prototype works, not during.

A (push through) gets you a half-finished feature and a tired developer. D (asset store) trades a problem you partially understand for a system you don't understand at all.

PrincipleWhen the estimate is wrong, shrink the work, not the schedule.

Question 6 of 8

A 200-line PlayerController

Skill: Architectural judgement

You've written a 200-line MonoBehaviour called PlayerController that handles movement, shooting, inventory, and health. You need to add abilities next. What signals you should split it up?

Your read

A.The four mixed responsibilities — split now, not based on line count.
B.Wait until line count crosses 300 lines — a common industry guideline.
C.Keep everything in PlayerController until a concrete refactoring need arises. Premature splitting creates classes that don't match the problem's real shape, which is harder to fix later than monolithic code that grew naturally.
D.Add abilities first and see if PlayerController becomes hard to test. If it does, split based on what's awkward.

The Reasoning

A is correct. The signal is mixed responsibilities, not line count. Movement, shooting, inventory, and health are four different concerns — they change at different times, are tested differently, and are likely worked on by different people in real teams. A 50-line script with two unrelated responsibilities is already worse than a 400-line script doing one thing well.

B treats line count as the symptom, but a 300-line script doing one focused thing (like a complex pathfinding system) might be perfectly fine.

C is the "sounds-sophisticated" wrong answer. The "don't refactor too early" idea is real for code with one focused purpose. But here, you already have the four responsibilities staring at you — they're not hypothetical future ones. The argument for delaying doesn't apply.

D defers the split unnecessarily. By the time tests are awkward, you've written abilities into a tangled class and now have to unscramble even more code.

PrincipleSplit by responsibility, not by line count. If you can name the responsibilities and they're different, that's the split.

Question 7 of 8

"I could never build this"

Skill: Realistic mindset

A junior teammate looks at a finished, polished Unity game and says "There's no way I could have built this." What's the most accurate response?

Pick what's actually true

A.They probably had a strong design vision before starting — that's the skill you need to develop.
B.Mid-size games require teams of people — solo developers genuinely cannot reach this scope alone.
C.Most of the complexity comes from asset packs and tutorials the developer had access to. You have the same resources and could replicate this through similar combinations over a few months of focused work.
D.The finished version hides dozens of broken iterations and abandoned features.

The Reasoning

D is correct. What students see is the polished final product. What they don't see: the version where the camera wouldn't follow correctly, the entire weapon system that got scrapped, the three days lost to a physics bug, the original "Roll-A-Ball-but-bigger" prototype the whole thing grew out of. Every shipped game has a graveyard of failed versions inside its git history.

A is partly true (planning helps) but overstates how much "vision" matters compared to iteration. Designers rarely know upfront what's fun.

B is just false — many polished games are made solo, given enough time and scope discipline.

C is the cynical wrong answer. Asset packs help with art, not architecture. The hard parts of any game are still the developer's — and they didn't come pre-built.

PrincipleYou're comparing your messy draft to someone else's final version. Of course it feels impossible. Their messy draft looked exactly like yours.

Question 8 of 8

MissingReferenceException at runtime

Skill: Unity-specific diagnosis

The Console shows: MissingReferenceException: The object of type 'GameObject' has been destroyed but you are still trying to access it. Your script accesses an enemy reference. What's the most likely cause-and-fix?

Best diagnosis

A.The reference is being set to null somewhere — check for enemy = null assignments and remove them.
B.Your script holds a reference to an enemy that was Destroy()-ed elsewhere. Check enemy != null before using it.
C.The error is non-fatal and can usually be ignored — Unity logs it as a warning even when the code works correctly.
D.Update() is running before Awake() finishes initialising the reference. Move the access into Start().

The Reasoning

B is correct. The error message itself tells you exactly what happened: an object was destroyed and your script still has a reference to it. This is distinct from null — in Unity, destroyed GameObjects evaluate as null via Unity's overloaded comparison but the underlying C# reference isn't actually null. Always check enemy != null before using a reference that another part of the game might have destroyed.

A confuses null assignment with object destruction. They produce different errors (NullReferenceException vs MissingReferenceException). Reading errors carefully matters.

C is false and dangerous advice — MissingReferenceException means your code is doing the wrong thing and only sometimes happens to not break gameplay.

D describes a different problem (initialisation order) that produces a NullReferenceException, not MissingReferenceException.

PrincipleRead the exact error name. NullReferenceException ≠ MissingReferenceException ≠ UnassignedReferenceException. Each points to a different problem.

🧭

Check Complete

What this tells you

How to practise what you missed

Build something tiny weekly. A 30-minute prototype with no tutorial — even just "make a cube that follows the mouse." Reps matter more than scope.
Read other people's code. Open up the Starter Assets or any Asset Store script and try to predict what each method does before reading it.
Time-box debugging. When stuck for 20 minutes, force yourself to step back, articulate, or take a break — not power through.
Modify before making. Take a previous tutorial project and change one thing. Then another. Building muscle for original work doesn't start from zero.