Why Unity
Unity isn't in this course "because industry." Unity is in this course because videogames are a medium of implementation.
Your Idea Is Not a Videogame
A design document is not a videogame. A concept is not a videogame. A mood board is not a videogame.
Your idea only becomes a videogame when you commit to constraints. Until then, it's potential. Implementation makes it real.
The Constraints
When you build in an engine, you must decide:
- Input - What buttons? What timing? What feels responsive?
- Timing - How many frames? How fast? What duration?
- State - What can happen when? What prevents what?
- Feedback - What does the player see, hear, feel?
- Camera - What's visible? What's framed? What's hidden?
- Audio - What sounds? When? How loud? How layered?
- Iteration - What do you change? How do you test?
These aren't implementation details - they ARE the design. A jump with 0.2 seconds of hang time is a different videogame than a jump with 0.4 seconds. The engine is where you discover which one is yours.
The Workshop
Unity is the workshop where those constraints become real. The engine teaches you what your videogame design actually is.
You can imagine a jump. You can describe a jump. But until you build a jump - set the gravity, the velocity, the animation frames, the landing sound - you don't know what your jump is.
This is why we use an engine in a design course, not a prototyping tool. Prototyping tools let you sketch. Engines let you commit.
Why Unity Specifically
Unity is not the only engine. It's not necessarily the "best" engine. We use it because:
- 2D and 3D: Handles both without switching tools
- C# scripting: Real programming language, transferable skills
- Documentation: Extensive, searchable, beginner-friendly
- Community: Large enough that most problems are solved somewhere
- Free tier: No cost barrier to entry
- Industry presence: Skills transfer to jobs (this matters, even if it's not the reason)
Godot, Unreal, GameMaker - all valid choices. The pedagogy transfers. The point is having a real engine, not which real engine.
What Unity Is Not
Unity is not the course.
This is not "learn Unity." This is "learn videogame design, using Unity as the workshop." We don't cover every Unity feature. We cover what you need to implement your designs.
The goal is not Unity proficiency. The goal is design thinking that happens to be implemented in Unity.
Why Teach This
Students often resist implementation. They want to stay in the idea phase, where everything is possible and nothing is tested.
Explaining why we use an engine - not just how - helps students understand that implementation is not a chore after design. Implementation IS design.
The "I'm Not a Programmer" Problem
Many design students identify as "not programmers." They see code as someone else's job.
Our response:
- You don't need to be a programmer. You need to commit to constraints.
- The Code Bank scaffolds let you design without writing from scratch.
- Debugging is the skill, not authoring.
- Every parameter you tune is a design decision. That's the work.
Common Misconceptions
"We use Unity because that's what the industry uses"
Industry relevance is a side effect, not the reason. We use an engine because videogames are implemented things. The industry connection is bonus, not justification.
"I can design without an engine"
You can concept without an engine. You can document without an engine. You cannot design a Gesture without feeling it, and you cannot feel it without building it.
Assessment
We assess the design, not the technical implementation. A buggy prototype with clear design intent passes. A polished prototype with no design thinking fails.
Implementation as Epistemology
There are things you can only know by building. The feel of a jump. The timing of feedback. The camera distance that makes a space readable. These are not specifiable in advance.
This is not anti-intellectual. It's recognizing that videogames are a medium where knowledge lives in the implementation. The engine is not just a tool - it's where you learn what your design actually is.
The Sketch vs. the Commitment
Paper prototypes, Figma mockups, design documents - these are sketches. Valuable, but uncommitted. They preserve optionality.
Engine implementation is commitment. You must choose: this gravity, this frame count, this sound. The constraint is the design. The sketch proposes; the engine disposes.
Material Engagement
This connects to Code as Material. The engine is the workshop where you work with the material. You discover what the material can do by working with it.
Unresolved Questions
- How much engine proficiency is enough? Where's the line between "can implement designs" and "is an engineer"?
- Do visual scripting tools (Bolt, Blueprints) change this equation? Is text code necessary?
- What do we lose when students only know one engine? Is engine-agnostic thinking possible or desirable?
Related
- Code as Material - code has properties you work with
- Debugging as Literacy - the skill that makes engine work possible
- Code Bank - scaffolds for implementation
- The Final Project - what implementation leads to