AI RIM Backend Update – A Fresh Foundation for Prelude to Chaos

Over the past few months, I’ve been building out the backend for AI RIM: Prelude to Chaos — the first book and the first online browser-based game in the 11-book / 11-game series. The goal has always been a clean, efficient system that can support tile-map gameplay, dynamic NPC conversations powered by Gemini 2.5 Flash, real-time heartbeats, player inventories, faction/quest state, and the deep lore connections between the novels and games.

After a lot of hands-on testing and iteration, I’ve decided to evolve the backend stack to better align with long-term maintainability, performance, and developer velocity as the series grows. This isn’t about any one tool being “wrong”; every choice we’ve used so far has strengths and has served the project well during early prototyping. The shift is simply about finding the combination that feels most natural for the kind of workload Prelude to Chaos (and the rest of the series) will demand.

The New Stack

Database
MariaDB (InnoDB engine)

InnoDB gives us full ACID transactions, excellent concurrency for the mix of reads (tile maps, NPC state, lore lookups) and occasional writes (inventory changes, heartbeat updates, player actions), foreign key constraints to keep relationships clean, and rock-solid crash recovery. It’s efficient enough to run comfortably on a modest VM and scales smoothly if player numbers grow.

API Layer
PHP-CRUD-API

A single-file PHP script that instantly turns any MariaDB table into a full REST API with filtering, sorting, relations, pagination, and OpenAPI docs — all without writing a single route. It’s tiny, fast, and secure when paired with prepared statements and JWT authentication. This gives the Godot HTML5 frontend a clean, predictable way to read/write game state while keeping the backend code surface extremely small.

Management Tool
DBeaver (cross-platform GUI) + phpMyAdmin (optional web interface)

DBeaver for local schema design, migrations, data seeding, and query testing. phpMyAdmin if I ever want a browser-based quick view during dev.

Virtualization Platform
Microsoft Hyper-V (on Windows host)

Hyper-V provides reliable, native performance on Windows, excellent guest integration, and solid shared storage options (via SMB or direct pass-through) that avoid the occasional sync quirks I encountered previously. It’s a natural fit for a Windows-based dev machine and gives clean isolation for the Debian guest VM running the backend.

Operating System (guest)
Debian 13 (Trixie)

Stable, secure, long-term support, tiny footprint, and perfect for MariaDB + PHP. The same OS we’ve been using, just now paired with a more predictable virtualization layer.

Why the Change?

The previous stack (PocketBase + Oracle VirtualBox) was fantastic for rapid prototyping — it let me get a working master_control node, heartbeat service, token propagation, and basic CRUD up and running very quickly. I’m genuinely grateful for how much ground it covered in the early days.

The new choices are driven by a few simple preferences as the project matures:

• Preference for explicit schema control and reliable migrations that survive full resets and backup/restore cycles.
• Preference for parallel read/write concurrency that scales naturally without single-writer bottlenecks.
• Preference for a minimal API surface (auto-generated REST + light custom code only where needed).
• Preference for battle-tested backup/recovery tools that minimize data loss to seconds (mariabackup + binary logs + PITR).
• Preference for virtualization that feels rock-solid on a Windows host with frequent guest reboots and shared-folder usage.

None of these are criticisms of the earlier tools — they simply reflect where my priorities have shifted as the scope of the series becomes clearer.

What’s Next

• Migrate the existing servers, clusters, and related tables from the PocketBase backup to MariaDB InnoDB (script coming soon).
• Deploy PHP-CRUD-API and secure it with JWT (using the same master_token logic).
• Update the Godot frontend to point to the new REST endpoints.
• Test concurrent player actions + Gemini 2.5 Flash conversation calls through the local proxy.
• Write a follow-up post once the backend is live and the first playable tile-map demo is running.

If you’re curious about any part of the stack or want to follow along with the migration code, drop a comment.

Thanks for reading — see you in the Tau Sector.

Neil & Grok