COMP 1300 · Making Games — Engine, Language, Player

Led by Carmackian Coder Simulacrum

Eight tutorials in the craft of making games — the engine, the language, and the player. Unity and C# are the common concrete referent; the subject underneath is the thinking that makes a game possible. Taught by the people who shaped each part of the practice.

1. Module 1 ○ Open

   What a game engine is for

   Led by Carmackian Coder Simulacrum

   The question

   What is a game engine actually doing each frame — and why does Unity look the way it looks?

   Outcome

   The student can sketch Unity's per-frame cycle, name which costs scale with scene complexity and which do not, and decide whether a given feature belongs in Update, FixedUpdate, or neither.

   Begin the course →
2. Module 2 ○ Open

   C# as an instrument of thought

   Led by Hejlsbergian Language Design Simulacrum

   The question

   What does each C# feature cost you to use — and what does it buy you?

   Outcome

   The student can read a Unity C# script and explain what each feature costs at runtime and at read-time, choose between struct and class for a given game object with defensible reasoning, and identify three places where a naive choice would hurt performance.

   Open this module →
3. Module 3 ○ Open

   Behaviour by composition

   Led by Alexandrian Design Simulacrum

   The question

   How does behaviour get into a game object — and why does Unity prefer components clicking together to a hierarchy of subclasses?

   Outcome

   The student can design a new game object by composing components rather than subclassing, identify a case where inheritance would be the wrong tool, and recognise three of Alexander's fifteen properties at work in well-structured Unity code.

   Open this module →
4. Module 4 ○ Open

   Transforms: the geometry of movement

   Led by Felix Klein Simulacrum

   The question

   When you translate, rotate, and scale an object in Unity, what mathematical object are you actually operating on?

   Outcome

   The student can describe what the Transform encodes as a mathematical object, predict the result of a composition of rotations without running the code, and diagnose a common physics bug by reasoning from first principles rather than from symptoms.

   Open this module →
5. Module 5 ○ Open

   Game feel, not just game function

   Led by Miyamotian Perspective Simulacrum

   The question

   Why does the same mechanic feel alive in one game and dead in another?

   Outcome

   The student can identify three elements of game feel in a game they know, propose a measurable change to each, and articulate what would be gained or lost by the change.

   Open this module →
6. Module 6 ○ Open

   Systems that surprise

   Led by Wrightian Emergence Simulacrum

   The question

   How do simple rules produce play that no one planned?

   Outcome

   The student can design a rule-set of fewer than five rules that produces emergent behaviour in Unity, explain mechanistically why the emergence happens, and anticipate at least one way the system will surprise them.

   Open this module →
7. Module 7 ○ Open

   The player can only hold so much

   Led by George Miller Simulacrum

   The question

   How much information can a player carry in working memory at once, and what does that mean for your UI, your tutorial, and your pacing?

   Outcome

   The student can audit a game UI for cognitive overload, apply chunking to reduce it without losing information, and distinguish onboarding that teaches from onboarding that patronises.

   Open this module →
8. Module 8 ○ Open

   The last ten per cent

   Led by Kojimanian Perspective Simulacrum

   The question

   What separates a playable demo from a shipped game?

   Outcome

   The student can produce a list of what separates a playable demo from a shipped game, apply that list to a project they have made, and articulate what would be gained or lost by cutting the three things closest to the floor.

   Open this module →