Esoteric Update #245 - Reflection, SQL And A Break

Right, I'm sorry to say this, as usual, but I need a break. I'm just not doing well, and I could use a few days for self-care and lots of sleep. The next update will be on the 5th or 6th of November.

As for the update for today... I do want to talk about something I've just recently finished, but it's a boring technical thing, so you might want to skip it.

Essentially, I made the engine extendible through additional libraries consisting of compiled .NET assemblies. Speaking otherwise, and to keep it as simple as possible, you can write a library in, say, C# and given that it maintains a particular specific interface, it can then be loaded into the engine as an extension. This kind of extension allows you to introduce new API tokens, which are managed code. Comparatively, the extension module allows new API tokens to be defined using our scripting language. Such extensions have limitations which these libraries don't.

But I guess you might want an example. It's quite possible you might have heard about this little thing called SQL? So, let's assume I might want to add a database to the game. I could bash out some kind of simple implementation using scripting... but I could also do something else. Using the library module, I could build a program that matches the interface and implements a set of commands that let me interface with SQLite directly from the game.

Well, this is precisely what I did.

Here's a fun fact about how this works... It doesn't require the library to import any code from my engine. Indeed, the only requirement is for the assembly in question to contain the definition of this class (maintaining all names, including the class name):

Template class.

For example, the SQL library consists of two files:

Template implementation.

Underlying code.

After some setup, the engine will programmatically load this assembly and set it up so that the engine can call it. You might note that apart from offering token resolution for the nine available data types, it also provides parameter reading and calls back to the scripting language. Overall, it allows for the free exchange of data and rather complex behaviour implementations. Especially since a library can have its own internal data that isn't limited to what the scripting language covers. Like what you can see here with the DB connections.

I've always wanted to have this as a feature, but I've never believed myself capable of accomplishing it. As some of you might know, I'm not actually a programmer, so this kind of coding isn't what I do. And it was hard, and the issues along the way made me feel really stupid.

Over time, not right now, I might consider moving some things to the library format, such as Eliza, Ink or the entirety of the draw command. It's a much better place for them to be rather than littering the main API. Perhaps one day, someone will even write their own library for the engine. Very unlikely, but I guess I can dream of things that would make me happy, right?

Again, I'm sorry, I need some time to put myself back together, at least a little bit.