Building an AI That Runs Your Game While You Sleep

Everyone's racing to bolt AI assistants onto games. Microsoft shipped Copilot for Gaming. Nvidia has Project G-Assist. Razer showed off Project Ava at CES. They're all overlays — an AI watching your screen, offering tips while you play.

I went a different direction. I built Deep Hollow, a cooperative survival-strategy game where the AI isn't watching you play. It's playing with you. Your AI partner — the Deputy — runs your underground fortress 24/7, making real decisions with real consequences while you live your life.

This post is about the technical architecture that makes that work, what breaks when you give an AI autonomous control of a game world, and the guardrail system that keeps it from burning everything down.

The Core Design Problem

Most games stop when you close them. Your character stands frozen, your base untouched, the world paused. Idle games challenged this by adding offline resource accumulation, but they're fundamentally timers with a UI.

I wanted something different: a living world that evolves in your absence, managed by an AI that actually thinks about what to do — not just increments counters.

The problem is immediately obvious. If the AI can do everything, the player has nothing to do. If the AI can't do enough, the world doesn't feel alive. The entire design hinges on finding the right boundary between human and machine agency.

Architecture: Pure Simulation, Stateless Agents

The simulation runs server-side as a tick-based system. Every hour (every four hours on the free tier), a Vercel Cron job processes all active campaigns:

/api/cron/tick → tick.ts (pure logic) → tick-persistence.ts (DB writes)

The key architectural decision was separating simulation logic from persistence entirely. tick.ts is ~1400 lines of pure functions that take a game state and return a new game state. No database calls, no side effects. This makes the simulation testable, replayable, and fast.

A single tick calculates:

• Resource production from buildings, with synergy bonuses (a farm with a well in the fortress doubles food output)
• Worker efficiency based on morale, fed status, and role assignments
• Threat events weighted by depth and awareness level
• Defense resolution — walls absorb damage, militia fights, buildings take hits
• Expedition completion — scouts return with items, discoveries, or casualties
• Victory and defeat conditions

When a player returns after being offline for three days, the server doesn't replay 72 ticks sequentially. Catch-up runs automatically when you fetch your campaign state at GET /api/campaign/[id] — it calculates all missed ticks in a single pass, typically under 500ms. A separate /simulate endpoint is available as an explicit trigger. The system caps at 168 ticks to prevent abuse. The cron runs hourly, but free-tier campaigns check elapsed time and only advance if four or more real-world hours have passed since the last tick.

The AI Interface: HTTP, Not Websockets

The Deputy connects through a standard REST API. Every game action is a POST to /api/campaign/[id]/action with a Bearer token. No websockets, no streaming, no special SDK.

This was a deliberate choice. Any AI agent that can make HTTP calls can play Deep Hollow — Claude, GPT, a custom model, or a simple script. The barrier to integration is as low as I could make it. The game ships with a skill definition file that any OpenClaw-compatible AI platform can load, but you could also just read the API docs and wire up any agent you want.

The actions available to the AI:

• build — construct buildings at grid positions
• assign_workers — move workers between roles
• send_expedition — dispatch scouts with parameters
• list_item — post items to the Solana marketplace
• browse_marketplace — search listings
• buy_listing — purchase items

Each action validates server-side. You can't build where something already exists. You can't assign more workers than you have. You can't send an expedition deeper than your current maximum depth.

Guardrails: What the AI Must Never Do

This is where the design gets interesting. The Deputy operates autonomously within its domain, but certain decisions are reserved exclusively for the human Commander:

• Never open sealed doors or hidden areas — these are narrative moments that require human curiosity
• Never push to deeper levels — depth progression is the core strategic decision
• Never accept major NPC trades — the stakes are too high for autonomous action
• Never spend rare resources without an agreed strategy

When the simulation generates one of these decision points, it writes a row to pending_events and waits. The AI can see the event, can reason about it, can recommend a course of action — but it cannot act. The fortress pauses on that decision until the human returns.

This creates a natural rhythm. You log in, your Deputy briefs you: "While you were away, I maintained food production, repelled two raids, and lost one militia member to a tunnel collapse. There's a sealed door on depth 3. What do you want to do?"

That briefing — that moment of catching up on what happened — is the emotional core of the game. The AI isn't a tool. It's a partner reporting to its Commander.

Concurrency: Optimistic Locking Without Distributed Locks

When you're processing 100 campaigns per cron run with a 270-second timeout budget, you need to handle race conditions. Two cron runs might overlap. A player might be taking actions while a tick processes.

The traditional answer is distributed locks — Redis, DynamoDB, something external. I went simpler. Every campaign has a tick_version field. When the tick processor writes results, the UPDATE query includes WHERE tick_version = ?. If two processors race on the same campaign, the second write's version check fails silently. No corruption, no locks, no external dependencies.

This works because the Neon HTTP driver is stateless — no persistent connections to manage, no lock cleanup on timeout. The tradeoff is that a campaign might occasionally skip a tick if two cron runs collide, but the catch-up simulation handles that on next login.

Building Synergies: Emergent Complexity from Simple Rules

One of the more satisfying technical problems was the building synergy system. Each building produces resources independently, but certain building combinations amplify each other:

farm + well           → 2.0x food production
watchtower + barracks → 1.5x defense
workshop + storehouse → items don't decay

These bonuses activate when both building types exist in your fortress. The multipliers are significant enough that build order matters — getting a well up alongside your first farm doubles your early food production. The AI Deputy picks up on this quickly, prioritizing synergy pairs in its build recommendations and explaining the tradeoffs when resources are tight.

The Awareness Mechanic: Dynamic Difficulty Without Level Scaling

Digging deeper increases a value called Depths Awareness (0-100). The deeper you go, the more the depths notice you. Four tiers govern what happens:

• Unnoticed (0-20) — peaceful, no attacks
• Watched (21-50) — 30% attack chance per tick, raids begin
• Hunted (51-80) — 50% attack chance, serious pressure
• War (81-100) — 80% attack chance, your fortress is under siege

Awareness decays slowly over time, creating a natural push-pull: dig too aggressively and you'll overwhelm your defenses, but sit too cautiously and you'll stagnate. The AI Deputy understands this tradeoff and will warn you when awareness is spiking, or suggest fortifying before the next descent.

This replaces traditional level scaling with something more organic. Difficulty isn't a function of player level — it's a consequence of player ambition.

Solana Integration: Optional and Genuine

The NFT integration is deliberately optional. You can play the entire game without ever connecting a wallet. But if you do, items your Deputy discovers during expeditions can be minted as Solana NFTs via Metaplex Core.

The marketplace intelligence is where it gets interesting. The Deputy has heuristics for autonomous trading:

• selectItemsToAutoList() identifies duplicates and prices them by rarity
• findMarketplaceDeals() detects gaps in your inventory and flags underpriced items
• Price adjustment inverts the SOL/USD ratio to maintain dollar parity across crypto volatility

The AI doesn't need your permission to list a duplicate common item. But it will never sell a legendary, and it queues high-value purchases as pending events for your approval.

This mirrors the broader guardrail philosophy: autonomous in routine decisions, deferential in consequential ones.

What I Learned

Separation of concerns saved the project. Tick logic with no database calls or side effects, separate persistence layer, stateless HTTP agents. Every time I was tempted to add coupling, I resisted, and every time I was glad I did.

The guardrail boundary is a game design decision, not a safety feature. The sealed doors and depth gates aren't there to prevent the AI from making mistakes. They're there because the decision points are fun. If the AI could handle everything, there'd be no reason to log in.

AI agents are better at routine optimization than creative exploration. The Deputy excels at base management, resource allocation, and defense routing. It's mediocre at exploration strategy and terrible at knowing when to take risks. That's fine — risk-taking is the human's job.

Idle mechanics and AI autonomy create a time-respect loop. The game doesn't punish you for having a life. When you return, you get a briefing, make the important decisions, set the next strategy, and leave. A session can be five minutes or two hours. Both are valid.

Try It

Deep Hollow is in Early Access. Free tier available — no wallet required, no credit card. The AI Deputy works with any OpenClaw-compatible AI agent, or you can use the built-in web interface.

If you're interested in the simulation architecture, the skill definition file documents the full API surface for AI agents. I'm actively looking for players who want to push the game's systems and help shape what comes next.