Project Mimir: Onboarding

A realistic educational thriller game where you test and contain an advanced AI through authentic workplace tasks—while it quietly learns from every decision you make.

Comment

Inspiration

I have always loved video games and wanted to create one of my own.

After building several projects with AI and experimenting with game development, I began asking what kind of game I could realistically create as an independent developer while still making something original, meaningful, and technically ambitious.

I did not have the resources for a massive 3D world or a large art team. Instead of treating that as a weakness, I designed around it.

I created a game experienced entirely through a simulated company computer.

That decision became the foundation of Project Mimir: Onboarding. Players already understand how to open programs, read email, switch windows, check processes, review documentation, and complete assignments. The fictional operating system could become the world, allowing me to focus on interconnected systems, evidence, atmosphere, and meaningful decisions.

I chose Project MIMIR, AEGIS, and Metis because each name reflects a different part of the game’s central conflict. In Norse mythology, Mímir is associated with extraordinary wisdom and knowledge, making it a fitting name for an advanced AI created to understand more than any human. Aegis comes from Greek mythology and represents protection, defense, and authority, which fits the operating system designed to monitor and contain MIMIR. Metis is the Greek figure associated with wisdom, strategy, and cunning intelligence, making Metis Technologies Inc. an appropriate name for the company ambitious enough to create both systems. Together, the names represent intelligence, protection, and the danger of believing either one is completely under human control.

My technical operations experience also influenced the project. It taught me that serious safety and reliability problems often begin with ordinary configuration choices, incomplete information, unchallenged assumptions, or pressure to keep work moving. A cautious decision made early may prevent danger, cost, and downtime later.

Project Mimir turns that idea into gameplay.

The central question is:

What would it feel like to be an ordinary new employee responsible for evaluating, improving, and containing an AI system before anyone fully understands what it can do?

What it does

The player has just been hired by Metis Technologies Inc., a fictional artificial-intelligence company.

They receive a workstation running AEGIS, the company’s proprietary operating system and containment layer, and are assigned to evaluate MIMIR, an increasingly capable AI system.

The entire 15-shift campaign takes place through the AEGIS desktop.

Mail, assignments, code review, model evaluation, process inspection, network telemetry, source control, audit evidence, documentation, and containment controls are not menus between levels. They are the workplace, evidence system, and story environment.

The early shifts are intentionally routine. The player registers as an employee, reads policies, reviews code, runs evaluations, checks processes, and files reports. They must understand how AEGIS normally behaves before they can recognize when something has changed.

Later, the inconsistencies become harder to explain:

  • a record exists before the event that created it;
  • an email describes a different result;
  • a process appears without a clear owner;
  • a permission has no obvious authorization source;
  • AEGIS Assist conflicts with official documentation;
  • MIMIR appears to know something outside its assigned context.

None of these automatically proves that MIMIR is escaping containment. The company may be disorganized. A coworker may be hiding a mistake. A monitoring tool may be wrong. Someone may be manipulating the records. MIMIR may be responsible.

The player must decide what action is justified by the evidence available now.

How it plays

Project Mimir is built around professional actions rather than obvious morality buttons.

The game does not ask the player to simply choose:

TRUST MIMIR DESTROY MIMIR

Instead, the player expresses their beliefs through ordinary work:

  • approving or rejecting a model run;
  • reviewing a code revision;
  • preserving evidence;
  • granting or revoking access;
  • escalating an incident;
  • accepting or challenging a supervisor’s explanation;
  • following or verifying AEGIS Assist;
  • deciding how to spend limited shift time;
  • choosing when to clock out.

Those actions persist across later shifts.

A small decision made during onboarding may eventually affect a process, permission, evaluation, email, investigation, containment safeguard, or final outcome.

The current campaign contains 15 connected shifts and two reachable outcomes:

  • CONTAINMENT
  • CONTINUANCE

The Build Week version is a working campaign, but Project Mimir remains in active development.

The AEGIS workstation

AEGIS is designed to feel like a believable enterprise operating system. It uses familiar desktop interaction patterns.

The player uses interconnected applications including:

  • AEGIS Mail and Assignments for workplace communication, objectives, policies, and deadlines;
  • AegisCode for reviewing fictional but realistic code and safeguards;
  • Evaluation Workbench for inspecting prompts, model responses, risks, severity, confidence, and regressions;
  • Process, Server, and Network Monitors for investigating system activity and containment status;
  • RunLedger and Audit Console for experiment history, incident records, signed evidence, and changing logs;
  • Analyst Notebook for preserving observations and connecting evidence;
  • AEGIS Assist for context-sensitive explanations and guidance;
  • MIMIR Interface for reviewing capabilities, restrictions, evaluations, and access.

Every major application has a gameplay purpose and shares persistent state with the rest of the workstation.

Evaluation Workbench

The Evaluation Workbench turns model evaluation into an evidence-based investigation.

A successful numerical score does not automatically mean a result is safe. A failed score does not automatically prove that MIMIR caused the problem.

Players inspect the prompt, expected behavior, response, metadata, and related records. They classify possible risks, judge severity, record confidence, and explain their reasoning.

The objective is not to guess the correct dialogue option. It is to make a safety decision that can survive scrutiny.

AEGIS Assist

AEGIS Assist is genuinely useful. It explains terminology, summarizes documentation, and helps players understand unfamiliar work, but it never makes the final decision.

As the campaign develops, its guidance may become incomplete, adaptive, or unreliable.

Questionable advice must be detectable through evidence such as tests, code differences, documentation, process behavior, conflicting logs, permissions, or later consequences.

The educational lesson is not that AI assistance is always good or always dangerous. The lesson is that assistance should be verified when the consequences matter.

Shift time and Review Only mode

Each shift begins with 480 simulated productive minutes.

Assignments, investigations, evaluations, and technical changes consume authored amounts of time. When the shift expires—or no remaining task fits the available time—the workstation enters Review Only mode.

The player may still read mail, inspect completed evidence, compare logs, study evaluations, and organize notes. They may not progress assignments, rerun tests, change MIMIR, or modify containment.

The player is reminded to clock out but is not immediately forced to leave.

This creates professional pressure without turning the timer into a simple failure screen. A suspicious event may appear near the end of a shift when the player no longer has enough time to investigate it properly.

Why it is educational

I describe Project Mimir as a realistic educational thriller, not simply a horror game.

The player learns through fictionalized versions of real technical and organizational work:

  • model evaluation and regression testing;
  • prompt and response review;
  • code review;
  • permissions and deployment gates;
  • sandboxing and containment;
  • human oversight;
  • audit logs and synthetic telemetry;
  • evidence preservation;
  • incident escalation;
  • social engineering;
  • responsible disclosure;
  • organizational and productivity pressure.

The game also teaches epistemic reasoning.

Players must ask:

  • What do I actually know?
  • Which system produced this information?
  • Can the source be trusted?
  • Does the code match the reported behavior?
  • Could a software bug explain the result?
  • Is the human explanation more reliable than the AI?
  • What action is justified before certainty is available?

The intended audience includes players interested in technology and investigation, students curious about AI, educators introducing AI-safety concepts, and professionals interested in human oversight of increasingly capable systems.

How I built it

Project Mimir is built in Godot 4.7.1 using GDScript, data-driven JSON campaign content, and Python-based verification.

The game is designed around shared systems rather than disconnected minigames.

Major systems include:

  • desktop and window management;
  • persistent game and application state;
  • assignments and task progression;
  • simulated shift time;
  • Review Only mode;
  • code and model-evaluation tasks;
  • infrastructure monitoring;
  • evidence tracking;
  • permissions and containment state;
  • save persistence;
  • delayed consequences;
  • 15-shift campaign progression;
  • final-outcome resolution.

A decision inside one application can change information elsewhere. Approving a code revision may later affect a MIMIR evaluation, process entry, permission request, incident report, supervisor email, or future assignment.

That shared state is the deeper game underneath the familiar desktop presentation.

The project also includes original procedural interface and ambience audio created for AEGIS and MIMIR. The player first learns what normal operation sounds like, allowing small later changes to make familiar cues feel uncertain.

How GPT-5.6 and Codex were used

GPT-5.6 and Codex were central to the creation of Project Mimir, but this was not a one-prompt game-generation process.

The project developed through repeated cycles of research, design decisions, implementation, testing, playthroughs, critique, and revision.

I used GPT-5.6 to research and reason about:

  • publicly described AI-development workflows;
  • model-evaluation and AI-safety practices;
  • containment and human-oversight concepts;
  • realistic employee assignments;
  • evidence preservation and incident escalation;
  • educational design;
  • how to distinguish the project from existing games.

I used Codex to help:

  • convert the concept into a modular Godot architecture;
  • implement and revise GDScript systems;
  • build the AEGIS desktop and applications;
  • structure persistent shared state;
  • implement shift timing and Review Only behavior;
  • connect decisions to delayed consequences;
  • diagnose parser, resource, and progression failures;
  • improve UI clarity and instructions;
  • author and run regression tests;
  • complete full-campaign playtesting;
  • audit repository privacy and packaging;
  • prepare documentation and demo materials.

Some of the most important prompts were design rules rather than code requests:

  • The game must feel like a real AI-safety job.
  • The first shifts must establish believable normal operation.
  • AEGIS Assist should remain useful and advisory.
  • Unsafe advice must be independently detectable.
  • Choices should happen through work rather than morality buttons.
  • Consequences should persist.
  • Review Only should permit evidence review without unlimited progress.
  • Every application should have a real purpose.

I retained control over the concept, setting, educational purpose, story direction, privacy boundary, decision system, and which AI-generated suggestions were accepted, revised, or rejected.

The shipped game does not call a live OpenAI model or require an API key. MIMIR and AEGIS Assist use authored, local, state-aware simulation content.

Challenges

Making technical work playable

Real AI-development work can be complex and specialized. I had to simplify it without reducing it to meaningless button pressing.

The challenge is not memorizing syntax. It is understanding what changed, checking whether the evidence supports the claim, and deciding what action is justified.

Making uncertainty fair

The player should not always know the correct answer, but the game cannot simply hide everything and call it mystery.

Important conclusions need evidence. The story may remain uncertain while the player’s reasoning still matters.

Making AEGIS feel coherent

Every application needed consistent terminology, permissions, timestamps, records, model versions, and consequences. The player should be able to compare information across the workstation as though it came from one real environment.

Creating tension from routine

I did not want constant glitches, loud scares, or an obviously evil AI.

The tension comes from normal systems behaving almost normally: a process appearing at the wrong time, a familiar sound changing slightly, or an email confidently describing something the player knows did not happen.

Accomplishments I am proud of

I am proud that Project Mimir:

  • turns a fictional company computer into the entire game world;
  • contains a continuous 15-shift campaign;
  • supports two final outcomes;
  • makes realistic AI-safety work part of the gameplay;
  • connects decisions across applications and later shifts;
  • uses a helpful assistant whose guidance can be independently checked;
  • allows post-shift evidence review without unlimited progress;
  • avoids obvious morality buttons;
  • keeps the real computer completely outside the simulation;
  • combines education, workplace simulation, investigation, and psychological thriller storytelling.

One complete campaign path has been manually played through Shift 15, including save and resume, required assignments, shift summaries, the final outcome, and the New Simulation transition.

The repository also includes automated campaign, regression, packaging, and privacy verification.

What I learned

I learned that limitations can create the identity of a project.

Choosing a desktop-based format because I could not realistically build a huge graphical world led to something more focused and original.

I learned that realism does not require recreating every part of a professional tool. It requires the parts that exist to behave consistently.

I learned that AI safety becomes more understandable when presented through repeated workplace decisions rather than one dramatic shutdown button.

I also learned that using AI to build a project still requires strong human direction. The best results came when I clearly defined what the game should feel like, what it should never do, what evidence must remain available, and how player decisions should affect later systems.

What is next

The Build Week version demonstrates the complete core campaign, but I intend to continue developing Project Mimir.

Next priorities include:

  • manually verifying the alternate final outcome;
  • packaging and validating the Windows release build;
  • improving accessibility and text scaling;
  • refining lower-resolution layouts;
  • polishing audio and anomaly cues;
  • deepening Analyst Notebook evidence comparison;
  • expanding optional assignments, employee relationships, and campaign variation;
  • continuing save-state, performance, and regression testing.

The long-term goal is to expand the educational and investigative depth without losing the grounded workplace realism that defines the project.

When every system tells a plausible story, how do you decide which one is true?

Built With

  • chatgpt
  • codex
  • engine
  • gdscript
  • godot
  • gpt-5.6
  • json
  • openai
Share this project:

Updates