It's on hiatus.
I need more experience with smaller projects before revisiting this ambitious one. Otherwise, I know I'm going to lose the plot in the design/programming process.
TL/DR: It's a waste of time to do any more writing until I have a working game engine with a
fun gameplay loop.
As I've feverishly worked on those smaller projects (and made some good progress), I've learned---finally doing back-end stuff for the first time. (It was way overdue!) I've thought about what The Archmage requires and reached some conclusions.
Gameplay Loop: The Archmage was initially built as a narrative game, modeled after text adventures like Zork. At the time, I didn't appreciate how time-consuming writing could be. (A speedy full-time novelist publishes one novel per year. Never mind the slower writers or the ones working part-time.) More importantly, a written scene has zero replay value, nor does it naturally loop. Good games
demand a core loop to design around. So I've pondered appropriate loops for this game.
Combat: When I envisioned the story of The Archmage, much of it involved magical combat. Mages casting crazy spells at each other. My first instinct was to approach combat just as I did the narrative, by writing prose to describe character actions. My God, was that stupid... I'm not sure I've ever been more wrong about anything in my life. Combat
must be mechanical. Not only does a combat engine scale for larger fights such as grand warfare situations, but it also alleviates the burden of writing each combat scene individually and allows for modularity, swapping NPCs in and out without overhead. My first task will be to develop a combat engine for the game based on the rules of magic that I've already outlined in the prose.
Economy: Economics is not only a planned theme for The Archmage's story, it was always intended as a core game mechanic for climbing the religious hierarchy. A vast open market with free trade, where wealth is the holy measure of status and magic is viewed as a commodity: that is the religious ethos of the Monastery. And the game's world must reflect those values. My next task will be to develop an economic engine for the game. Prices will fluctuate for all items, but not randomly. The engine will check supply and demand for each item individually based on NPC behaviors and world events. If you kill an NPC, it might reduce demand for items they used to buy. Or it might reduce supply for items they used to produce. Implementing this engine will be the most complex task of all, but at least it's a task I'm autistically passionate about.
Graphics: Modern games require graphics. Art is more accessible than ever before with the rise of generative AI and the vast swathes of art freely available on the internet (or for purchase). There's no excuse for modern games without graphics. Working with Ren'Py has shown me the immersive value of artwork, no matter how simple the graphics might be. At the very least, characters and locations will be represented graphically.
Implementation: Here's the tricky part: making the ideas real. Given the features I'm planning, a few things are required for this project to be technically feasible. The first requirement is a robust game engine that can support the back-end customization I'm planning. Twine was never intended for a project with this scope; it was designed for branching stories.
First and foremost, the programming language needs to be low-level. The Archmage's back-end will be some sort of hybrid financial database/wizard simulator data structure, and as the datasets grow larger and larger, speed is going to matter. Imagine warfare with thousands of NPCs casting spells. I've never used a low-level language and I definitely don't trust myself with memory leaks. I've been reading about Rust for memory safety and will be working on a smaller Rust database project in the meantime, inevitably learning the ropes. My fear is the rigidity of Rust. I've heard that refactoring in Rust is an endless headache and larger projects require more foresight in the planning stages (skill issue). But every language is a trade-off. At least with Rust, I'm guaranteed performance and memory safety, despite whatever horrors it may inflict upon my soul. I could try C, but honestly, I may never get the project off the ground with that approach. C++ is apparently a broken language, so it seems my best alternative is Go. (Or maybe Zig, but I don't trust myself with that one either.) Whether I ultimately choose Rust or Go, I need my game engine to support the language.
Godot is the obvious choice. It supports graphics, low-level languages, and has open-source community support. I've heard of gripes and rough edges with Godot, but those issues seems to be even more pronounced with proprietary engines.
These are initial thoughts and I'm still mulling them over in my head, but I'm open to any public insights about game engines and back-end planning. I'm going to release alpha builds of those smaller projects soon. Probably in a month or so.
