Esoteric Update #271 - A Highly Technical Update

Alright. I'm a little late with the update, but something came up yesterday. It wasn't anything serious; it just ate up a lot of my time.

So, I've felt burned out working on the adventure. A lot of stuff there needs to be bootstrapped for future adventures to work, both in terms of code and data, but it's coming along. Unfortunately, it can also be very tedious, especially since I work alone on the technical side of things. So, I decided to leave it for a week, catch a break to solve some technical issues, and pick it up again this week.

So, what sort of technical things got done?

I exposed the engine form to the API; now, you can set the window icon or title with code. This might be useful for cute stuff, and manipulating these things makes it feel more like an actual game engine. I'll likely look into it again later, just to introduce a few more controls.

While I was at it, I also cleaned up a few things in the form's configuration so the window can now be resized more freely. This includes the feature of being able to tap it against the side of the screen to get a half-screen window (this didn't work correctly before).

I've entirely removed Ink from the engine. My disappointment with Ink is immeasurable, and I don't think there's any use for it, especially considering how buggy the whole system is. I might bring it back as a library, but not now.

I want to emphasise that this has nothing to do with the previous point, as I've already been asked if this is a replacement for Ink. The answer is no, it's not; it's something completely different. I've looked into CS-Script, CSScript, C Sharp Script, or however you want to render it. It's an interesting solution that lets you use C# as a scripting language through compiled-at-runtime Assemblies. This means that while the system requires some time to compile the scripts, they are as fast as C# once they are compiled. While there are some problems with versioning, I managed to get an older version working in an environment compatible with the engine, and it works fine. I had to figure out how to interface with it, but that went fine, and I have a working example solution. Unfortunately, the usage of CSScirpt is a bit dubious as it allows you to access a lot of stuff, which makes scripts unsafe. This is something that I doubt a lot of people care about, but I try to make the engine as boxed as possible so it cannot be used as some kind of malware platform. This library would make it very difficult, if implemented. For now, I'll just leave it as it is and not include it in the engine. Note that technically, libraries also have similar issues, but because they are pre-compiled, it's much less of a problem.

I've also managed to get hotkeys working, and while it's a bit hard-coded right now, I'll be expanding this to a configurable solution shortly. I'll likely also remove the right-click menu and replace it with one coded on the level of the renderer, just for the sake of everything being able to be configured, etc. I don't want the engine to require any hard-coded JS calls to work. I've also used this as a chance to improve how pasting works. This was partially done to rest the keyboard controls and partially to test some new things I learned about JS.

Finally, while playing around with the paper-v2 template, which I improved performance-wise last week, I found it still took too much CPU time to render when filled with a lot or very complex content. I've written a paper-v3 template that runs the vast majority of its operations on the GPU instead. This change helped with any performance issues, though because it's written entirely from the ground up, it does not yet have full feature parity with paper-v2. So, I might look into that at some other time; the missing functionality is unrelated to what we're currently working on.

Also, I uhhh... I made a mistake at one point:

I'm currently expecting a pretty rough week at work, but it's the last one before my summer vacation, where I have a lot to do. In the following weeks, until the end of the month, the amount of work I have to do will return to normal. This should give me much more time to work on the project, and I am rather excited about that.

Anyway, this week, we will return to bootstrapping data for environment objects and the like.