A Shared Unity Foundation For Spec-Driven Games

How a small shared Unity package can support many game repositories without turning into a dumping ground.

When many Unity game repositories share the same production model, reusable code becomes tempting. The trap is moving too much too early. A shared package should reduce repeated work without flattening the games into the same product.

The shared Unity foundation starts with a narrow rule: only broadly reusable, SDK-free foundations belong there. Safe-area helpers, accessibility settings, save interfaces, localization keys, telemetry event envelopes, feedback routing, and deterministic test utilities are good candidates. Game mechanics, art, content, economy, platform entitlements, monetization, and vendor SDK choices stay with the individual game unless there is an explicit decision to promote them.

The package is also part of the spec-driven production loop. The shared library has its own VeritySpec workspace, release checklist, migration notes, tests, CI, and agent instructions. Each game repository has a planned dependency record, but the Unity manifest dependency is not installed until a package version is tagged and approved.

That distinction matters. A planned dependency lets agents discover the shared foundation and propose reusable work. An installed dependency changes the actual Unity project. Keeping those separate makes rollout more deliberate.

The first adoption should be small. A few pilot games can prove the package shape, migration notes, and validation flow before all 50 games point their manifests at the same tag.