Building a Custom AI Companion for Breath of the Wild
Zelda: Breath of the Wild has over 150 shrines, roughly 120 combat trials, and enough side quests to fill three hundred hours if you count every single NPC request in Hyrule. Most walkthroughs I've seen are either static wikis that haven't been updated since the Switch patch of 2020 or video guides where someone screams through forty minutes of footage without pausing. Neither format works when you're standing at the foot of Death Mountain at 2 AM in game time, your character is freezing, and you need to know whether the next shrine requires fire-resistant elixirs or heat armor. That's the gap an AI guide bot fills. The basic approach is straightforward. You take an LLM with web search capability, load it with structured data from the game, and give it a interface that accepts natural language questions and returns location-based answers. The tricky part isn't the question processing. It's making sure the bot knows the difference between "Goron City" and "Living Rock Road" and doesn't tell you to use Rubbery elixirs when the actual requirement is Heat food. I spent about six weeks building this out for personal use, and the first version was essentially useless because I hadn't accounted for how the game's region boundaries actually work. I started by pulling raw data from the Legend of Zelda wikis—shrine locations, trial requirements, enemy spawn tables, material drop rates, and weapon durability stats. That came to roughly 4,200 entries across seventeen categories. I then organized everything into a structured JSON format with a consistent schema: each entry had a type field (shrine, quest, enemy, material, location), a region field matching the in-game map zones, coordinates where available, and a tags array for filtering. The schema design matters more than the volume of data because an LLM can reason over a clean five-hundred-entry dataset better than a messy thirty-thousand-entry one.
One thing most people miss when building these guides is the distinction between static and dynamic content. Shrines don't change. Enemy placements do. The Bokoblin camps on the map are fixed, but patrol routes shift based on in-game time and weather conditions. My first build included only the static layer, which meant the bot would point you toward a camp that had already moved to a different ridge after you'd cleared it two days earlier in your playthrough. I solved this by adding a "last known state" field to each dynamic entry and tracking whether the player had triggered the encounter. If the bot detected a prior flag, it would suppress that suggestion and fall back to the nearest unencountered option instead.
The interface layer
I went with a simple web chat interface that runs locally on port 8080. No auth, no database backend, just a local-first design. The frontend sends a message, the backend chunks it through a retrieval-augmented generation pipeline, and returns the top three relevant entries ranked by region relevance first, then tag overlap second. The chunking uses a hybrid approach: exact keyword matching for item names and shrine titles, then semantic embedding for contextual queries like "a shrine near a river where the water flows east." For the embeddings I used a small localized model rather than reaching for an API-based solution, which keeps the whole thing running offline once the initial setup is complete. The region boundary problem I mentioned earlier cost me about three full days of debugging. The issue is that Hyrule's map has overlapping zone labels. "Great Plateau" technically contains the "Hyrule Field" border region in the game's internal data, but the wiki lists them as separate zones. When the bot received a query like "where is the nearest shrine from the Great Plateau," it sometimes returned results from Tarrey Town because the vector embedding saw them as semantically close. I fixed it by hardcoding region priority weights: when the player's reported location falls within a plateau boundary, the bot filters out all non-plateau results before ranking. This isn't elegant, but it works and it doesn't require retraining the entire embedding model.
Get the Full Details
What actually makes this useful compared to a wiki
The main advantage is conversational reasoning over structured lookup. A wiki tells you that the Owa Daim shrine requires a Rubbery Elixir. An AI guide bot can tell you that the shrine requires a Rubbery Elixir, explain how to brew one using Froggy Leg and a Critter Crisp, identify which area in Hebra has the highest frog spawn rate during rain, and then check the current in-game weather at that location to recommend the optimal farming time. It's a matter of layering. Each layer adds about two to four seconds of response time, but most queries only need one or two layers depending on how specific the question is. I also found that adding a weight system for difficulty curves changed how often the bot became actually helpful versus mildly irritating. Early in my playthrough, I asked the bot for a "good spot to find hearts" and it recommended the Akkala region. That's technically correct—there are fifteen heart containers available there—but it's not useful advice if you're level one and the region is populated by Lynels and Moldugas. I added a scaling weight based on the player's approximate progression stage, inferred from the number of shrines completed. Once the bot could differentiate between early-game and late-game recommendations, the output quality jumped noticeably. It went from answering literal questions to answering the questions I was actually trying to ask.
Limitations and failure modes
Here's what doesn't work. The bot cannot reliably track your inventory in real time unless you manually update it. There's no legitimate API hook into BotW's save data that reads your current items. Some people claim you can parse the .sav files, but those are encrypted on Switch and the encryption keys changed between the original release and later patches. On PC with emulators, the situation is slightly better but still unreliable because the save structure varies by emulator version. So the inventory feature I built—where the bot filters recommendations based on what you currently carry—is purely manual input. You type your items, and it does the matching. It works, but it's friction that makes casual use impractical. Another hard limit is the weather system. BotW's weather is semi-random on a per-region basis. The bot can't predict tomorrow's weather in Faron because the game doesn't expose that information through any accessible means. It can only pull from the current in-game clock and make probabilistic recommendations. When I asked it "should I head to Eldin tonight?" it would factor in the current humidity value and estimate the chance of rain, but that's an approximation, not a guarantee. Players who treat the probability outputs as certainties will waste travel time. I learned this the hard way after three consecutive trips to the Gerudo Highlands where it rained every time despite the bot predicting clear conditions. There's also the matter of spoilers. The bot doesn't know what you've discovered. If you ask "where can I find the master sword?" it will give you the location regardless of whether you've already found it or whether you're completely unprepared for the trial that requires it. I added a soft spoiler toggle that checks your shrine completion count against the master sword's approximate placement in the progression curve, but it's a rough heuristic. The only reliable spoiler protection is manual mode where you confirm you want the answer before it's displayed.
Setup details
The tool runs on Node.js 18 or later. The core stack is the local embedding model for vector search, a lightweight FastAPI server for the chat interface, and a Python script that handles the JSON data loading and schema validation. The total setup time from a clean machine is roughly forty-five minutes if you have the dependencies pre-installed, or about two hours if you're building the environment from scratch. The model files alone take up approximately 1.2 gigabytes, and the full dataset runs about 340 megabytes compressed. I host it at a local address and access it through a browser while playing. The response latency averages around 800 milliseconds for simple queries and 2.3 seconds for complex multi-layer requests. That's fast enough to keep the flow of exploration going without breaking immersion for more than a brief pause. The interface itself is deliberately minimal—no animations, no color themes, just text input and results. I designed it this way because anything that draws attention away from the game screen creates a friction point that discourages regular use. If you're looking for something already built rather than constructing your own, the open-source implementations in the BotW modding community tend to fall into two categories: Discord bots that connect to a central server (reliable but require internet and account setup) and offline CLI tools that run entirely locally (fast but lack conversational depth). The Discord route worked well for me during group play sessions where multiple people were asking different questions simultaneously. The CLI version is better for solo runs where speed matters more than conversational flexibility. Neither handles the inventory and progression tracking that my local build does, which is why I kept going back to the custom version even after finding both alternatives.
