The Lass is for the Lady

If you take a look at this pic, I am leading a party.  The flower is reacting to someone.  That someone is not my party.

I have managed to get an Event to react to another Event, restricted to whether that Event is an Enemy or can trigger events, and also restricted to whatever can be effected by Events.  Also demonstrated, though not easily visible, is that the Event is also affecting whoever touches it, whether it is an Enemy or the Player. (In this case, the flower subtracts some HP, which can "kill" the enemy".)  Also, Events that only trigger but aren't enemies can still trigger the flower but won't get damaged by it, so no crashing here.

Hm...I know the next step for an ABS is to implement some attacks, though at this point, I probably want to create a demo, even if it's just zombies tearing down a wall.  Anyway, I do have to add in some more code for functionality, such as knocking characters back and creating events that can trigger from enemies but not players.


I want to take a second to remember this journey into the ABS, because it was one thing that I never thought I would make.

-Quicksand for All:  I suppose the desire to make an ABS came from the idea that I wanted everyone to sink in Trivel's Quicksand.  It involved messing with jumping and notetags, as well as a improvement to the movement system I used in my games to affect Events as well.   At one point, I experimented on adding states when sinking to a certain point for players, which led to...

-Event Enemy:  Considering that a player has an Actor, it should be simple to give an Event an Enemy, all for the purpose of storing states on their end.  This one had been a brain teaser considering that Player and Event/Actor and Enemy have their differences, especially as I could add states but couldn't re-add them, not to mention the fact that Events didn't have "default" character sets like the player.

-Buttons for All:  Now I had Events that could sink and get states, but that left me wondering about how to affect events if I don't have quicksand.  It was easy to get events to trigger another as they can trigger from players already.  I also learned about events_xy, a Game Map method that creates an array of events at a certain location, so I was able to create a method for the target event that determines who "triggered" it, though it's more accurate to say that it triggers and applies its effects on anyone in that spot.

-Buttons for Us:  At least, only for floor traps at that point.  While I could have followers each step on a trap and get individually affected, I had to borrow from Himework's Follower Touch Event, which changes player's position into "party position", though I have an "original position" for the actual leader; this solved the problem of events walking past the party and straight into the leader.  I also attempted to have the "damage any character" method in the interpreter, but with how the eval script worked, I don't think it could store actor data usefully, so I would have to call through the event (not too difficult).  I also thought about having a method caller, but decided that a method judged by a string/variable would be less clunky.

-Buttons for Her:  The most recent item was to get Events to be able to trigger Events on the same level(one tile away), which looked harder than having them trigger floor traps (same tile).  This stumped me a bit until I found the two issues.  First, an event usually looks at the player when it's triggered; so it would look at me from a distance and may ignore the guy touching it, but with how my method works (calculate one space in front), it won't see the triggering event.  This was solved by adding a switch that gets turned on when the player or other event starts the event, and the event will instead look towards the character/location that has this switch.  The second issue was that events could only trigger other events once and they would have to step away.  However, I had a theory and it works out:  Characters are still moving even against a wall, though they instead "turn", so I placed the method for triggering other events in that part, and after adding some wait time to pace "button presses",  I managed to get an event to bother the flower until they're dead. (by default, the trigger_touch method there was to start its own event, hence why I didn't notice any effects before.)

Well, a few more tests to see any other interactions I missed, and a few ideas on the "battle system", perhaps remove the facing mechanism if the player's fighting an enemy.  Well, we'll see if this will become an actual if basic ABS or just a fancy way for Events to interact with other events.  I know this has been enjoyable to make.