Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.
My set up: The character is presented with four switched that can control another event (a zombie), moving it up, down, left, and right. The object is to move the zombie around obstacles so that it walks across four floor switches, pressing them down and opening a door. Everything works perfectly except that I can't get the zombie event to trigger the floor switch events. How do I get an event to trigger another event by touching it?
Then, you need to do a conditional branch that checks if ZombieX is equal to SwitchX, and then a conditional branch INSIDE that one, that checks if ZombieY is equal to SwitchY, and then whatever you want to happen...
Basically, that just makes sure the zombie and switch are on the same tile together.
And I assume that these variables would be controlled by a common event that would be tied to the switches the player throws and thus checked every time they throw a switch? Also, where in a conditional branch can you set it to check location on map?
Also, keep in mind that there is not one set path through the obstacles.
You'll need to make it a Parallel Process event, but this is just a variation of the Boulder Puzzle, which I have a bevvy of screenshots of, in case there's any confusion about how to do this.
Hey, screenshots are always welcome and appreciated!
This event sequence is really all that's standing between me and completing my first full (albeit short) game. It's a tribute of sorts to the old DOS game "Hugo's House of Horrors".
I wrote a tutorial for this that's kinda buried in that section. Here it is, reposted:
Unka Josh":1k67fx23 said:
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?
