Esoteric Update #210 - Ink Gone Emotional
Alright, time for an update here again~
No lore, no article and no tutorials today, I'm just running late here, and I have no intention of postponing this update to tomorrow so I can edit and format one of those. However, I have some ready to go, so... I'll try to make it a double or triple feature next week.
Ok, so what happened this week? I finally managed to wrangle a working system out of Ink that has parity with most of the features of our current regular interface. While it's rough at some places to accommodate for this, the experience of working with it isn't that bad... except for having to work in Ink, and I have to say, the whole experience was somewhat frustrating.
I hoped to have this ready about a week ago, but here's the issue. Ink has three components you need to work with: the IDE, the compiler and the runtime. Over the last three weeks, I have thoroughly experienced many different and "interesting" ways for each component to crash or not work correctly.
Additionally, I've been somewhat ambitious with the feature parity itself as I wanted it to, at the very least, be able to handle the following features (in ascending order of difficulty):
- action economy,
- v2 choice menus,
- basic features of dynamic paragraphs,
- reordering dynamic paragraph elements,
- emotions.
And yeah, it worked. This is what a responder looks like in Inky:
And this is the effect it produces in-engine:
There's a bit more, but it's pretty technical. I changed some of the code for my engine to ensure parity between how different selectors work. I have also provided a new special tag element for the all and allrev selectors, denoted as ...else. This particular tag allows me to work with some edge cases that were a bit difficult before, but let's be honest, you have no idea what I'm talking about, nor are you very interested.
The point is I spent a lot of time getting this Ink thing to work, and the fault wasn't on my side (because I was sick) but just on the side of Ink's tools being problematic. But it's done now, and it's fit for purpose, so I can give it a spin and make some events and interactions.
Get Esoteric ♥ Esoterica
Esoteric ♥ Esoterica
A story driven erotic game about magic, supernatural forces, love and BDSM.
Status | In development |
Author | EsoDev |
Genre | Interactive Fiction |
Tags | Erotic, Experimental, Fantasy, Female Protagonist, Mystery, Procedural Generation, Romance, Story Rich, Text based |
Languages | English |
Accessibility | Color-blind friendly, High-contrast |
More posts
- Esoteric Update #294 - ACK! (Give Your Opinion, Ok?)5 days ago
- Esoteric Update #293 - A Touple Of Things12 days ago
- Esoteric Update #292 - Keys And Snakes And Charts, Oh My18 days ago
- Esoteric Update #291 - All Keys To All Doors26 days ago
- Esoteric Update #290 - Returning To Work33 days ago
- Esoteric Update #289 - A Convolution By Another Name48 days ago
- Esoteric Update #288 - Continuing On With Work55 days ago
- Esoteric Update #287 - Return Of The Cat: Long Update61 days ago
- Esoteric Update #286 - Hyperplanar Orthography82 days ago
- Esoteric Update #285 - Ugh My Head, Anyway, Coding89 days ago
Comments
Log in with itch.io to leave a comment.
How is Ink working out for you? I would have thought that you would need a language with storylets or QBN to handle all the procedural text generation needed by your game. I found that Ink lets you randomly choose text or conditionally choose text, but it doesn't have a primitive for randomly choosing text with conditions (or better yet, something that could assemble storylets into a more coherent story)
I got it to work but it wasn't easy. That said, main interest for Ink was providing other people with a semi-visual interface for writing story fragments (mostly as a replacement for TreeNote, which we used before). In terms of procedural text generation it cannot particularly compare with my own systems but that's fine, the implementation of it I have right now has full interop with my own code, including a very easy way of handling procedural narration calls. Including the features you mention Ink to lack.
Incidentally, I part of what I was doing with Ink included an idea I had for assembling sub-stories into bigger stories but it's something I'd prefer to discuss on Discord if you are interested.
Overall, I think I got what I wanted out of Ink but it didn't surrender it freely and it wasn't at all any kind of extension to what I could do, just a different way of visualizing it.
Sounds reasonable. I'm currently having trouble using Discord through a proxy at the moment, but I'll be sure to check it out if I ever figure out what's going wrong there.
So I'm curious, what are your experiences with Ink? You struck me as having some ah... experience with its god awful design.
I'm not particularly experienced with it. I used it in a mini-comp game once to gain experience with it, and I ended up embedding it into Twine's Sugarcube engine in order to get a proper UI and saving. But there were bugs in the ink.js saving code, so I submitted fixes for that. I wrote a little blog post about my initial impressions. My initial impressions still hold now. The language is a real workhorse language used in real games, which is good. It really shows in the versatility and practicality of the language. But its syntax is a mess. And I couldn't use it in other games I wanted to use it for because I really needed a primitive for choosing randomly from a bunch of events but with conditions on when the events were valid. I think that primitive is getting more common in simulation-style games, and those are the styles of games I lean towards making. Newlife uses it. I think storylets is based on the same idea, but I've never used StoryNexus, so I don't know. I've seen a YouTube GDC video from Valve where they mention using the same primitive in their games.
For more conventional dialog trees, I think it's great though. The Twine-derived languages just become too messy for more intricately scripted conversations with lots of choices.
Someone came by the AIF discord last year and tried to promote the dialog engine and Å-machine, which are Prolog-style langages, and they also seemed promising if a bit difficult to get started with. But I think they also lack the random events with conditions that are useful for simulation-style games. But you might find the design interesting.
In my gut, I think an interesting engine will be something based on storylets and chatGPT. Basically, you have little storylets with conditions on when they can fire and changes in the game state. And these storylets and gamestate are fed into chatGPT to generate text that reflect the change in game state. As you know, I'm currently interested in going in the opposite direction with board-game-style narrative games, so I haven't had the energy to really explore what's going on there though.
A lot of my same thoughts and opinions.
At base, for the kinds of needs most users will have, the language works great. It works great as an addition to other systems too. The more advanced syntax though is not only a mess but functionally broken and there's a lot of things that inexplicably cause either the IDE (Inky), the compiler or the runtime to hard crash. Told the devs about both a load of those and how to fix them, got ignored, decided it's not my problem. The shame is that I feel this could be basically narrative gold if they actually resolved a lot of the bugs and reworked the syntax. Heck, just... implement an array datatype.
For the best "up and coming" narrative engine I've seen in a while, I have to say, I'm impressed with the progress Narrat v2 made compared to the state in which Narrat started in. It's essentially Ren'py but stripped down of the VN bullshit and with a few neat pre-defined modules for narrative games. Also really good for beginners, but I think it's more possible to strike out into something more advanced using it.
ChatGPT I have no faith in, however.
Oh that sounds pretty cool bro
I feel good about it, despite the issues with it. I might actually use it extensively myself since it makes organizing work easier.