Unemployment Simulator

Overview

Unemployment Simulator started as a deliberately constrained experiment: could I build a complete 3D game without writing code or manually assembling anything in the engine?

My only implementation interface was natural language. I described what I wanted, played what came back, reported bugs, made product decisions, and kept pushing the design. Claude Code handled the implementation in Godot.

The first version was a small game about an unemployed character living in a messy apartment, applying for jobs, preparing for interviews, dealing with a landlord, and trying to get hired before everything fell apart.

Then I kept building it.

The apartment became part of Fenwick Row, a dense neighborhood with moving NPCs, shops, a pub, gym, library, job centre, motel, bikes, benefits, gambling, household inventory, clothing, physical possessions, interviews, fitness systems, and many different ways to spend or waste a day.

From Experiment to Sandbox

The original question was:

Can I make a game if I refuse to write any of the code?

That constraint changed my role. Instead of opening a script and fixing a function, I had to behave like a game director, product owner, systems designer, and QA tester. If something felt wrong, I had to describe the behavior I wanted clearly enough for an implementation agent to reproduce it.

As the game grew, a more interesting design question replaced the original experiment: how do you make a systems-heavy sandbox feel like a life rather than a spreadsheet of stats?

A rule emerged:

If something important happens, try to let the player actually see or do it.

That principle shaped the later game.

Making Systems Physical

The first-person body is visible. A real mirror uses a reflected camera rather than a decorative texture. Clothing bought in stores appears on the character and in the mirror. A bathroom scale wakes and settles when the player stands on it. A bicycle stays where the player leaves it and can be locked or stolen.

Several mechanics that began as text were rebuilt as actual interactions. Blackjack became a table with cards, chips, a shoe, legal actions, and dealer behavior. The gym gained minigames. Shopping became a shared catalogue interface. Inventory became a proper bag. A bulk energy-drink order arrives as a physical box that can be carried into the apartment and stored as individual cans.

The neighborhood uses dynamically generated AStar3D navigation. Twenty-eight scheduled NPCs physically move between shops, benches, the library, café, job centre, and pub instead of teleporting to schedule points.

Removing the Quest System

A major pivot was deleting the quest framework.

Rent still matters. Benefits appointments still happen. Interviews still occur at specific times. NPCs can remember debts. But the game no longer puts objectives in the corner of the screen.

Information comes through the world: mail, people, shop hours, schedules, missed opportunities, and consequences.

The player can skip an interview, gamble through the morning, pawn furniture, buy a bike instead of paying rent, or simply waste a day. The game remembers the result without declaring which choice was “correct.”

That pushed the project closer to the 3D Stick RPG-style sandbox I actually wanted.

State Ownership and Testing

As systems multiplied, state ownership became a major engineering problem.

An early design used one shared “busy” flag across sleeping, showering, work shifts, movement, and other routines. A delayed action could finish after another action had taken control — or even after a new game had started.

The fix introduced centralized world ownership and tokenized routines so stale asynchronous actions could no longer mutate newer state.

Testing also had to become more visual. Some interiors were technically correct in code but unusable because important objects existed behind walls. That led to screenshot passes and later an automated doorway sweep that caught shops whose logic said “open” while geometry physically blocked the entrance.

Performance

As Fenwick Row grew denser, performance dropped. Profiling showed that the bottleneck was not the mirror, GPU, lighting, or shadows; it was CPU-side draw submission from thousands of small objects and character meshes.

Renderer-side distance culling, slower distant NPC updates, and avoidance optimizations reduced mean measured frame time from 2.76 ms to 1.81 ms — about a 34% improvement. One problematic street view dropped from 5.25 ms and 5,745 draw calls to 2.17 ms and 2,167 draws.

One counterintuitive result was that removing building facades made performance worse because the facades had been occluding hundreds of interior objects.

Current State

Unemployment Simulator is a substantial local sandbox rather than a released commercial game.

The latest reported build includes the apartment, visible body and mirror, scheduled NPCs, jobs and interviews, benefits, rent pressure, clothing, household storage, fitness activities, blackjack, slots, bikes, shops, food delivery, cats, and save/load. The development state reported 15 test suites and 1,426 passing checks.

The largest unfinished direction is runtime AI NPC behavior. The world movement, schedules, and behavioral interfaces are increasingly structured to support it, but the current NPCs remain deterministic.

The goal is no longer simply to build a game about getting a job. It is to make Fenwick Row deep enough that different playthroughs naturally become different lives.