Wizard's War - Enter the Labyrinth

Conjured with Codex: A scratch built MMO-scale wizard war where hundreds of players battle across one living, ever-shifting world.

Comment

Inspiration

In June 2025, I created the original Wizard's War around an unusual challenge: how far could I build a game without personally writing a single line of source code? I acted as the designer, director, and tester while the AI models available at the time translated my ideas into a playable prototype.

Exactly one year later, I returned to the same game using Codex powered by GPT-5.6 SOL Ultra. I preserved the original Alpha as a read-only reference and built the new Beta alongside it, creating a practical before-and-after benchmark: the same creator, the same game, and the same creative vision—separated by exactly one year of AI progress.

My goal was bigger than adding features. I wanted to measure the practical improvement of GPT-5.6 SOL Ultra in Codex against the models I used in June 2025. I evaluated its ability to sustain long-term reasoning, design software architecture, debug interactions across multiple systems, optimize performance, iterate visually, and maintain consistency throughout a real codebase.

Wizard's War is therefore both a multiplayer game and a time capsule: a playable snapshot of exactly one year of progress in AI-assisted creation.

## What it does

Wizard's War: Enter the Labyrinth is a browser-based, real-time multiplayer action RPG set inside a living world of shifting stone and rival spellcraft.

Players can create or join multiplayer lobbies, explore the labyrinth and its connected realms, fight rival wizards, battle roaming monsters and shared bosses, discover loot, and develop unique builds from six upgradeable spells. The world periodically transforms around its players, replacing paths, encounters, treasures, and hazards without restarting the game.

Combat includes server-simulated projectiles, critical hits, knockback, physics-driven objects, six-direction gravity, and magical transformations into chickens or rolling chairs. Players can push and carry physical objects, manipulate them with a mage hand, discover hidden passages, enter gravity-defying realms, and fight bosses that use the same authoritative spell system as the players.

Players can enter immediately as guests or create an account to retain their gamer tag, leaderboard scores, and unlocked staffs. Every meaningful outcome—from movement and physics to damage, loot, and progression—is decided by the server, keeping the shared world synchronized and combat fair.

## How we built it

Codex was the project's primary coding environment and implementation partner. I directed the creative vision, requirements, priorities, testing, and final decisions while Codex—powered by GPT-5.6 SOL Ultra—worked directly across the repository to implement systems, investigate bugs, evolve the network protocol, run tests, and optimize performance.

I preserved the June 2025 version as a read-only Alpha and developed the new Beta beside it. This gave the experiment a tangible baseline and allowed me to compare the two generations directly instead of relying on isolated benchmarks or memory.

The game combines a C++20 authoritative server with a TypeScript and Three.js browser client. The server runs the complete gameplay and Box3D physics simulation at a fixed 60 Hz. It owns player movement, rigid bodies, collisions, spells, damage, enemies, loot, progression, transformations, and world events. Clients transmit sequenced, time-stamped player inputs—never trusted positions, physics results, or damage claims.

Box3D is fully integrated across the client-server boundary. The native server and browser use the same pinned physics implementation, compiled to WebAssembly for client-side prediction. A dedicated browser worker predicts the local player, rolling chairs, crates, moving platforms, and mage-hand interactions immediately. The server validates every result and sends authoritative states that the client reconciles using dead-zone, soft-correction, and hard-correction policies.

Player input is sampled at 60 Hz and transmitted at 30 Hz with redundant command history. General world snapshots arrive at 20 Hz, while important rigid-body states are replicated at 30 Hz. Remote players and objects are buffered and interpolated, while local interactions are predicted and replayed against acknowledged server inputs.

The networking layer uses a compact binary WebSocket protocol, spatial interest management, supersedable snapshots, bounded reliable event queues, rate limits, and backpressure handling. Clients receive the closest relevant entities instead of the entire world, allowing the server to support large encounters without unbounded traffic or memory growth.

Shared C++ movement, collision, and geometry code is also compiled to gameplay WebAssembly. This ensures the browser predicts the same walls, staircases, cylinders, archways, gravity directions, and realm geometry used by the authoritative server. Visual effects remain cosmetic and cannot influence gameplay.

Three.js and WebGPU power the primary renderer, with WebGL 2 available as a fallback. A Node backend connects Clerk authentication, Neon Postgres, persistent unlocks, leaderboards, and Stripe-backed cosmetics to the isolated game simulation.

I also created a custom world editor with a real terminal and one-click Codex launcher. From one environment, I can describe a feature, edit structured geometry, update shared game data, run native, WebAssembly, physics, and protocol parity tests, and preview the result inside the game.

## Challenges we ran into

The hardest challenge was making authoritative multiplayer feel immediate. Waiting for every server response would make movement and physics sluggish, but trusting the browser would make combat inconsistent and exploitable. Solving this required input prediction, tick-aligned reconciliation, interpolation, replay of unacknowledged inputs, and carefully tuned correction policies.

Networking full 3D physics was especially difficult. A player expects a pushed crate, rolling chair, moving platform, or mage-hand object to respond instantly, but the server must remain the final authority. The client predicts those interactions locally while the server independently simulates and validates them. Corrections then need to converge smoothly without allowing the client to manufacture motion or ownership.

Keeping C++, TypeScript, WebAssembly, Box3D, rendering, and network representations synchronized was another major challenge. A tiny difference in collision geometry or simulation timing could cause clipping, incorrect impacts, or visible snapping. Shared source data, generated contracts, immutable protocol fixtures, and parity tests became essential.

The shifting labyrinth introduced a world-scale synchronization problem. The server and every connected client must replace an entire generation of walls, objects, enemies, loot, and physics geometry on the same simulation tick. The next generation is prepared in advance and atomically swapped at an authoritative tick so players never encounter a half-built world.

The broader challenge was directing an AI-built codebase as it grew from a prototype into a deeply interconnected system. Codex could move extremely quickly, which made explicit invariants, automated tests, performance budgets, live browser inspection, and disciplined review increasingly important.

## Accomplishments that we're proud of

The accomplishment I am proudest of is the measurable distance between the two versions. The 2025 Alpha demonstrated that AI could help one person create a playable game. Exactly one year later, the Beta has become a production-minded multiplayer system with an authoritative C++ server, shared native and WebAssembly simulation, fully networked Box3D physics, synchronized world transitions, multiple realms, accounts, lobbies, progression, and server-controlled bosses.

During development, a 500-bot cast-storm benchmark sustained its 30 Hz simulation target while producing 2,500 simultaneous live spells, with no overruns, disconnects, backpressure losses, or queue drops. A compact protocol revision also reduced network traffic by approximately 47% compared with the earlier full-precision format.

I am especially proud that the same physics and gameplay rules operate across the native server and the WebAssembly client predictor. Crates, chairs, moving platforms, held objects, projectiles, characters, and static geometry can feel immediate in the browser while still being validated by an independent authoritative simulation.

The game has also become an end-to-end experience rather than a collection of technical demonstrations. It includes an opening sequence, authentication and lobby flow, exploration, combat, loot, character progression, major encounters, cinematic realm transitions, and a complete ending.

Because the original Alpha remains intact beside the Beta, the project preserves both sides of the experiment. It is a working, playable record of what one additional year of AI development made possible.

## What we learned

The clearest improvement was not simply that GPT-5.6 SOL Ultra could produce more code. It was the amount of coherent complexity Codex could sustain across C++, TypeScript, WebAssembly, networking, Box3D physics, rendering, authentication, databases, and automated tests.

The models I used in June 2025 were effective at turning individual ideas into features. Exactly one year later, Codex could reason across subsystem boundaries, trace failures through several languages, preserve architectural decisions during large changes, interpret test and browser results, and continue an extended implementation loop without losing sight of the larger system.

I also learned that not personally writing source code does not eliminate engineering—it changes the interface to engineering. My role became defining intent, setting constraints, evaluating tradeoffs, identifying failures, protecting the player experience, and deciding when a result was genuinely complete.

The experiment reinforced that AI performs best when surrounded by strong feedback: clear requirements, shared sources of truth, automated tests, visual inspection, measurable performance targets, and direct access to the complete working environment.

Traditional benchmarks usually evaluate short, isolated tasks. Wizard's War evaluates AI through a persistent creative and engineering challenge where every decision affects a living system. That made the project a personal, practical, and tangible measure of one year of AI progress.

## What's next for Wizard's War - Enter the Labyrinth

The next milestone is opening the labyrinth as a persistent public world and validating the expanded game through larger production-scale playtests. That work will include additional server and browser profiling, balance passes, accessibility improvements, and a smoother first-time player experience.

After that, I want to introduce more realms, bosses, enemies, spell combinations, social systems, seasonal world events, and deeper long-term progression.

I also plan to evolve the embedded Codex workflow into a true world-building copilot. The goal is to describe a landmark or encounter, have Codex implement its structured definition, automatically run collision and multiplayer parity tests, and preview it immediately inside the editor.

Finally, I want to preserve each major version and continue revisiting the same project as models improve. Wizard's War can become a living benchmark—measuring AI progress through what a single creator can actually imagine, direct, and ship.

Built With

Share this project:

Updates