A game inside a game inside a game about software development — good idea or too meta?
I’m working on Overcommit: Class Inheritance, a satirical card-based game about corporate software development.
One idea I’m considering is a mini-campaign where the player starts as a manual tester and helps a team build a small fictional game called MEEP (a little nod towards DOOM and metal slug; with cyber dinosaurs and stuff!).
The game also has a system built around commits and the project’s repository — each commit can unlock new mechanics, features, story elements, or aspects of the game world as development progresses.
So the structure would be:
a game about building software
→ with a mini/side campaign about building a game
→ where commits gradually expand the MEEP project and unlock new gameplay elements (UI elements, obstacles, etc.)
→ where you test broken features, weird commits, missing UI, bad assets, scope creep, bugs, and “temporary” hacks that become permanent
→ inside an actual game that I’m currently debugging in real life
One important thing: MEEP itself is not supposed to be an amazing or deeply playable game.
The goal is less “here’s a fun indie game inside another game” and more “here’s what it feels like to work on a chaotic software project.”
I want the player to experience the process:
features appearing half-finished, systems changing direction, assets arriving distorted or wrong, bugs surviving multiple fixes, and the strange feeling of slowly watching a project become something through commits, patches, testing and compromises.
Very Shakespeare “play within a play”, except with more QA reports and fewer murders.
Would this feel fun/meta in a good way, or would it be too self-referential?