27 August 2026
A game I'm building from scratch, mostly to find out how the things I've only ever drawn on diagrams actually work.
My day job is technology leadership and architecture. I spend a lot of time drawing boxes that other people fill in. Rendering, physics, simulation: I know where they go on a diagram, but I'd never had to make any of them work.
Arthur and the Sword Beyond Worlds is where I find out. It's an isometric action-adventure that mixes fantasy and sci-fi, the first in a planned series, written in C# on MonoGame and running on Windows, macOS and Linux.
MonoGame gives you a window to draw in and a way to load assets. Everything else (terrain, water, shorelines, animation, sound, the people walking about) is code I've written rather than an engine feature I've switched on. That's slower, which is rather the point.
Instead of one big map, the world is a growing set of places, each designed by hand and joined up with portals. I build them in a map editor I wrote alongside the game: paint the terrain, place objects and people, draw runs of dry-stone wall, and link a portal here to a spot over there. A second tool checks models and their rigs, because importing a character and hoping for the best isn't a workflow.
Step through a portal and the new area should still feel like the same world, so it inherits things like the climate of wherever it connects from. Branching dialogue works, and a conversation can hand you an item or send you somewhere. Quests exist in the data, but nothing tracks your progress through them yet. That's on the list.
This one changed under me. The plan was 3D terrain with flat 2D characters drawn on top. Nine days in, I replaced the player's sprite with a proper skinned 3D model, and the boar, the eagles and the fish soon followed. Now nearly everything standing on the ground is a rigged model with real joints, loaded at runtime and animated every frame.
The ground is real 3D tiles under an isometric camera. Where grass meets sand meets water, the blend is calculated rather than drawn: the game works out how far each point is from the water and grows a beach to match, scaled to the size of the water. A puddle doesn't get the same beach as a lake.
Water humbled me more than anything else. It started as scripted waves. Then it became a real simulation: a height field moved forward every frame by a wave equation, pushed by wind from a climate model that runs a full four-season year underneath day and night. Then I rebuilt the foam, twice.
It costs a lot more than a scrolling texture, but it's why the sea looks like it's actually moving.
The people in the world run on goals rather than a long list of if-statements. A blacksmith walks to the work table, a woodcutter to a tree. With nothing to do, they wander, or strike up a conversation with a neighbour, more often if they're the gregarious type. When evening comes, the schedule takes over and everyone heads home or to the pub. Anyone mid-conversation is allowed to finish first.
They find their way around obstacles with A* pathfinding over the same map of walkable ground the collision system uses, trying a straight line first, because most of the time that's all you need.
The lesson this project keeps teaching me is that a first fix is often a new bug wearing the old one's clothes.
The world fades out into a ring of extra terrain at its edges, so it never stops at a hard line. Profiling showed that ring was the most expensive thing on screen, because it was simulating water nobody could ever reach. Skipping that took the game from 21 frames a second to the low 80s. But my first attempt to cap the ring's detail just moved the problem: a visible cliff where the detail stopped, one ugly edge swapped for another. The real fix was to keep the detail and fade everything towards the sky across the ring's full depth.
That's changed how I work with AI. Claude Code is very good at getting an unfamiliar technique, a wave equation or a skinning optimisation, onto the screen fast. Deciding whether it's actually right is still my job, and the only reliable way I've found is to turn it on and look. More than once, the commit said "fixed" and the screen disagreed.
I started with a house rule: generate it, don't import it. Trees and stone walls still grow from a hash of their own ID rather than being placed or modelled by hand, and the first sounds were all made in code: wind and rain from filtered noise, fire from crackle and an envelope.
Sound is where the rule gave way. Synthesis got the game making noise in its first week. It never made a beach sound like a beach. So in August I layered in real recordings of wind, surf and campfires, mixed by the strength of the wind and how close you are to the shore, with their own volume controls for weather, water, fire and creatures.
I still like the rule. I just like the beach more.
The Starting Isle in these screenshots is the current build, not a mock-up: a hand-built island, people living through a real day and night, and water and shorelines running at the frame rate that horizon fix was chasing. Portals lead out to areas still under construction.
Physics sits behind an interface of its own, with BepuPhysics plugged in and stepping every frame, but nothing uses it yet. That's the next real step, and probably where it starts to feel like a game with puzzles in it.
I still learn something every time I open it.