Building the first real slice of Beyond the King's Road
The goal for this prototype is simple: make a small fantasy RPG that feels playable early, keeps its scope honest, and uses systems that can grow without rebuilding the whole game every time a new item, enemy, or quest gets added.
Why this game exists
Beyond the King's Road started from a specific kind of RPG itch: an older adventure structure, but without the weight of a giant party, random encounter grind, or endless content promise. I wanted the game to feel like leaving the safe path and finding strange little pockets of a kingdom that has more going on than the road signs admit.
That pushed the prototype toward a focused design: one playable character, visible enemies, one-on-one battles, free movement, and a physical inventory where what you carry actually matters. The first milestone is not "build a massive RPG." It is "make a small vertical slice that proves the game has a spine."
The current development slice
The Godot prototype is already built around data-driven content. Areas, items, enemies, shops, quests, and dialogue live as JSON data, while the runtime reads that data to spawn exits, NPCs, chests, visible enemies, shops, and objective markers.
That matters because it keeps the project flexible. A new potion, slime, chest, shop stock list, or quest step should not require rewriting core game code. The game needs to be easy to expand while the world is still being discovered.
Free movement, readable interactions, visible enemies, one-on-one combat, a quest chain, shops, saving, area transitions, and a physical inventory that turns gear and supplies into real space decisions.
Physical inventory is the hook
The inventory is not a simple number stack. Items have shapes. A long item can take multiple cells. Some items rotate. Potions do not magically become one pile of "3." If you find three potions, that means three physical objects competing for space.
The player has different containers: on-person space for ready gear and battle supplies, a gear pack for equipment, and an item bag for general supplies, keys, quest items, and treasure. That creates a small but important question before combat: what did you actually bring within reach?
Combat without random encounter noise
The current direction avoids invisible random battles. Enemies exist in the world, and touching one starts a focused one-on-one fight. That keeps danger readable and gives the player more control over when to push forward, retreat, prepare, or spend resources.
Battles now flow through a result screen before returning to the map, showing gold, XP, recovered items, level progress, and skill point gains. It is a small detail, but it makes each fight feel like an actual event instead of a disposable interruption.
Making the dashboard useful
A lot of RPG prototypes bury the useful information in separate menus too early. For this one, I wanted the main dashboard to carry the player: current objective, world map context, area map markers, encounter prompts, journal notes, and inventory access all live close to the main view.
The quest system can mark a target area on the world map and a more exact objective position on the area map. That means the player can stay oriented without opening a full journal every few steps.
What I am learning from the build
The biggest lesson so far is that a small RPG still gets complicated fast if the systems do not agree with each other. Inventory affects battle readiness. Quest rewards have to respect available space. Shops need sale protection for quest items and equipped gear. Saves have to preserve world state, claimed rewards, opened chests, and quest progress.
That is why this first slice is so system-heavy. The art can improve later. The map can expand later. But if the rules for carrying, fighting, saving, buying, selling, and questing are solid now, the game gets easier to grow instead of more fragile with every new idea.
What comes next
The next useful step is to polish one route until it feels like a real playable sample: a starting area, an objective, a few visible threats, a meaningful inventory choice, one shop or service point, and a small payoff for leaving the road.
After that, the prototype needs better presentation: stronger character art, cleaner environment tiles, more readable combat feedback, and a public-facing build that shows the game in motion instead of only screenshots.