Syllabus
The contents of these labs are made to teach and stress some learning points and for mere “practice”, e.g: getting used to Unity layout, terminologies, etc.
By no means we claim that they are the best practice, in fact some of the ways may be convoluted and they won’t be done exactly this way by experienced coders but we can’t teach the “best practices” right away because it relies on many prior knowledge.
Experienced programmers: keep in mind that you too were once a beginner. You made mistakes, you grow from it. You didn't get to be where you are right now instantly.
If you realise that some parts are troublesome or ineffective, then good for you. It means that you’re experienced, and from now on you can embark on the journey to customize it to a more fitting way: simpler, better, more efficient, whatever it is.
You can tell our teaching team your personal opinion, and constructive criticism is always welcome after class. We however expect a certain kind of mutual respect during the lab hours.
We do not give a trivial hand-holding step-by-step tutorial here. We do condense some steps. Remember that this is still part of your graded lab assignment, so you need to imply some parts based on standard programming knowledge as a CS student.
Week 1: Unity for Newborns
We start from standard introductory knowledge about using Unity:
| Topic | Details |
|---|---|
| Installation | dotnet, configuring editor, enabling intellisense |
| Unity Basics (files) | Layout arrangements, windows, managing project files |
| Unity Basics (scene) | Adding and editing a scene, add GameObject & elements, create prefabs, use Camera, binding keys for input |
| Unity Basics (scripts) | C# scripting basics, setting script execution order |
| Unity Engine | Physics Engine: Rigidbody2D, Collider2D |
| UI Elements | Canvas, Text, Button (Legacy), TextMeshPro |
| Unity Lifecycle | Introduction, common callback functions: Update(), Start(), OnTriggerEnter(), among many others. |
| Unity Events | onClick() Button |
Week 2: Unity for Babies
This week, we expand our horizon a little bit and instill more fun in our lab by adding enhanced feedback:
| Topic | Details |
|---|---|
| Animation | Create animator and animation clips, transition between animations, setup animation parameters, timing animations and state machine |
| Unity Basics (camera) | Camera Movement |
| Unity Events | Trigger events from animation |
| Sound Effects | Add sound effects |
| Unity Basics (files) | Create and manage Prefabs |
Week 3: Unity for Toddlers
We have a lot of state management to do at this stage. It's time to learn more advanced Input Management, Audio Management, and Design Patterns.
| Topic | Details |
|---|---|
| Unity | The Input System |
| The Input System Input | Keyboard, Mouse |
| The Input System | InputActions, Actions, ActionMaps, Action Binding, Action Properties |
| The Input System Workflow | ActionAsset, PlayerInput Component |
| Unity | AudioMixer |
| Design Pattern | The Observer Pattern |
| C# | Delegates, Actions, and UnityEvent |
| Unity Scripting | AnimationEvent<T>Tool |
Week 4: Unity for Children
This week we learn how to make a multi-scene game and make important instances and values persist between scenes and gameplay.
| Topic | Details |
|---|---|
| Unity | Switching Scenes |
| C# | Enums, switch statements, interface and inheritance, static variables, properties and method overloading |
| C# Advanced | Coroutines, async-await |
| Design Pattern | Singletons |
| Design Pattern | Delegates, Actions, and Unity Events |
| Unity Scripting | Scriptable Objects |
Week 5: Unity for Teens
This week we are doing a complete overhaul of game architecture and utilises the Scriptable Object Game Architecture (SOGA) instead that allows for better modularity and decoupling (minimise dependencies between subcomponents). However it requires quite a big initial investment to set up.
| Topic | Details |
|---|---|
| Architecture | ScriptableObject-based event and data architecture for modularity and reuse; singletons only where global caches or configuration are appropriate. |
| SO Event System | GameEvent ScriptableObjects with GameEventListener components implement a publish–subscribe pattern; call Raise to broadcast events decoupled from the sender. |
| Persistent Data | Use ScriptableObject variables (e.g., integers, booleans, object references) so values persist across scenes and objects without singleton managers. |
| Migration | Replace direct managerInstance.Event.AddListener(...) calls with: (1) creating SO events, (2) attaching listeners to objects, (3) wiring callbacks and Raise methods in the Inspector. |
| FSM Purpose | Implement a pluggable finite state machine using ScriptableObjects to separate state definitions from code, making logic reusable and easy to extend. |
| FSM Core Types | State (SO with actions, transitions), Action (SO behavior unit), EventAction (triggered action), Decision (SO conditional), Transition (links states). |
| State Controller | MonoBehaviour that runs the FSM at runtime, tracks current/next states, executes actions, and evaluates transitions. |
| Actions | ScriptableObjects encapsulating behaviors (e.g., setup, clear, activate ability). Can be reused across states or objects. |
| Decisions | ScriptableObjects encapsulating conditions (e.g., input detected, timer expired). Drive state transitions without hardcoding logic into controllers. |
| States | FSMs require a set of states plus a “remain” or “no transition” placeholder; states are modular and swappable. |
| Input & Events | External input or in-game events connect to trigger event actions or state transitions, keeping input handling decoupled from gameplay logic. |
| Design Patterns | Apply ScriptableObject architecture for modular systems; use singletons selectively for global services. |