Esoteric Update #290 - Returning To Work

Alright, update time. I'll speak about some personal things related to the previous "update" (or rather lack thereof) and then move on to the game itself.

I'm off the medication now, though coming down from it still took a while, and I needed a few days from the beginning of the week to start feeling more like myself. I've still had issues with a spot of brain fog, and I've had some problems with writing in particular. I spent a bit of the week trying to write, but unfortunately, it hasn't been working out. I threw out a lot of the work I did, but at the very least, I've been able to do some work.

In terms of the actual update, I've focused on two things. First, I wanted a quick and easy win, so I looked into the NPC conversations. I've had a stash of one hundred conversations from playing around with AI (I'll talk more about this in a moment), so I looked into that old module and worked on it a bit. I both improved the vocabulary for the system (there are also some additional pending amendments) and encoded around sixty-five of those generated conversations.

Now, there might be a question here as to why we're using AI for this. The answer is simply to work around certain biases. The AI works under a three-pass supervision routine (conversations can be rejected immediately, when being edited by someone else and then when being edited one more time by me), so it doesn't exactly have free reign over what ends up in the game. What it does work for is touching on subjects I wouldn't think about myself or be unable to write anything of substance about. So overall, it works very well, fills out the conversation space with some new chatter, and we can reject anything weird or inappropriate along the way. The process should also fill out some of the word statistics we need for some other things I've been working on.

Anyway, after that, I moved on to working on the test adventure, and I'm tackling the key issue. Last time, I mentioned implementing a method for modular items to stack together. I wanted to use our item generator to resolve the specific items needed for the key stacking, but it did open up a rather interesting issue...

So far, generated items contained only terminal text - that is to say, this is text stored in a done and finished way, it's not dynamic, it doesn't incorporate any variables (past the generation process), it doesn't contain any square bracket expressions. This is, of course, because the generated items result from resolving such expressions. However, modular items require bracket expressions to pass data there and back to coordinate names, descriptions and... well, it can also do the same with stats, though it's not used in such a way in this case. After all, the behaviour and function of a key are not changed by adding a carabiner.

Anyway, I had thought about this before and added some provisions for it; however, I didn't have a chance to check it out extensively before. Ironically (???), the feature made its way into the modular items already because it's used for a trick involving passing responsibility for resolving a token back to the parent item part. In practice, it results in this strange-looking construction popping up in the template files: [<<_[<<_[raw-data@11]]]. And no, it cannot be simplified.

Ultimately, I've started generating the key items now, but I still have some writing to review, edit and encode before they are all ready. After I finish that, I'll set up the doors in the adventure location and move on to descriptions of the rooms. There's, once more, something interesting happening there that I'll want to get a bit deeper into.

So yeah, sorry for a pretty basic update, but I thought these were interesting enough development details to get a bit deeper into them.