Quest for the Grail

• 

  Rest, shop, craft, and then choose your companions and equipment before heading out.

• 

  Random encounters offer different solutions based on equipment, learned skills, resources, and how much risk you are willing to take.

• 

  Push deep enough into the Old Forest Road and you can discover a hidden village with new services, quests, crafting, and resupply options.

• 

  Some discoveries permanently expand future expeditions - this encounter can teach Arthur how to fish.

• 

  Fishing is an unlockable minigame that provides raw fish for cooking and another way to stretch dwindling provisions.

• 

• 

  Active-time party combat combines action gauges, enemy intents, Faith-powered abilities, equipment, consumables, statuses, and injuries.

• 

• 

  Returning safely secures expedition discoveries and rewards, improving the next attempt and letting the company push farther.

Inspiration

Quest for the Grail started with a simple idea: combine the expedition survival and resource decisions of games like The Oregon Trail with Arthurian myth and active-time party combat.

I wanted repeated expeditions to tell their own little stories: prepare in town, head into an increasingly dangerous forest, find something valuable, and then face the most important decision of the run - keep going or turn back while you still have enough provisions and health to make it home.

What it does

Quest for the Grail is a portrait-oriented Survival & Resource Management prototype set in Brocéliande.

The primary playable route is the Old Forest Road. Each expedition begins in the village, where you can buy supplies, craft equipment, cook provisions, rest, choose companions, configure your loadout, and decide how much you are willing to risk.

Once on the road, the game becomes a push-your-luck survival journey. Provisions are consumed as you travel, injuries persist, encounters can help or hurt you, and anything found during the expedition remains unsecured until you return safely.

Repeated expeditions gradually open new possibilities rather than simply awarding XP. Players can discover equipment, recipes, knowledge, companions, quest items, better supply options, and new locations.

The prototype includes:

• Randomized expedition encounters with choices, rewards, hazards, dialogue, and combat.
• Active-time party combat with abilities, Faith, equipment effects, status conditions, injuries, consumable items, enemy abilities, bosses, and companions.
• Camping, resting, cooking, crafting, shops, persistent injuries, treatment, inventory management, and unsecured loot.
• A fishing minigame that can be learned from an encounter and then used at fishing locations as an additional source of provisions.
• A hidden forest village discovered deep into the Old Forest Road, with its own inn, merchant, druid, crafting, resupply, dialogue, and quests.
• Character sprite-sheet animation support for idle, walk, attack, and ability-specific animations.
• A native Web Audio synthesizer used for the game's music and sound effects without requiring conventional audio files.
• A built-in Traveler's Guide explaining the major systems.

Additional Brocéliande routes and campaign progression are present, but the Old Forest Road is the route that received the majority of the prototype's content and balance work.

How we built it

The game was developed primarily by prompting OpenAI Codex (mostly Luna), with my role focused on directing the design, testing the results, deciding what worked, and repeatedly changing course when something did not.

A working version of the main expedition loop came together very quickly. After that, I deliberately spent time building tools that would let me test the game rather than relying entirely on manual play.

One of those is a deterministic simulation system that can run individual expeditions or entire campaigns using different player strategies. Simulated runs can then be opened in a full browser replay viewer that reconstructs the expedition, encounters, combat, camping, town preparation, and resource changes.

The game also has a separate local Content Editor that can author most of the data-driven game without manually editing source: encounters, enemies, abilities, loot, dialogue, shops, locations, recipes, injuries, audio definitions, image assets, character animations, and more.

The simulator is available in the prototype with ?sim=1, and development/debug tools with ?debug=1.

Challenges we ran into

The biggest challenge was scope.

Once the basic systems were working, it became extremely tempting to build every Brocéliande expedition at once. Doing that made each route shallower, so I eventually concentrated most of the remaining time on turning the Old Forest Road into a complete repeated-expedition experience.

Balance was another major challenge. Provision consumption, injuries, combat damage, cooking, equipment, companions, resupply, and encounter randomness interact in ways that are difficult to judge from a handful of manual runs. This is what pushed me to build deterministic simulations and replay tools early, and those tools exposed several strategies that looked reasonable on paper but failed badly over repeated campaigns.

Presentation also required far more iteration than expected. Scrolling panoramas, foreground layers, sprite-sheet dimensions, character anchors, combat formations, encounter transitions, and small portrait displays all created problems that only became obvious when repeatedly playing the game.

Audio created a different problem: file size. Rather than spending a large portion of the submission budget on music and SFX assets, I built a lightweight native Web Audio synthesizer and authored the soundtrack as data.

Accomplishments that we're proud of

I'm happiest with the expedition loop itself. Going out a little farther, finding something new, deciding whether to risk another few stadia, and eventually returning with something that makes the next journey easier became the part of the prototype I kept wanting to test myself.

I'm also proud of the development tooling around it. The simulation/replay system made it possible to test balance changes across hundreds of runs while still being able to open one specific failure and watch exactly what happened.

The separate Content Editor also became much larger than originally planned and turned most of the game's systems into content that can be authored without touching runtime code.

What we learned

The biggest lesson was how dramatically AI changes the cost of trying an idea.

Several systems were implemented, tested, substantially changed, or removed within a single day. That made it much easier to treat features as experiments rather than commitments.

It also reinforced something less new: having code quickly does not eliminate the need to play the game. Many of the most important improvements came from noticing that something technically worked but felt confusing, repetitive, too safe, too punishing, or simply looked wrong on a phone.

AI made iteration much faster. It did not remove the need to decide what was worth iterating on.

What's next for Quest for the Grail

I would like a full game to expand this structure across a much larger Arthurian journey: additional regions, legendary characters, branching discoveries, companions, stranger supernatural encounters, and a complete search for the Grail.

The part I would preserve is the structure at the heart of this prototype: prepare, venture into the unknown, decide how much to risk, return with what you learned, and go farther next time.

Built With

• javascript
• python