Part 62: Behind The Fangs, Part XV - Party Following And Blinking

Behind The Fangs, Part XV - Party Following And Blinking

♪ BGM: Vacant Lives ♫

Alright, time to get back to digging into Marlex's bag of tricks. This time around, it'll be something that has been following us around pretty much the entire game now - literally. We're going to be checking out how exactly Marlex managed to get three different character sprites to follow the main one, since that's not at all something the engine supports - it's entirely centered around a single character sprite representing the hero and his entire party. Now, this will be managed by several different things - for one, we have a few common events that work together, and on the other hand, we have some events that are placed on every single map that our party can potentially end up. Fun stuff. Anyway, let's start out with a simple common event that will be laying the foundation for everything.



This is the basis for the following. It's "Position Nachlaufen" (position following) a parallel process that runs when switch 0498, "NachlaufenAN" (following on) is on. This event simply constantly writes the main character's position to two variables. I have no idea why there's a check for the trigger switch, since the event can only run if the trigger switch is on. There might be a particular quirk of RPG Maker 2003 that requires this branch check I just don't know about. Anyway, that's the first part. Before we get to the part where the characters are actually drawn and controlled, we need to address another subject which is... blinking.

Yes. Blinking. We've gone full pannenkoek2012.

Anyway, here's the first common event that is used in blinking.



...yup, that's it. This is common event "PartyBlinzeln" (party blinking), which is a parallel process with switch 0495, "Blinzeln" (blinking) as its trigger switch. The event just adds one to three variables, one for Alaine, one for Asgar, one for our fourth party member, and waits a little bit. That's it. We will see how this plays into things later. Finally, we have one more common event, this one being a mite more complex.



Long one, however fairly simple one. This is common event "Blinzeln". It is also a parallel process, and it also has switch 0495, "Blinzeln" as its trigger switch. Now, the first thing it does is check for switch 0496, "BlinzelnAUS" (blinking off).

...I need to interject something for a bit. There's some things I will never understand about this code, and these switches are a big part of it. There are some things that are very difficult to find out in RPG Maker, and finding out how exactly a switch that is used over a hundred times is actually used is one of them. So you're just going to have to take my word for it that these switches are used to control the blinking, but their exact procedure will have to remain a mystery.

Another thing that will remain a mystery? What exactly the check for map ID #1 is supposed to catch. This happens if BlinzelnAUS is on, and if the map ID is #1, then it just skips everything, waits a bit and starts over. I can only presume that map #1 is the very first one, where we selected our difficulty and that kind of stuff. Anyway, if the map ID is not #1, then the event goes and sets the characters graphics for every potentially playable character to their non-blinking version. Oh, right, I should probably explain how that part works, too. Well, it's simple.



Here's Valnar's basic character graphics in their non-blinking form. Also, blown up to 400% size because them motherfuckers are tiny.



And here's Valnar's basic character graphics in their blinking form. This is the basic way the rest of the event works - it switches to the blinking version for a very short time, then switches back. There's also a little check for whether Nyria is in that part of the story where she's bleeding from the back of her head that sets character graphics accordingly, and really, that's about it.

That's basically it for the common events - the second part of this is dealt with through some different events, which we'll look at now.



So here's a small map for us to take a look at just how this works. You can see three events in the top right corner, one with Alaine's sprite, one with Asgar's, and one with the sprite of a vampire warrior. These are the three events that will be following us around. Let's open up Alaine's event and take a closer look.



Now, there's four different pages to this event. The first one requires Alaine to be in the party. The second one requires Alaine to be in the party and switch 0078, "SCHNELLLAUFEN" (walk quickly) to be on. The difference there is that the movement frequency of the event is taken up a notch to adjust for the faster walking speed. The third one then requires switch 0499, "NachlaufenAUS" (following off) to be on, and doesn't do anything. Finally, there's page four, which requires switch 0500, "KeineParty" (no party) to be on, and also doesn't do anything. Refer to my above comments regarding the usage of random switches as to how exactly these switches are used during the game. Now, the first two pages have the same code behind them, and it's what makes the following work, so let's take a look!



This is an interesting event, as it's one of the rare cases where there's a loop that is actually never exited! But we'll get to that. For now, let's start at the beginning, which is often a good place to begin. The first thing this does is an initialization. It places the event at a particular location, that being the two variables that the main character's position is being constantly written to. Then the event is made to face the same direction as the main character as well. Next, the variable for blinking is reset to 0, and then we enter a loop.

The first thing we do in the loop is set a variable to the direction Alaine is facing. This is used in the followup event to allow Asgar's event to know where it's supposed to go. Next, there's a check for Alaine's blinking variable. If it's 35 or more, then the character graphic is changed to the blinking form, then if it's 37 or more, the graphic is set back to the normal one and the variable is reset. So that's how blinking works. Alaine blinks between 35 and 37, Asgar between 40 and 42, and the fourth party member between 33 and 35. Valnar, as the main character, is not subject to this blinking cycle and instead has his cycle defined by the common event we saw earlier.

After that, we have a bunch of mathematics occurring. We write the coordinates for this event into variables and then subtract the main character's position from those variables. Basically, the event is waiting until the total distance between this event and the main character is two tiles, because that means it needs to move in a specific direction in order to close the distance back to one tile again. How it does that is probably best explained by way of crappy MSPaint, so let's do that!



So, imagine this to be four tiles of an RPG Maker plane. Tile V is occupied by Valnar, and tile A is occupied by Alaine. The distance between the two is now two tiles, meaning that the event that represents Alaine needs to move a specific way. The difference between the Valnar's X and Y coordinates to Alaine's event's X and Y coordinates are both 1, so that's the part of this event we need to look at. After that, we need to check which way Valnar is facing. If he's facing left, that means he came from tile M1, so that's where Alaine's event needs to move, and so it moves up. If he's facing up, that means he came from tile M2, so that's where Alaine's event needs to move, and so it moves to the left. There's then several different cases to catch all of the potential ways Valnar's sprite can get two tiles away from Alaine's event, and then the loop just constantly repeats.

And that's the basic gist of how the party following mechanic works! Asgar's and the fourth party member's events work very similarly, just that they are based on Alaine's and Asgar's event's position as opposed to Valnar's, respectively.



Also, the fourth party member's event is a total clusterfuck of pages since it has to cover all eight potential fourth party members. But that's about it for this time. Next time? I have no idea again!