Blade Quest: Prototyping a Dream Project with AI

Not every idea works as well in practice as it does in theory. Blade Quest began as an ambitious concept, a branching fantasy adventure that combined classic storytelling with modern development tools. The goal was to create a narrative game where players could explore a rich imaginary world, making meaningful choices along the way.

At first glance, it looked like everything a fantasy fan might want. But the true value of this project was not the game itself; it was the opportunity to prototype an idea quickly. With the help of AI tools, the project moved from concept to playable demo in a matter of weeks. That process made one thing clear: wordy interactive fiction does not suit the habits of modern players. In an environment shaped by short attention spans and fast feedback loops, deep narrative structures can struggle to find their place.

None of this would have been obvious without building and testing the prototype. This article looks at how Blade Quest was developed, the AI technologies used throughout the process, and the lessons learned about rapid prototyping, interactive storytelling, and how to avoid the mistakes made along the way.

Why Blade Quest?

World building runs deep in the veins of tabletop gamers, and for some, it starts early. The roots of Blade Quest went back to a twelve-year-old version of myself, a young Dungeon Master scribbling quests into spiral notebooks—blending imagination with dice rolls and dreaming of worlds yet to be built. Long before AI tools and digital platforms, the seeds were planted through hours spent navigating the labyrinths of Ultima III, The Bard’s Tale, and Dragon Warrior, or battling pixelated fiends in Final Fantasy and Hero Quest. RPGs weren’t just games—they were formative experiences.

Equally formative was a deep appreciation for choose-your-own-adventure books, considered by many an ideal medium for interactive storytelling. These books invited readers not just to observe a story, but to shape it. In French-speaking communities, their popularity was amplified by beloved series such as Livre Dont Vous Êtes le Héros (Choose your own Adventure), which found their way into classrooms and bookstores across Quebec and Europe alike. They offered a framework where every decision mattered—a format that would leave a lasting impression.

The dream to one day create a fully-fledged RPG never faded. But dreams often evolve alongside technology. Blade Quest, in its current form, is the product of years of experiments and prototypes: an idea that took many shapes across different programming languages. One particularly unique version even lived briefly on the now-defunct Sifteo Cubes, showcasing an early attempt to combine storytelling with novel hardware.

The modern incarnation of Blade Quest came from a simple question: what happens when age-old fantasy storytelling meets modern AI tooling?

The World of Draven

Blade Quest is set in a world shaped by political tension, diverse cultures, and the lingering effects of a devastating magical war. The ideation process started with a simple prompt:

Let’s build a world around three warring factions, and a neutral town in the middle. The factions will each be distinct in their culture and organization: one, a kingdom of knights built on honor and ruled by a king; another, a secretive society of wizards governed by a ruling magical class; and the third, a technocratic, steampunk-inspired nation led by an elected council. Surrounding them are four neutral factions: the Owls, mysterious forest-dwellers; the Dwarves, mountain merchants who sell weapons to the highest bidder; the Dragonborn, noble warriors with ancestral ties to dragons; and a commerce-driven religious order rooted in trade. The world is still haunted by a past war over magic, and all factions are now vying to control what remains of it.

From that prompt, the world of Draven was built using a combination of AI-generated content and manual iterations. The AI provided region names, faction histories, and early political structures. These outputs were then edited to better match the tone and goals of the project. Key locations like Silvercross, a neutral city focused on trade and diplomacy, emerged from that process. The result is a setting that feels consistent and complete.

The World Engine

Blade Quest was designed with the long-term goal of supporting multiple adventures. Players would create a character and travel across the world of Draven, completing quests as they went. From the beginning, the backend needed to support modular content, with a focus on making new adventures easy to add and manage.

The first iteration of the backend combined several familiar tools. A Flask service handled the front-facing API, Django was used for content management, and SQLite served as the database. Each component were chosen for its ease of use, especially when it came to rapidly building a prototype. The structure itself was simple, with two main constructs: players and adventures. Each adventure was made up of events, and each event could include up to three choices. For early testing, the game was hardcoded to use player ID 1, which allowed for continued focus on the adventure themselves.

Creating individual models in Django for events and choices was straightforward, and spinning up a basic admin panel to manage them took very little effort. However, embedding events directly within adventure screens proved more complicated. Building a clean interface to manage nested event trees inside a single view introduced too much complexity. That part of the design was eventually abandoned in favour of simpler, separate editing screens.

Communication with the Javascript frontend was handled by a lightweight Flask API. It read directly from the Django-managed SQLite database and returned the appropriate event data and available choices. For the most part, the system worked well.

Interface Design

Frontend development for Blade Quest relied heavily on AI support as this author has limited experience with React. The design approach was simple: present a single card on screen with an event image, narrative text, and up to four possible choices. This structure was easy to manage and reflected the core goal of Blade Quest—interactive storytelling with clear player decisions.

The frontend stack used React 19 with Axios for API calls. The card component serves as the main display element, showing the current scene along with choices that called back to the API. Each button on the card triggered a new GET request to fetch the next event, updating the state of the application. The UI was styled using basic CSS, with a focus on a clean layout and legibility. The background used a wood texture to give the game a rustic, fantasy feel.

Routing was kept minimal. There was no menu or progress tracking, just a single path from adventure start to conclusion. The design was intended to feel more like flipping through a digital storybook than navigating a modern game interface. While React was helpful for rapid prototyping, it often felt limiting for this type of interactive fiction. Adding special effects or custom transitions was more complicated than expected, and at several points, switching to a framework like Phaser was considered for better control over visuals and state management.

Storycrafting

The first adventure in Blade Quest was designed to serve as a First-Time User Experience (FTUE). The goal was to onboard the player on to the core mechanic of every choices shaping the journey. From the outset, the story was structured to guide players through different types of interactions including dialogue, exploration, puzzle solving, and conflict.

The narrative followed an orphaned hero on their sixteenth birthday, leaving the safety of their village to earn a magical blade. This setup allowed the story to focus on personal growth and discovery, giving the player meaningful decisions in a low-stakes environment.

Designing the story flow was still complex. While ChatGPT was useful in writing scenes and generating branching options, it often struggled to maintain continuity once the number of paths grew. To mitigate this, each story event was assigned a unique ID, which made it easier to reference specific events and outcomes. Branching logic was mapped using Draw.io, providing a visual diagram of the full decision tree. This graph could then be exported as XML and fed back into ChatGPT when needed, helping it keep track of the narrative structure.

Visuals were another important part of the storytelling process. The goal was to generate all in-game graphics using AI, and Layer.ai was used extensively to create locations, backgrounds, and environments. The biggest challenge was consistency: getting each image to look like it belonged in the same visual world. After many iterations, a somewhat unified style was achieved for locations, but characters proved far more difficult. For those, ChatGPT produced better results when paired with careful prompting, detailed examples, and a lot of patience. While not perfect, the output was consistent enough to support the narrative and bring scenes to life.

While this wasn’t the final version of the adventure, the prototype served its purpose. It proved that a guided narrative could be built and tested quickly, setting the stage for more ambitious stories. Several new adventures were already in early development, including a missing child investigation in Silvercross, a lost merchant caravan near dangerous roads, and a magical disturbance linked to a stolen spell book. Each aimed to introduce different types of challenges while expanding the world of Draven. Together, they hinted at the broader potential of Blade Quest as more than a one-off experiment.

Giving the Game a Voice

As the Blade Quest prototype took shape, it became clear that something was missing. The text alone delivered the story, but it lacked the atmosphere and emotional weight needed to bring the world to life. To address this, voice narration was added using ElevenLabs, a tool that generates realistic AI speech from text. This made it possible to give each scene a voice without a full recording setup or cast of voice actors.

The integration was straightforward. Each narrative block was fed into ElevenLabs, producing audio clips that matched the tone of the story. It was a simple addition that immediately made the game feel more complete.

What worked and didn't

Blade Quest succeeded as a prototype. The project moved from concept to playable in a matter of weeks, powered by a modular backend and a set of flexible tools. AI was used across every part of development: writing scenes, building the UI, generating artwork, and voicing narration. This made iteration fast and development lightweight. The stack, while basic, was effective. Flask and Django made it easy to test ideas, and the structure was clean enough to support additional adventures with minimal changes.

Problems started to appear once the story began to scale. Managing branching logic became difficult. While scene IDs and flowcharts helped, syncing the narrative structure between the diagram and ChatGPT required too much manual work. The model would often lose context or overwrite branches it had previously generated. A tighter integration between charting tools and ChatGPT would likely help. Ideally, the story graph and the model should share a single source of truth, reducing desyncs and cutting down on repetitive input.

The Django admin also became a bottleneck. While useful at first, it wasn’t designed for large-scale narrative editing. Content entry slowed down significantly as the adventure grew. In hindsight, a better option would have been a structured Google Sheet, connected to the database using a sync service like FiveTran. This would allow for faster data entry, simpler versioning, and better collaboration. The second prototype moved to a PostgreSQL database hosted on Supabase, which helped, but the workflow still needed refinement. Combining this approach with a live story map would resolve both technical and structural friction.

The final challenge was more fundamental. Narrative games demand attention, but modern players often engage in short, fragmented sessions. Long scenes with slow pacing don’t hold up well. Any future attempt would need to ensure that scenes are consumed in five seconds or less. This shift would significantly increase the volume of content needed, putting even more pressure on scalable writing, better tools, and tighter production pipelines.

Even with these challenges, Blade Quest delivered what it needed to. The prototype exposed the difference between an idea that sounds good and one that actually plays well. It also highlighted how important it is to test early, especially in narrative design. AI can accelerate development, but it doesn’t remove the need for critical iteration. For creators exploring branching stories or experimental game formats, the real value is in building fast, testing often, and being ready to change direction when needed.