It’s been almost a year since I started working on Salet, and I think it’s time to tell about my progress.
The current version number is
It’s a forty-third release, a result of one hundred and fifty-six
Admittedly, that’s not much; there are many cool new features but mostly I focused on polishing and documenting everything that I already had and loved. Salet is a great multi-genre tool suitable for complex puzzle games as well as kinetic novels.
And you can go crazy with it.
I made Salet because I wanted to do whatever. The engine has only eight assumptions about the game interface, and six of them are there for you to break.
This approach means, among other things, that Salet has a ton of things and affordances to make portable objects and player inventory but offers no default way to present the inventory itself. That’s an intimate piece of a game, a thing that is a part of the whole design. Should the inventory include a short summary on the character’s stats or a spell list? Should it be a special room or an interface block? Should it change the page layout to something entirely different? I’m not the one who makes these decisions. The game author does.
And let’s not forget about having the right amount of puzzles and linearity without sacrificing the visual design. My latest Salet game is a Ludum Dare piece that jumps from a one-room puzzle game to long-scrollback dialogue sections and back again. (It’s also full of bugs and broken Engrish until I finish the post-comp update)
The library is now packaged for NPM and that’s
the easiest way to get it - just
npm install salet.
There are automated tests to ensure the engine always behaves as intended.
I might be ready to call it 2.0 but I feel like I need to write more documentation. I translated the API docs to English but the user guide is still not there. I’m not even sure it’s worth translating because… well, no one used it and some sections are just explaining the API but in a different way. Maybe a post like “How to display the inventory” would be better, but - again, I have no idea at the moment.
So, about the new features. Let’s start with my favorite and the oldest one (March or April).
Autosaves were there since version 1.0; Salet automatically saves the game whenever the player enters a new room. When the player returns to the game, it automatically continues as if nothing happened.
But now there can be rooms that won’t be autosaved. Like an “inventory” or an “options” room that is not diegetic, so it doesn’t even exist in the plot. It allows me to put a “Go Back” button in it - another new feature - and gives more control over the automatic saving.
There’s still only a single save slot but I hadn’t much time to look into that. But I wrote manual loading with delayed game initialization in case you want to have a welcoming menu thing (“Play game - Load game - Options”), so that’s something.
Remember the eight assumptions?
Well, there is nothing against changing the whole HTML inside the
One minute you have some block above the text, and then you can swap that for a
I tried that on a shared project where the game went right to the world map after the character generation, but unfortunately the project is not public yet, so I can’t show that in action.
This is not a core feature per se because it’s always game-specific. The themes can be simple strings or complex functions, and they can be international too. I wrote three different implementations for theming. But the general idea is universal and it’s already supported. You’re free to make anything.
The player activates something that’s going to pop five turns later.
This feature is not tied to objects or rooms, it operates on functions. The function would be called before the turn but Salet will write its output after the turn, so that it could affect the room description but not be affected by it (some rooms clear the text before printing their descriptions).
And it’s a hell to debug in the game, so I suggest you look at
test folder in Salet’s sources,
because now you have an object, an action, an immediate effect and a delayed effect.
And you’ll have to catch the actions between the immediate and delayed effects too.
and some rooms can delete whatever there was before entering them, so you can miss some text.
For now, there are no plans for the new features.
Hell, I still have a small Undum feature to backport.
Or shall I say it like that: there are no more features from my games that I feel like would be general enough to introduce to the core. There are more than enough code examples, so…