The bulk of Foxie’s capabilities will be the ability to script a quest. This won’t be simple event-based triggers, either — our quests are going to be built up, piece by piece, from common components and custom bits alike. But what is a “quest component”?

Quests, if you’ve ever played an RPG, tend to follow a pattern. You do something for someone. You clear a dungeon. You kill the rats in the basement. You rescue the princess, maybe bringing her back to the castle while fighting off more bad guys. The point is, you know what a quest is and what usually constitutes one.

In retrospect, I think the old man knew more than he let on.

In short, we’re going to provide the common pieces. Like Lego bricks, you’ll be able to build up quests bit-by-bit.

For example, the king might send you on a quest to rescue the princess, sending you to Dunshire to meet with Quazyx the wizard, who asks you a favor before he spills the beans on how to invade the dungeon where the princess is kept.

When your side quest got a side quest that also has a side quest...

I could go on, but you get the idea. But beyond this, you should be able to build your own quest components. I envision these much like React hooks — a component could simply be a couple of existing components glued together with some logic (“you have to bring a pristine steel sword to the smithy”, for example).

It could also be a completely custom quest, built up from the components that the built in components are built on. For example, you could customize an EscortComponent such that the character can fight for themselves (thank the gods, am I right?!). Or you could customize an ItemFetchComponent such that the quest giver’s response to your return depends solely on random chance! You should be able to customize to your heart’s content, but in short, easy things should be easy and hard things should be possible.

In code, I imagine this will be largely declarative in nature, when it comes to actually defining quests, meaning you simple declare what a quest is, put it in the right place at the right time, and you’re good. Defining custom quest components will likely involve more straight up imperative code, but when it’s used, it’ll be in a declarative context.

Ultimately, I imagine much of the language will be declarative. I mean, look at the way conversations were scripted — it defines data structures that will be processed by the system based on their definition and structure!

Anyway...when I’m designing a language like this, I often feel as though I’m wandering a desert. Here’s a song that captures that feeling. Til next time! ✌