LyLad April Update 2 (Patreon)

(Image is concepts for some of the types of daemons that will appear, not likely as enemies but as special encounters or events.)

Main bulk of the work this latter half of the month was focused on this: https://twitter.com/OrriGame/status/1652874039709298688?s=20 New way of setting up maps and events within maps (though it's probably not all that obvious what is different.)

Earlier in the month I drew up the three main demo maps and got to work on setting up their functionality (being able to traverse them, pass checks, find secrets, etc.) and as I kept working on them I kept finding ways to improve the basics that I had laid down when I made the first map late last year. The basic setup was not ideal and it was inefficient for both making maps from scratch and trying to edit them. At first I just wanted to improve the system by making manual checks (inspecting a dot for instance) call on text and variables stored in the event itself rather than find it hardcoded elsewhere based off of coordinates (this was bad and annoying). 

Eventually I decided the entire current system needed to be redone and standardized so that everything would be working on the same level, and thus dots (the spots that you interact with on a map to progress through it) could also plainly interface with each other and send each other messages. 

The best example is how doors are set up to work now. If a door is closed, you need to open it. If it remains closed, you can't access the dot on the other side. Previously, if you opened a door but say didn't pass through, if you approached from the other side while disconnected from the previous path you took (ie, took a one-way passage to the other side), for the dot on the other side of the door to know that the door was open and that it should reveal the side you were previously on to you, it needed to specifically target the dot you already opened the door from to get that information, then add that dot to the list of dots it can reveal.

Now, two dots connected by a door will automatically check and find their reciprocating dot without it needing it be hard-coded in, and tell that the door is opened. The same applies to two-way locks and other checks. Unlock a door from one side and the other side will automatically know that the check is passed and doesn't need to be done again. It's not that this functionality didn't exist previously, but that it required many more bespoke inputs that could be easy to forget or annoying to change, where now I can take any pair of doors, copy and paste them elsewhere with different dot ids, and it'll work just the same.

On top of that, these interactions such as doors are self-contained within a dot, and more interactions can be stacked on top of each other without any interference or needing any extra guidance. A single dot can have several different doors, items, chests, switches, etc. when previously I could only hope to put one or two of such things.

Because of how this works you now mainly interface with dots through commands, including utility skills such as 'inspect' and 'force' (perception and strength), tools such as lockpicks, items such as keys, and generic inputs like 'pick up', 'open', and 'interact'. Pressing the shift key brings up a quick menu of all the actions you can take. When there are multiple things to act upon, you get prompted with a selection of the 'interactibles' associated with a dot based on the action you choose. Each interactible can also have its own trap attached, part of why even picking up an item is now a choice, so it can be clear that nearly everything carries an associated risk. (I do want to add a bit more convenience to it, so it's likely just activating a dot like normal will bring up the 'interact' action so you don't need to open the action menu all the time.) Watch the video above to see this part in action.

The main point of all this was to make map-making faster, which it has succeeded at, though I'll need to remake the old ones to fit into the new system. It also opens up many more opportunities for interactions, checks, secrets, and randomness (mainly with whether or where traps are set). 

Parts of this still need to be completed, such as how encounters, random encounters, and enemy ambushes are worked into it, but the video was a kind of proof of concept that succeeded. I'll know if it really worked when I can recreate the first map of the demo.
After that my goal will be setting up functionality for all the other demo maps, then that will be it for this part of the work. Then I will finally move on to Lilya's sprites and some more art assets. The demo in June is much less likely now by the way, but late July is still possible I think.