Wisest Wizard

A game of spellcraft

The Concept:

In Wisest Wizard, you will play as a hapless young wizard as they learn how to perform the art of spellcraft in order to solve puzzles, defeat opponents, and uncover mysteries...

The runes that spells are comprised of are my own invention. They come together to form words, phrases, sentences, etc. Spells will take the form of programs made up of commands that these runes can perform. The setting is planned to be a wizard school, in order to teach players how the ins and outs of this system work.

Milestones:

The focus thus far has been on the editor that will allow you to combine different runes into words. So far we have:

• An interactable object that opens the editor UI
• An inventory that holds "scrolls"
• A menu of available runes
• Rune combination functions, including:
• Simple overlap
• Nesting
• Raising
• Rotation
• Scaling
• Shifting context with the "Doh Stick"
• Complex Nesting (WIP)

Code exists to show the proper name of a rune if it's created. At this time, that code doesn't do anything, because I've removed all the proper names in order to refine the ID combination and JSON formatting, as well as add complex nesting.

Some things are able to be saved and loaded to and from the scroll editor, but it's still a WIP.

Plans:

I've made great progress with the Save and Load features of the scroll editor. To the point that a structure such as a.(b.c,d.e) will save and load properly-- although as of November 20, 2025, I've edited the way the IDs are generated so that structure would now be written as a.((b.c),(d.e)) and it's better because it's easier for the parser to tell what to operate on first. I figured I'd note the change here.

Trees currently seem to work. I don't know how many layers deep I can go, I'll need to stress test that, but it should theoretically work. Nested structures are more complicated, and there's a bug where if you shrink a set of runes too much some runes will switch from being a simple overlap to being nested, and that has to do with the way nested structures are created-- which is by doing the overlap operation close to the center of the object. When the object is forced into that radius, it becomes a nested child. I'll fix that.

Improper nestings are still going to be a problem. Finding exactly how to dynamically resize the boundaries to fit the runes inside is hard. I've also got to make sure that they don't break anything else, because they're technically the same type of object as the runes, but they're processed in the code differently. It might prove better to make the left and right ones separate objects? I'm still looking into it.

Once the editor is complete, the "hard" part starts. The rune combination IDs will be used as syntax for the "programming language" that will be used for the spells. The reason that's so difficult is that, well, it's making a programming language. That's hard. It's an esoteric language by necessity, the rune IDs are pretty incomprehensible but technically when the language is finished you'd be able to program with those independantly, save for the actual planned integrations with the game. I've been reccommended to look into Total Functional Programming because I'd mentioned that I want to avoid infinite recursion, among other things.

I expect that creating all the gameobjects and properties that are editable by the spells is also going to be a real challenge. It'll require a lot of thinking and planning, but luckily at that stage it should be possible to just modularly add in new possible spell outputs whenever I find one we're lacking.