Azhora II: Time, Space, and Demos

Having gone overboard with vibe coding this game, I am trying to pull myself back into earth’s orbit, and what better way than to revisit two of the most fundamental ideas of computer science: time and space.

Time concerns how much work a program does. In algorithm analysis, we often count basic operations rather than seconds, so we can reason about that work without tying the answer to one particular computer.

Space concerns how much memory the program needs. The important question for both is how those requirements grow as the problem gets bigger. In my case, the problem is a continent I keep finding new things to put in.

The reason I feel the need to go back to basics is that I have been in a frenzy of world building, bringing to pixels a world I have been tinkering with in my head for years. Never having expected to get to do such a thing, I suppose it is only natural I went overboard.

I have been having ChatGPT Astra and Claude code for me most of the last week, prompting them on my desktop, or remotely through my phone, to keep them almost full-time building out this world.

I drew the map approximately ten years ago, and a few months ago I used it in my Clashvergence and World Builder projects, refining it with hexagonal organization and Köppen climate classification of hexes. This gave the agents a strong basis for how to shape the terrain and wildlife.

Here is the most recent map version adapted for the game: mcrombie.com/game-azhora-map

The game itself is live, but no promises on its current state as I am in the midst of developmental upheaval. You can check it out here: azhora.onrender.com (or framed in this site at mcrombie.com/games/azhora).

It may be easier to check out this demo I made.

Or this quest where you help a fire wizard slay a giant spider:

Or this other quest where you ride a bear in a race with a chameleon on a unicycle:

Or this more beautiful flyover of the whole continent:

Perhaps I got carried away having Claude Fable make so many videos.

To create such high quality recordings, it ran the real game in a hidden browser, stopped its clock, and advanced it one sixtieth of a second at a time, saving a picture with each step and sending the pictures into ffmpeg to make a smooth 60 fps video, regardless of how slowly the game actually draws (which makes the quality here deceiving). For the flyover path, a script steered the dragon and camera along a preplanned route. For the quests, the game already had a computer playtest that walked through the quest without user input. Meanwhile, whole-page screenshots captured the dialogue and HUD.

This is all well and good for a video, however, for a playable game, I need to track how much work it is doing and whether it is fast enough for a smooth playing experience.

The problem now is that I have expanded both the world and the current quest arc without paying enough attention to the game’s fundamental architecture. In other words, I got sloppy. Now I am taking a step back to take stock and consider where I am ultimately going with the project.

Looking at the directories, I found there was a lot of tidying to be done. Most of the source files sat together in the src directory, with little separation between the game’s reusable systems and the particular places, characters, and quests built on top of them.

Going forward, I want to focus on a single, stable scenario that gives the player a clear path through the game and gives me a manageable place to test its basic systems.

To do that, I am shelving most of the existing quests and skill trees. I am not deleting them, but I don’t want the new foundation to be constrained by everything I have already built. For now, I will work within a sandbox of about five regions, developing the core game loop and a consistent way to track the state of the campaign. Before expanding across the continent, I want to find out whether this smaller version actually supports the kind of game I am envisioning.

This brings me back to time and space. As I add regions, characters, and things for them to do, how much more work does the computer have to perform? How much more information does it need to keep in memory?

For example, how often does the game need to update a character on the other side of the continent? Does a distant settlement need to be loaded in the same detail as the one the player is walking through? Could the game preserve a smaller record of what is happening there without keeping the whole scene in memory?

These are the kinds of questions I want to investigate in the smaller sandbox. The time question is what needs to be calculated, how often, and how that work grows. The space question is what needs to remain in memory, and how that requirement grows. Getting five regions to work will be a starting point. Then I want to think about scaling. Adding a sixth will tell me more about whether the design can scale.

Although reorganizing the directories does not answer those questions, it gives me a clearer starting point for asking them.

Until recently, I have mostly been asking the coding agents what else we can add. Now, I need to spend more time figuring out what all these added features require to make an enjoyable game.

In that spirit, here is one more demo of what I have so far:

Don’t get me wrong though. I still want the whole continent!

But first I’ll limit myself to understanding what it takes to get a good combat system within five regions running and if that can scale.