Most people open presents on Christmas. We opened VS Code.

The project had existed as a loose collection of scripts since December 1st, but today it got real structure. We rebuilt everything around a self-bootstrapping System — a single entry point that discovers and initializes all game modules automatically. No more manually wiring things up in Studio.

What went in

  • Framework v1 architecture — A System module that boots itself, discovers assets, and manages their lifecycle
  • Rojo integration — Syncing from the filesystem into Studio via a default.project.json, with an Anchor.rbxm to hold the tree together
  • Wally package management — Because manually managing dependencies in Roblox is pain we don’t need
  • First gameplay assets — A ZoneController for defining playable areas, a Dispenser for spawning items, and a Marshmallow template (yes, marshmallows — it’s a campfire game prototype)

Why self-bootstrapping?

In most Roblox games, you’ve got a handful of Scripts and LocalScripts that each require() their own dependencies. That works until you have 15 assets that all need to initialize in a specific order. Then you’re writing WaitForChild chains and praying that replication order stays consistent between Studio and production.

Our System takes a different approach. It sits at the root of the asset tree and walks downward, discovering modules by convention. If a module has an init() function, the System calls it. If it declares dependencies, the System resolves them first. The game developer doesn’t wire anything — they drop a module into the tree and it gets picked up.

This is borrowed from how web frameworks handle service discovery. Express middleware, Spring beans, Django apps — they all follow the same pattern: register by convention, resolve by the framework, initialize in dependency order. We’re applying that to Roblox’s Instance hierarchy.

The tradeoff is that the System now owns the boot sequence. Individual scripts can’t just run whenever they want. That’s a constraint, but it’s one that pays off immediately — you never wonder “has this been initialized yet?” because the System guarantees order.

The Rojo + Wally stack

For anyone not using Rojo yet: it syncs your filesystem into Studio in real time. You edit Lua files in VS Code (or any editor), and they appear in the Explorer tree. This means version control, diff tools, code review, and all the things professional developers take for granted actually work.

Wally handles package management — third-party libraries get a version number and a lockfile instead of “I pasted this ModuleScript from someone’s GitHub.”

It’s the kind of foundation work that isn’t flashy but saves you from a world of hurt later. The framework is 5 assets today. In a month it’ll be 50.