Unity course curriculum: the full roadmap from zero to employable
All 20 sessions of the 64-hour Unity course, week by week: what each one covers, why it comes in that order, and what you can do by the end of each week.
Lucian Lazar · 12 Sept 2026
The course is 20 livestream sessions recorded over four weeks in 2024. This is the whole thing laid out in order, with the reasoning behind the order. If you want the interactive version with checkboxes and a progress bar, that is the curriculum page.
The shape is simple: week one is the editor, week two is code, week three is a complete game, week four is shipping and getting hired. Each week assumes the one before it.
Week 1: Unity fundamentals
Most people who quit Unity quit in the first week, and it is rarely because of code. It is because the editor is large, the vocabulary is unfamiliar, and they never get to the point where moving around a scene feels natural. So week one is entirely about that: getting comfortable in the tool before writing anything serious.
Intro: what this course is and how to learn gamedev (about 2h) sets expectations. What the course is, what it is not, how to practise so that things stick, and how to think about gamedev as an engineering discipline rather than a hobby. This session is free.
Version control and the Unity interface (about 2.5h) starts with git before Unity. That order is deliberate: every professional project lives in version control, and learning it on day two means you never build the habit of working without it. Then the editor itself, panel by panel.
Assets, GameObjects and Components (about 2h) is the mental model that everything else in Unity hangs on. A scene is a tree of objects and every behaviour is a component on one of them; once that clicks, the rest of the engine stops being mysterious.
Prefabs, lights and materials (about 2.5h) covers reusable objects, prefab variants and overrides, then the basics of lighting and materials so your scenes stop looking like grey boxes.
Scenes and 2D animation (about 2.5h) closes the week with scene management and the 2D animation system: sprite sheets, the Animator and transitions.
What you can do at the end of week one: open Unity, build a scene from assets, set up prefabs, animate a sprite, and commit all of it to git without thinking about any of those steps. No real code yet, and that is intentional.
Week 2: C#, systems and the coding masterclass
Week two is the heaviest week and the one that separates this course from most others. The first two sessions finish the engine systems you need. The last three are about how to write code, which is the actual job.
UI, sprites and physics (part 1) (about 4h) covers the UI system, sprite handling, and the first half of 2D physics: rigidbodies, colliders, triggers, and the difference between them.
Physics (part 2), sound and particles (about 2h) finishes physics with forces and layers, then adds audio and particle systems. After this you have every engine feature needed to build a small game.
Coding masterclass (watch even if you are not a gamedev) (about 6h) is the centre of the course. It is a long session about how a senior engineer writes C#: naming, structure, when to split things, how to read an error, how to debug methodically, and the habits that make code readable to the next person. It is engine-agnostic on purpose. This session is free, and if you only watch one thing from the course, watch this.
C# meets Unity (about 5.5h) applies the masterclass to the engine. MonoBehaviour lifecycle, the update loop, coroutines, events, ScriptableObjects, and how Unity’s runtime actually executes your code. This is where the fundamentals from the masterclass turn into working game code.
Microservices: how games talk to backends (about 3h) is the session most Unity courses do not have. Leaderboards, accounts, saves, live ops: any game with a server needs someone who understands HTTP, JSON and the shape of a backend.
What you can do at the end of week two: write C# that another engineer would accept in review, build gameplay systems from scratch, debug your own problems instead of pasting errors into a search box, and talk to a backend.
Week 3: build a full game, Duck Invaders
Everything so far is preparation for this. Week three is one warm-up session and then four consecutive sessions of live coding a complete game from an empty project.
Finite state machines, Cinemachine and debugging (about 3.5h) gives you the last three tools you need: state machines for enemy and player behaviour, Cinemachine for cameras, and a deeper pass on the debugger.
Live coding Duck Invaders (1/4) (about 3h) starts from nothing: project setup, folder structure, the player, the first enemy. This session is free, so you can see exactly what the live coding looks like before buying.
Live coding Duck Invaders (2/4) (about 4h) adds waves, shooting, collisions and the core loop that makes it a game.
Live coding Duck Invaders (3/4) (about 3.5h) is UI, score, sound, particles and the state machine tying menu, play and game-over together.
Live coding Duck Invaders (4/4) (about 5.5h) is polish, bug fixing and the long tail of small decisions that turn a prototype into something you would actually show someone. The length is honest: finishing takes longer than starting.
These are raw recordings. You see the mistakes, the wrong turns and the fixes, because that is what the work looks like.
What you can do at the end of week three: you have built a complete game alongside me, and you understand every line in it. That is your first portfolio piece.
Week 4: ship it and get hired
A finished game on your hard drive is worth nothing. Week four is about getting it in front of people and then getting yourself in front of employers.
Workflow, building and publishing (about 4h) covers build settings, platform targets, project organisation for a real team, and actually publishing to a store page.
Your profile, resume, GitHub and communities (about 1.5h) is short and practical: what a hiring manager looks at, how to present one finished project so it counts, and where to be visible.
Adapting to existing projects and company conventions (about 2h) is the skill nobody teaches beginners. Your first job is not an empty project, it is a five-year-old codebase with rules you did not write. This session is about reading it, respecting it, and contributing without breaking things.
Freelancing, indie, employment and the interview (about 2.5h) is the honest comparison of the three ways to make money with this skill, and then how Unity interviews actually go, including the questions that come up every time.
Exam, project grading, feedback and certificates (about 3h) is the final exam from the live cohort, with projects graded on stream. Watching real beginner projects get reviewed shows you the gap between “it runs” and “it is good”, which is the gap you need to close.
What you can do at the end of week four: you have a published game, a profile that presents it properly, and a realistic picture of what the first job looks like and how to get it.
The three free sessions
The intro, the coding masterclass and the first Duck Invaders session are public on YouTube. They are on the samples page with notes. They are full sessions, not trailers.
Realistic pacing
The live cohort did this in four weeks, full time. You almost certainly have a job. Plan for four to eight weeks, an hour or two most evenings plus a longer block on the weekend, and do not watch without Unity open. Pausing to reproduce what is on screen roughly doubles the time per session and is the entire point.
If you know some programming already, week two goes faster and you can compress into the four-to-five week range. If you are new to code, give week two extra room before moving on. Week three should be done in a continuous stretch if you can, because the four Duck Invaders sessions build on each other and momentum matters.
Track it on the curriculum page, which has a checkbox per session and a progress bar that lives in your browser. Common questions about prerequisites, Unity versions and more are on the FAQ and the teacher is on the about page.