Inspiration
I’ve been thinking a lot about how we’re naturally wandering back toward old-school terminal interfaces. Games like Zork amazed me as a kid because it felt like I could do almost anything, even though everything still operated within certain boundaries. I’m a huge fan of old-school MUDs, D&D adventures, and good storytelling. When I was ten, I connected through Telnet and played games that way. Grand Adventure Engine draws from all of that: it’s a retelling of an old idea, now guided by an LLM so the world can react when I decide to do something clever, unexpected, or just plain dumb.
What it does
Grand Adventure Engine turns a text-adventure campaign into a shared workspace for players, human Dungeon Masters, and browser agents. Players explore and act through natural language while the AI narrator maintains the story and game state. Meanwhile, a WebMCP-enabled Co-DM can inspect live scenes, search campaign lore, examine characters and quests, message players, and propose mechanical interventions. High-impact changes—such as applying conditions, adjusting health, or correcting suspicious actions—remain queued for human approval, combining the speed of an agent with visible, accountable DM control.
How we built it
We extended an ASP.NET Core and PostgreSQL RPG engine with five browser-native WebMCP tools registered through document.modelContext.registerTool: scene inspection, world search, entity inspection, player messaging, and governed mechanical-change proposals. The vanilla JavaScript dashboard provides a real-time DM console and player view through SignalR, while server-side authorization, ownership checks, typed schemas, bounded searches, audit receipts, and human approval gates protect the game state. The application is containerized, deployed over HTTPS through Azure Container Apps, and backed by automated unit, integration, security, and browser tests.
The original project was build a few months ago, mostly over the course of a week. I sat on it, doing occasional work, and popping in to update it, play with it, or test it on a newly released model. Originally the plan was to set it up for local LLM use only, but it naturally progressed into using Codex OAuth (on a local node) and it worked really impressively and quickly.
When I decided to join the hackathon, I added the admin console, and updated the site to handle the incoming changes. I opened it up to (hopefully) allow the admin to do basically anything they wanted to from Codex.
Challenges we ran into
The biggest challenge was flexibility—specifically, finding the right balance between hands-on and hands-off control. We needed a way for the DM—or God, depending on how dramatic they’re feeling—to step into a scene, rebalance an encounter, influence an outcome, or simply monitor the game to make sure everyone is having a good time. It’s frustrating when you give an LLM a basic command and it simply says “no.” At the same time, even with strict guidance, players will inevitably find ways to break things. I can’t justifiably blame them for that. If a character wanders off the edge of the map, that’s the developer’s problem—not the player’s.
Accomplishments that we're proud of
I’m especially happy that I originally architected this project in a way that could be meaningfully extended for this hackathon. I’m proud that I found a balance between giving players free rein and preserving human control when intervention is necessary. The project is also bootstrapped: I designed it to be inexpensive to operate and straightforward to manage. Finally, I’m proud of how quickly I was able to iterate, incorporating the latest WebMCP guidance into an existing project under an extremely short deadline.
What we learned
The biggest lesson was the difference between having a cool idea, merely bolting WebMCP onto it, and creating something where WebMCP is genuinely useful. This competition forced me to assess ideas honestly and pivot quickly when something wasn’t coming together. ChatGPT provided valuable feedback throughout the process, helping me turn the project into something fun and functional while still aiming for a creative and novel use of the technology.
What's next for Great Adventure Engine
Honestly: playtesting and gathering interest. This is an iterative project, and so far it has only been playtested by me—which means someone else will almost certainly discover an imaginative new way to break it. The plan is simple: playtest, study the logs, fix the problems, and keep going. I’m particularly interested in bringing it into Discord communities, where I can host the engine from my own machine and let the AI respond directly in Discord. That would make it an inexpensive, accessible way for groups to run persistent adventures together.
Built With
- .net-10
- api
- asp.net-core
- azure-container-apps
- c#
- css3
- docker
- entity-framework-core
- html5
- javascript
- openai-compatible
- playwright
- postgresql
- signalr
- webmcp
Log in or sign up for Devpost to join the conversation.