Embedded Files
🗓️ Coming Up
🗓️ Coming Up
Week 6: Pixel Artist Spotlight - Sprite Sheet Animation, Top Down Vs. Platformer Vs. Isometric, Color Pallettes & Eastward Demo
Week 7: Audio Engineer & Manager Role Overview, Important Questionnaire to decide Roles/Teams/Genre & Hollow Knight Demo
Week 8: Role/Team Reveal & Project Planning - Announce genres + start brainstorming for Winter/Semester 2
About Multiplayer (and Why We’re Not Doing It...Yet)
About Multiplayer (and Why We’re Not Doing It...Yet)
When I first dreamed up this class, I imagined two-player games— maybe even a full co-op forest adventure.
That’s totally possible in Godot… just not practical for our classroom setup.
2-Player LAN (Local Play) x2 workload
2-Player LAN (Local Play) x2 workload
Works only if both computers are on the same Wi-Fi network.
Needs open network ports and special firewall permissions.
Most networks block those ports for safety, so the connection fails even if the code is perfect.
It’s great for home experiments but unreliable in shared spaces.
2-Player Web Play
2-Player Web Play
Browser (HTML5) builds can’t use UDP, the fast protocol Godot multiplayer needs.
Browsers block UDP for security, so two players can’t exchange live data online
3-Plus Players x5 workload
3-Plus Players x5 workload
Real online multiplayer needs a dedicated lobby server (hosting $ + maintenance + security).
Powerful long-term skill, but far beyond our class scope.
Teacher Disclaimer - Leafkeeper Demo
Teacher Disclaimer - Leafkeeper Demo
This little demo isn’t our final game — it’s my practice project.
I made it to understand the Godot engine inside-out, test how to teach it, and figure out what challenges you all might face once we start building together.
It’s rudimentary and clunky (I cut every corner possible!), but it still took me hours of trial, error, and bug-hunting.
The goal wasn’t perfection — it was learning how to make things work, so when we begin our class project, I can help our developers press the easy button when things get tricky.
GDScript — Speaking the Game’s Language
GDScript — Speaking the Game’s Language
GDScript is Godot’s built-in language, similar to Python or Lua.
It’s interpreted — Godot reads it line by line and turns it into bytecode, which the engine runs immediately.
That makes it perfect for testing ideas fast.
In contrast, languages like C++ are compiled ahead of time into machine language (1s and 0s), which runs faster but takes longer to build and debug.
Scenes, Roots, and Child Nodes — The Family Tree of a Game
Scenes, Roots, and Child Nodes — The Family Tree of a Game
In Godot, everything lives inside a scene — a mini-world that holds all the parts of something: a player, a tree, a menu, or a level.
Each scene starts with a Root Node (the parent) and a set of Child Nodes (the branches) that each handle one job.
Godot reads this scene tree from top to bottom — drawing, updating, and sending signals between nodes.
You can drag one scene (like Ghost) into another (like World) to reuse it as a child — that’s how big games are built from small, testable pieces.
World Scene
-Ghost (Scene)
- Leaf (Scene)
- UI (CanvasLayer)
- Script (World.gd)
Collisions — How the Ghost Knows a Leaf Is There
Collisions — How the Ghost Knows a Leaf Is There
Games check each frame to see if two things touch.
When they do, a signal fires — a tiny message that says “Hey, these two just met!”
Our ghost bumps the leaf → the leaf sends a signal → our score goes up!
You can use collision settings to block movement, for example the ghost cannot move through the tree.
Signals — The Game’s Way of Talking to Itself
Signals — The Game’s Way of Talking to Itself
Signals let one node talk to another — like built-in walkie-talkies.
In Java, you’d call this a listener or event handler.
State Machines — The Game’s Memory
State Machines — The Game’s Memory
A state machine tracks what mode the game is in: menu → playing → paused → win screen.
Our Leaf Keeper uses it to remember how many leaves we’ve caught and when to show the win scene.
Randomization — The Wind’s Dice Roll
Randomization — The Wind’s Dice Roll
When leaves appear in new spots each play, that’s randomness!
Godot rolls invisible dice to decide where things spawn.
GitHub — Our Developer Backpack
GitHub — Our Developer Backpack
GitHub is where developers save, share, and track their work.
It’s like a digital backpack that remembers every change you make. Each time we update our game — add art, fix code, or test ideas — we make a commit, a save point in time. If something breaks, we can rewind to any earlier version.
Why we use it:
Keeps everyone’s work safe
Lets teammates edit without overwriting
Shows our progress over time
GitHub is our time machine — every version of the game lives there, even the mistakes. Each team will have its own folder inside our shared Gather Studio repository. Developers will push code, artists and writers will sync assets, and managers will keep everything up to date.
Demo Spotlight - Celeste
Demo Spotlight - Celeste
Mountain of 2D Mechanics
Mountain of 2D Mechanics
We’ve explored A Short Hike for storytelling and Mario Kart for fairness — now we climb a mountain built by developers who mastered movement and feedback. Rubric here
Watch for:
Collisions
Signals
State changes
Random elements
How the code feels to the player
Page updated
Google Sites
Report abuse