Refactoring for a Feature: Unity Inspector Cleanup on Project E.G.G.

Emergent Media Center • Champlain College • C# • Unity Editor API

The Game

Project E.G.G. was an educational web-based game developed at Champlain College's Emergent Media Center and tested with elementary school students. You play as a small robot tasked with restoring a dying planet — but you never start from scratch. Every session picks up the world exactly where the previous player left it, for better or worse depending on the choices they made.

That persistent handoff is the mechanic that makes the game work as an educational tool. It teaches consequence and collective responsibility: the planet's health when you arrive is someone else's legacy, and the state you leave it in becomes someone else's problem.

The Problem

The world is populated by spawnable resources — trees, rocks, grass, flowers, soil. Each type had its own ResourceSpawner MonoBehaviour on the same GameObject, every one of them carrying a single prefab field and a single count field. Seventeen resource types meant seventeen stacked components in the Inspector.

That was inconvenient, but the real cost was architectural. The persistent handoff mechanic requires loading saved resource positions from a database on session start and writing them back on quit. Doing that cleanly across N separate components, each managing one resource type independently, was going to be messy. The Inspector problem and the database problem had the same root cause: the resources weren't being treated as a collection.

Unity Inspector before and after the refactor — Before: one component per resource type, stacked indefinitely. After: one component with a typed list and a custom Editor UI.

The Solution

A single ResourceSpawner MonoBehaviour holds a List<Resource> , where Resource is a small serializable inner class pairing a prefab with a spawn count. On Awake() , the component calls DatabaseDataHandler.LoadWorld() and restores each resource to its saved positions — or generates random placement for anything that's new. On quit and on the EndGame event, it writes the current positions back.

The Inspector cleanup followed naturally from treating resources as a list. A custom ResourceSpawnerEditor renders the list as a collapsible foldout with an Add button, per-entry delete controls, and a count field clamped between 0 and 50,000. The editor code lives in an Editor-only assembly and is stripped from builds entirely.

The Diff

The diff below covers ResourceSpawner.cs . The before version is the per-type component; the after version is the consolidated component with database persistence, event system integration, and RNGCryptoServiceProvider -backed random placement. ResourceSpawnerEditor.cs is new — there was no custom Editor before the refactor.