Someone suggested that I post this here, so we'll see if it's any use to anyone.
Purpose
This tutorial will cover the creation of a Lufia 2-style pressure switch-- that is, a switch that opens a doorway only as long as the player, or another heavy object such as a boulder, is placed on it. The key point here is that the doorway will close again if no heavy object is placed on the switch; however, it is simple to adjust the scripts to have the switch only need to be pressed once.Â
Setup
Here's our hero, trapped in a dark dungeon by the Evil Disco Demon, Lord Gibb. Since Lord Gibb hates all that is natural and good, he can open the door by trampling on that one bit of grass in the dungeon, but the door will torment him by closing again the minute that he steps away from the grass. But wait-- that boulder over there looks round enough to roll...
First, here's that boulder as an event.
This is a fairly standard and simple boulder-- when the player walks into it, it slowly moves in the direction the player, using the nested conditional branches to determine the facing of the player. If we change the event's trigger to "Action Button," the player will need to push the button to move the boulder, but I made it easier to discover this accidentally in this case.
The player can shove the boulder around as they like, although they'll be very sorry if they push it into a corner.
The important thing, of course, is to test if the player or the boulder winds up standing on the grass. First, we'll track where the player is located on the screen. On the map above, the event that does this is represented by a harpy. The harpy will "watch" the player by continually setting a pair of variables to the player's Map X and Y.
Note that the harpy is a Parallel Process event-- this is necessary for the event to continually update the player's location. It is very important to note that the variables are being set to Map X and Y, not Screen X and Y-- the Map X and Y correspond to the location of events and tiles, not pixels.
Here's another Harpy, just like the first. It's watching the boulder.
Just the same as the other one, but tracking an event instead of a player.
As a side note, these events do not have to have graphics. They don't have to be two different events, either-- they could easily be one single event checking four different variables. I chose to do it this way on a whim.
Here's the door, by the way. It's good and closed, and it tells you so. However, note that there's another page. We'll be looking at that second page later on.
All right. Now that we have all those variables being tracked, we need to do something with that information. Thus, the Sea Serpent. It's going to compare the X and Y of the player and the boulder to the X and Y of that patch of grass-- when they are the same, the boulder or player is on top of the grass, and it opens the door, both by changing the graphic and by turning a Door Open switch ON.Â
(As a variation, if you want an event to detect when a player goes, for example, north of a given point, you can use just one X for a similar purpose.)
Again, note that this is a parallel process event. It's checking continually. (Use too many of these on one map and it'll get laggy, though.) Also note that there's a second page.
Both two-page events have the same switch-- Door Open. Here's what the Sea Serpent event looks like when the door is open:
Two pictures, because the coding is longer.
Now, why did we do it this way?
Because a parallel process event will continue to check the same event. If we didn't put a second page here, the door opening animation and sound would play continually. Even if the switch is only triggered once, and doesn't reset, use the second page if you have any animations or sounds that you don't want to play continually.
This conditional branch is much more complicated, because it's checking for two different things-- it needs to see that neither the player nor the boulder leave the patch of grass, and that requires extra nesting of the conditional branches. (This would be simpler if only the boulder could activate the switch, but I'm showing you the most complex version.)Â
Note that the event, when triggered, shows the opening or closing animations, waits, and then flips the switch that will change the page of the event. This prevents the animation from being abruptly cut off by the switch changing the page of the event, and is a technique worth remembering for other events.
Finally, here's what the door looks like when that same door switch is triggered:
Which is fairly straightforward.Â
Was this tutorial helpful? Do I need to make any points clearer?
Purpose
This tutorial will cover the creation of a Lufia 2-style pressure switch-- that is, a switch that opens a doorway only as long as the player, or another heavy object such as a boulder, is placed on it. The key point here is that the doorway will close again if no heavy object is placed on the switch; however, it is simple to adjust the scripts to have the switch only need to be pressed once.Â
Setup
Here's our hero, trapped in a dark dungeon by the Evil Disco Demon, Lord Gibb. Since Lord Gibb hates all that is natural and good, he can open the door by trampling on that one bit of grass in the dungeon, but the door will torment him by closing again the minute that he steps away from the grass. But wait-- that boulder over there looks round enough to roll...
First, here's that boulder as an event.
This is a fairly standard and simple boulder-- when the player walks into it, it slowly moves in the direction the player, using the nested conditional branches to determine the facing of the player. If we change the event's trigger to "Action Button," the player will need to push the button to move the boulder, but I made it easier to discover this accidentally in this case.
The player can shove the boulder around as they like, although they'll be very sorry if they push it into a corner.
The important thing, of course, is to test if the player or the boulder winds up standing on the grass. First, we'll track where the player is located on the screen. On the map above, the event that does this is represented by a harpy. The harpy will "watch" the player by continually setting a pair of variables to the player's Map X and Y.
Note that the harpy is a Parallel Process event-- this is necessary for the event to continually update the player's location. It is very important to note that the variables are being set to Map X and Y, not Screen X and Y-- the Map X and Y correspond to the location of events and tiles, not pixels.
Here's another Harpy, just like the first. It's watching the boulder.
Just the same as the other one, but tracking an event instead of a player.
As a side note, these events do not have to have graphics. They don't have to be two different events, either-- they could easily be one single event checking four different variables. I chose to do it this way on a whim.
Here's the door, by the way. It's good and closed, and it tells you so. However, note that there's another page. We'll be looking at that second page later on.
All right. Now that we have all those variables being tracked, we need to do something with that information. Thus, the Sea Serpent. It's going to compare the X and Y of the player and the boulder to the X and Y of that patch of grass-- when they are the same, the boulder or player is on top of the grass, and it opens the door, both by changing the graphic and by turning a Door Open switch ON.Â
(As a variation, if you want an event to detect when a player goes, for example, north of a given point, you can use just one X for a similar purpose.)
Again, note that this is a parallel process event. It's checking continually. (Use too many of these on one map and it'll get laggy, though.) Also note that there's a second page.
Both two-page events have the same switch-- Door Open. Here's what the Sea Serpent event looks like when the door is open:
Two pictures, because the coding is longer.
Now, why did we do it this way?
Because a parallel process event will continue to check the same event. If we didn't put a second page here, the door opening animation and sound would play continually. Even if the switch is only triggered once, and doesn't reset, use the second page if you have any animations or sounds that you don't want to play continually.
This conditional branch is much more complicated, because it's checking for two different things-- it needs to see that neither the player nor the boulder leave the patch of grass, and that requires extra nesting of the conditional branches. (This would be simpler if only the boulder could activate the switch, but I'm showing you the most complex version.)Â
Note that the event, when triggered, shows the opening or closing animations, waits, and then flips the switch that will change the page of the event. This prevents the animation from being abruptly cut off by the switch changing the page of the event, and is a technique worth remembering for other events.
Finally, here's what the door looks like when that same door switch is triggered:
Which is fairly straightforward.Â
Was this tutorial helpful? Do I need to make any points clearer?