Code Bank
A library of Unity script scaffolds for recreating and experimenting with videogame gestures. Each scaffold exposes the variables that matter for feel without requiring you to write code from scratch.
The goal: tune, don't code. You're learning to shape gestures, not learning to program. The scaffolds handle the engineering; you handle the design.
Multi-perspective support: Each scaffold includes variants for 2D, 3D Third-Person, 3D First-Person, and Isometric perspectives where applicable. All scripts use the same InputReader pattern for seamless gamepad and keyboard+mouse support.
How to Use
- Find the scaffold that matches the gesture you're recreating
- Drop it into Unity (drag the prefab or attach the script)
- Tune the exposed variables in the Inspector until it feels right
- Document what you changed and why - this is the learning
Every variable has a tooltip explaining what it does and what changing it affects.
Available Scaffolds
Setup & Foundations
| Scaffold | What it does | Key components |
|---|---|---|
| Input Setup | Unified input system for all perspectives | InputReader, New Input System, device detection |
Movement
| Scaffold | What it does | Key variables |
|---|---|---|
| Basic Jump | Single jump with tunable arc | jumpForce, gravity, fallGravityMultiplier |
| Variable Jump | Jump height based on button hold | minJumpForce, maxJumpForce, holdTime |
| Double Jump | Extra jump in mid-air | extraJumps, airJumpForce, resetVelocity |
| Coyote Time | Grace period after leaving ledge | coyoteTime |
| Dash | Burst movement with recovery | dashSpeed, dashDuration, cooldown |
Feedback & Feel
| Scaffold | What it does | Key variables |
|---|---|---|
| Screen Shake | Camera shake on impact | intensity, duration, decay |
| Hitstop | Freeze frame on hit | hitstopDuration, timeScale |
| Squash & Stretch | Deform sprite based on motion | stretchAmount, squashAmount, returnSpeed |
| Knockback | Push away on hit | knockbackForce, knockbackUp, hitstunDuration |
Timing & Input
| Scaffold | What it does | Key variables |
|---|---|---|
| Input Buffer | Remember inputs for grace window | bufferTime |
Scaffolds In Development
Future scaffolds will include:
- Movement: Ground Movement, Air Control, Wall Jump
- Feedback: Trail Effect, Landing Impact
- Camera: Follow Camera, Camera Bounds, Focus Point
- Timing: Cooldown Timer, Charge Mechanic
- Combat: Melee Attack, Health System
Starting Points by Exercise
Gesture Recreation (Week 2)
Start with: Basic Jump
Add: Screen Shake for landing feedback
Heritage Translation (Week 3)
Start with: the scaffold closest to your source gesture
Modify: tune until it matches, then deliberately transform one variable set
The 30-Minute Action (Week 5)
Combine: Dash + Screen Shake
Constraint: only tune what's exposed, no new code
Feel Experiment (Week 7)
Pick any scaffold. Change one variable dramatically. Document:
- What changed in the feel?
- What didn't change that you expected to?
- What does this tell you about how the components interact?
Why the Code Bank Exists
The Code Bank exists because code is a barrier to feel exploration. Students who have to write their own jump code spend all their time debugging, not designing. The scaffolds remove that barrier.
Key Principles
Expose the design variables, hide the engineering variables. Students don't need to know how the physics integration works; they need to know what hangTime does to the jump arc.
Tooltip discipline: Every exposed variable has a tooltip. This is non-negotiable. Students should be able to hover and understand without leaving Unity.
Scaffold Philosophy
- Modular: Each scaffold does one thing. Combine them for complex behaviors.
- Readable: Variable names should be self-explanatory.
- Tunable: Default values should produce a "neutral" feel. Students move from there.
Common Issue
Students want to dive into the code. Redirect: "First get it feeling right by tuning. Then you can look under the hood." The sequence matters - feel before implementation.
Assessment
Can they articulate why they changed a variable, not just that they changed it? "I increased coyote time because the original felt punishing" is good. "I set it to 0.15" is insufficient.
Code as Material
The Code Bank embodies the idea that code is material, not prerequisite.
Traditional videogame education often teaches programming first, design second. Students spend semesters learning to make things move before they can ask whether the movement feels right. This gets it backwards. Designers need to develop feel intuition early, even if they can't yet implement from scratch.
The scaffolds are like woodworking jigs - tools that let you focus on the craft decision (the cut, the joint) without rebuilding the saw each time. Eventually you learn how the saw works, but not before you've made some furniture.
What This Approach Resists
The "real programmers write from scratch" mentality that pervades CS-adjacent education. Using scaffolds isn't cheating; it's working at the right level of abstraction for the learning goal.
The black-box tool critique - yes, scaffolds hide complexity. That's the point. You can always open the box later. But if you never get to the design layer because you're stuck in the implementation layer, the box might as well not exist.
Unresolved Tension
When do students graduate from scaffolds to raw implementation? We don't have a clean answer. Current approach: scaffolds for the intro course, increasing implementation in intermediate courses, full implementation in advanced. But some students never need full implementation - they're designers, not engineers. Is that okay? We think yes, but the industry often disagrees.
Contributing
The Code Bank is a living library. If you build a scaffold that others might use:
- Follow the naming conventions
- Add tooltips to every exposed variable
- Set sensible defaults
- Document in the same format as existing scaffolds
- Tag with relevant concepts
Related
- Gesture - what you're recreating with these scaffolds
- Aesthetic Heritage - using scaffolds to trace and transform inherited gestures
- Code as Material - the philosophy behind this approach