RSS

Part 2: Complicated Line of Sight Examples

These four examples combine the Simple Line of Sight Examples or use more complicated lines of sight with eventing to provide various effects.  Its assumed that you read Part 1 because I won’t be explaining concepts from that part again.

1) Chase/ Tag Event

This event varies from the others because it was made to move.  This event could be used for kids playing tag with the player for example and other things.  Let’s look at the parts:

This uses the Wide Line of Sight script calls, and if the player is in range, the event will move towards the player after speeding up.  If the player isn’t in range the event will return to normal speed and go back to moving randomly.  I did it this way so the player could run out of the event’s range and the event would stop pursuing.

This utilizes the Triangular Line of Sight script calls with the Range script call set to 1.  This is just like the earlier Triangular Line of Sight example.

2) Assassination Event

This is just the Basic Line of Sight example from Part 1.

The basic purpose of this section is to allow the player to hit the C Button (usually Enter, Space Bar, Z) and the player can attack from behind or from the side.  I separated these out so you could do different things, but I was being lazy so they both do the same thing.

The first conditional branch is a simple button press conditional branch.

The second conditional branch uses the Triangular Line of Sight Range script call, but this time the Range is actually the player’s range and not the event’s.

The third conditional branch determines whether the player is behind the event, of course you can’t see it:

When the event and the player are facing the same direction and are within one square of each other (because of the second conditional branch), then one is behind the other, which is why the third part of each condition checks that the player is behind the event.

The fourth conditional branch determines whether the player is to the side of the event, here it is:

When the player is facing the event and within one square, if the player is facing a perpendicular direction then this is satisfied.

Of course when all of this is satisfied the Self Switch A is turned on, which triggers page 2 of the event:

This page is all about the enemy dying visually on the screen.

First it shows an animation.  I created the animation from the slash and darkness animations, so feel free to use this if you want to.

Then we have a series of conditional branches.  These check which direction the player is facing so that the event has the appearance of being knocked back while the animation is playing.

This is just a move route that turns the image on and off to give the blinking effect on the screen.  If you use a different animation you might extend or shorten this to go with the animation.

At the end it turns Self Switch B on and A off which brings up the 3rd page which is blank, so the event no longer matters.  Turning Self Switch A off in this event makes it easier to turn the event back on with the transfer from the room event.

This is a standard transfer event with a script call added which can be used to turn the event back on as the player leaves the room.  The example here is set for map id 1, event id 3, it effects Self Switch B, and the false turns the switch off.

Its handy particularly for puzzles/ touch encounters you want to reset when the player leaves the room or if you want, you can use this to create a reset switch in the room as another example.

3) Surprise Battle Event

This event uses line of sight with a particular emphasis on the direction the player and event are facing when the range condition is satisfied.  It will show a different Balloon Icon on the player or event depending on whether the event and player are facing each other when the battle is initiated, one initiates the battle on the other from behind, or one initiates the battle from the other’s side.  The Wait command is used primarily to give the appearance that the player and event are closer together when the battle transition actually occurs, basically its a timing issue that I thought looked better, on screen, by adding a little wait.

This also differs from all the other examples in that it actually uses switches and variables and has components in the database (other than animations), such as Troops, Enemies, and States tabs.

I’ll start by explaining the conditional branches and show the relevant database tabs afterwards.

The Conditional Branches

The main conditional branch is just the triangular line of sight range script call that is the basis of this whole event page.  Now the other two are checking whether the player is sneaking up behind the enemy or vice versa.  I added comments to these in my event example to help keep things organized.  When you have this many nested conditional branches I would highly recommend you do so.

This is a similar to the Assassination Event above, but if you’ll notice the sign are reversed in the third part because this is checking if the event is sneaking up on the player.  If this condition is met then the switch I used [0101: Surprised] is turned on and the Ballon Icon appears over the player.

This is exactly the same as the script call in the Assassination Event.  If this condition is met then the switch I used [0102: Pre-emptive Strike] is turned on and the Ballon Icon appears over the event.

These conditional branches are checking whether the player initiates combat from the side of the event or vice versa.

This is similar to the Assassination Event’s script call, but the signs in the third part are reversed because this is checking if the event initiates combat from the player’s side and if the conditions are met the Ballon Icon appears over the player.  Also if the conditions are met then a random number from 1 to 100 is assigned to Variable [0101: Random Number] and the immediately following conditional branch checks to see if the variable is below the value set (this example is 50).  If it is then the Switch [0101: Surprised] is turned on.

This is just like the check in the Assassination Event, which is checking whether the player is initiating battle from the event’s side and if the conditions are met the Ballon Icon appears over the event.  Also if the conditions are met then a random number from 1 to 100 is assigned to Variable [0101: Random Number] and the immediately following conditional branch checks to see if the variable is below the value set.  If it is then the Switch [0102: Pre-emptive Strike] is turned on.

This conditional branch is checking if the player and event are facing each other when battle is initiated.  If so the Ballon Icon appears over the player, but you could have it appear over the event or both if you so desired.

All of these turn of Self Switch A which leads us to page 2 of the event.

This is just the Battle Processing and after the battle the event blinks in and out then shuts its self off similar to the Assassination Event.

The Database Changes

So with the conditional branches I turned on switches depending on how the player and event were oriented when battle was initiated.  Here is why:

This troop page is triggered by Switch [0101: Surprised] being on.  First, it adds the state Surprised (shown further down) to the entire party.  Then, using Show Text displays the message “The party is surprised”.  Finally, it turns off the switch to clear it out.

Similar to the one above, this troop page is instead triggered by Switch [0102: Pre-emptive Strike] being on.  First, it adds the state Surprised to the entire enemy troop.  Then, using Show Text displays the message “The enemy is surprised”.  Finally, it turns off the switch to clear it out.

Note:  You will have to add these to each of the troops that you want affected by this.  This gives you a lot of flexibility if you want to utilize this to have different states or forced actions per troop.  If you want this to happen with all your troops, I would suggest finding a Base Troop script.  There are a lot of different versions, so find the one that suits you.

This is the state Surprised that I created.  It has a Restriction of Cannot Move and adds some negative Features.  It is set to go away at the end of turn in one to three turns.  Of course you are welcome to make the Surprised state however you want.

Now if you played with the Test Game for a bit you may have noticed the Bat enemy is never surprised, that is because one of its Features is State Resist (Surprised).  This is one of the advantages of using a state to add surprise because you can make enemies and actors resistant to the Surprise state, which can give you some extra flexibility.

4) Zapper Event

This event uses a the Basic Line of Sight with the Range set to 5.  When the player is in range an animation will play to indicate that the player was damaged and the entire party takes a little damage.  The damage is set low because the damage will occur each time the parallel process cycles through.  The 2nd page is blank with a Condition: Self Switch A On and the crystal graphic.  When this page is active the event is essentially off.

This event shows an animation, followed by a wait of 20 frames to give the animation to complete.  Then it uses the script call described in the Transfer Event of the Assassin Event above to turn the Self Switch A of the Zapper Range event On, which turns the event off.  Next it waits 45 frames to give the player a chance to get past unharmed.  Finally it uses the script call again to turn the Zapper Range event back on by changing it’s Self Switch A Off again.  The 2nd part is the same as the first with a different animation.

I hope you found the examples in this part helpful.  Feel free to ask any questions you may have.

 

3 responses to “Part 2: Complicated Line of Sight Examples

  1. Trent Moore

    November 3, 2014 at 5:12 pm

    If I put it on the original branches else, it does not work (the making enemies follow you)
    If I don’t maske the event repeat (which isnt shown in screenshots or said) then it only follows me for one step, the resumes moving at random.
    When you saw ==3 will also work for the lower line of sights (2 and 1, in your triangle example), it does not. I have to put the || command and do it a second time.

     
  2. Todor Imreorov

    May 8, 2016 at 12:37 pm

    none of these examples take into account any walls between you and the enemies

     
    • infamous bon bon

      May 9, 2016 at 4:15 pm

      That is correct, they do not. You will have to make your maps with this in consideration or find a script that takes those into account. There are ways to check passibility of tiles with script calls, but that is way more complicated and I never made the time to fully investigate that.

       

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: