Good writing has one central focused topic. But, a lot has happened in the last 2 weeks, so this is a triple-topic blog post.
These past two weeks mark my first stretch back working full-time on Archmage Rises in quite a while.
I put out a significant bug fix patch with a lot more fixes than that short list conveys.
Then I focused on the most foundational work the game needs.
Turning Down Contract Work
Over the Christmas holidays, a studio reached out to hire me as a consultant. At first I said yes. Certain income is nice! But the more I thought about it, the parameters of the deal just didn’t feel right.
One consideration was it would steal energy and attention from Archmage Rises, mainly around mental context switching. The kind of background drain that does not show up on a timesheet. In the end, I passed on the offer.
It was a risky choice, but my wife and I feel it was the right one for now. I want my attention fully on this game.
Macro Game Loop
For our purposes I’ll define a macro game loop as “What am I doing and why do I want to do it?”
Starting Jan 5 my main effort is on the macro game loop. I have been working through a systems-driven approach for creating large, persistent problems in the world that the player has to respond to over time.
The game must answer this question:
“What gets worse if the player does nothing?”
Most of the games I play the answer is simple: “nothing.”
Archmage Rises is different and I have to bring that difference to the forefront.
To make design discussion easier and more focused, I spun up a dedicated Design Discord channel and started posting questions and design examples there, this pairs alongside the Real Time Dev blog where I’m posting almost hourly as I work.
For those that prefer Steam, I posted design discussions on Steam forums. I check these threads each morning as I start work.
Early feedback has been encouraging. The direction feels right.
Threat System Design
For the first time in this project history, I’m sharing an internal design document. I didn’t know Confluence could do that!
You can read the real design doc of what I’m attempting to build (with good formatting!) and it gets updated whenever I make changes.
In software we talk about features as “user stories”. I think a story is a better way to describe a system and convey it’s features and feels better than a series of logical bullets.
I think about the threat system through the concrete story of a Spider Queen.
The Spider Queen
A spider infestation slowly converts a human region into a breeding ground. The queen is an amoral biological force optimizing for reproduction and safety. The player hunts her by cornering her by destroying her location options.
I’m just highlighting a piece of the design here, I think this bit about the Threat Escalation explains a lot.
Threat Escalation
Threat Moves provide progress along the Threat Track Foundation → Aggression → Conquest → Domination
However, Escalation on Threat Track is gated by certain requirements.
Cannot enter Phase 3 Conquest until N sites are Infested
Cannot full assault a Town until a minor attack is performed on it
Queen cannot enter Phase 4 Domination of attacking the capital until she conquerors a Town
This allows the player to block the Queens progress through defensive actions
After sharing the first macro threat example, I spent the next few days incorporating feedback and testing the design against another scenario, a goblin warband. Once the ideas felt stable, I shifted from pure design into technical design of classes and systems. I think I found a way to implement the threat tracking in a way that avoids keeping data in the save file and instead making it more systemic logic driven. This makes it safer for save file migration across updates.
I considered the design phase complete and started to code the Spider Queen threat.
Then reality hit.
Pre-req: Regions
There is no way around it, the threat system depends heavily on a map made up of Regions, which in turn requires reworking how the world map is generated. This is a system I am not deeply familiar with, so there is both learning and refactoring involved.
I’ve known I had to implement Regions for a while, you can read the design goals in this dev blog:
https://www.archmagerises.com/news/2024/3/9/developer-update-regions
This week:
Created a new, simpler, cleaner way to store map data and render it. All the logic was on the renderer, when it went to draw a hex is when it decided what kind of terrain and features it had. The renderer was hundreds of lines long and overly complex. It is now 12 lines and handles 6 layers of ‘stuff’.
Moved the logic to when the map is created (where it should have been). This setup now allows the player to modify terrain through world spells. Or state changes like a burned down forest or ruined village.
Added 12 new terrain types, like shallow vs deep ocean, badlands, volcanic ground, and jungles.
Created a new region generation algorithm. I’ve only put a few hours into it but I’m already liking the shapes it is making, I see fun in it.
A game world is made up of 5-8 regions.
Here is a WIP screenshot i pasted together for 30x30 region that won’t impress anyone but my mom 😛:
Next step is adding forests and mountains.
Perhaps it is nostalgia, but the mental ‘goal’ for terrain generation is my fond memories playing Ultima V. I found a cool website that has the whole game map on it you can walk around in it. I printed out some of my favorite spots and put them up on the wall to inspire me
Also on the wall is my favorite most inspirational quote from the Steam Forum. What you say matters.
That summarizes where the project is at. I’m excited to hit the Region map generation next week!