Search the Community

This is a neat little idea that can make your typical boulder-pushing puzzle a little more interesting. It took me a while to figure out how to do this through events (although I'd like to learn, I currently have no ability to script), but I have it sorted now and hope it might help someone else. Hard mode: Multiple boulders and gaps. (<if this anchor doesn't work, just scroll down) Pushing a rock into a gap. First thing's first - create an event that will be the boulder, or whatever your character will be pushing. You also need an area of water or a hole or something of the sort, which the boulder can be pushed into. The gap must be one tile across, the the boulder can act a bridge when in the water. In this case, the player is pushing a boulder into the river in order to get to the island. I added a chest that can only be reached this way, for added incentive. The boulder event will eventually have several pages, but initially, just set up the first event page. The settings should look like this: 'Event Touch' means that the boulder will move when the player stands beside it and pushes a directional button. Other people may prefer setting the trigger to 'Action Button' so that the player must press the 'A' button to activate the movement. You will need to use a terrain tag to label the water tiles. Doesn't matter what number you use, but tag the water tiles you want the player to be able to push the block into. You need several variables for this. Two will store the boulder's current X and Y location on the map, two will store the X and Y location of the position the player is trying to push it to (when they walk up to it, or press 'A'), one will store the terrain tag of the new position. So, let's do some eventing! As soon as the event is triggered, we want the boulder to store its current position in the variables. We can then use conditional branches on which direction the player is facing to determine which direction the boulder is being pushed towards. With this information, we can store in variables the new position. We then get the terrain tag of the new position. If the player is just pushing the boulder over land, the boulder should just move normally as these tiles are passable. We check if the terrain tag is equal to the one you set up for the water. If so, the boulders move route includes setting it as 'Through' which means it can pass into impassable tiles (like water). Self Switch A is then turned on if the boulder has fallen into water. It's not mandatory, but I added an extra bit of eventing here so that the boulder wouldn't reset back to its original position if the player left the map. This only activates if the boulder is in the 'goal' position and the puzzle is solved. Use two conditional branches to check if the boulder's new position is equal to a designated goal location, and if so, turn on a switch. This isn't a self switch, as we need it to link to another event. More on this later - first, let's finish setting up the other event pages on this boulder. Here's what the first page looks like: Page 2 is relatively simple. Once the rock is in place, this page sees when the player is trying to cross over it. It takes note of which side the player is on. Because switch A turns on if the boulder falls into ANY water, we need to check if it is in a goal location first. Page 3 is triggered if the player touches the rock and is facing left. This page must be set to 'Autorun' and the priority 'Below Player'. This is important, because the 'Below Player' priority means that the player will walk on top of the rock, rather than appearing to walk behind or underneath it. The event autoruns and moves the player over the rock to the other side. The switch then turns off, so that if the player touches the rock again, Page 2 runs, which looks at which side the player is on and redirects to the corresponding event page. Page 4 looks exactly the same as this, but is for if the player approaches from the other side. The only difference is that the move route contains 'Move Right' and it's a different self switch. Of course, you can also make boulder bridges which are north-south. So that's it - for the most part. What about Page 5 though? Well, it's completely empty! Remember that part at the end of Page 1 where I said something about getting the boulder to stay put after it's solved? If you want to add this feature, create a second event using the same boulder graphic. Put it in the place where the boulder is 'supposed' to be when the puzzle is solved. The second event contains a copy of pages 2 to 4 of the first event, with an additional condition that the 'Solved' switch must be 'on'. This switch also removes the first event from view. Hopefully this was useful to somebody - it's the first tutorial I've written and I'm not particularly confident in my ability to explain things, hence the use of pictures. Here's a short demo of how this looks in-game. *** Hard Mode: Multiple boulders and gaps! (Uses more switches and variables, but the basic idea is the same). It's here that I must stress the importance of keeping your switches, variables and event names organised. Otherwise, you're gonna have a bad time. Depending on just how complex you want to go, here's the switches and variables you need to use: The good thing is though, that you can re-use some of these for other boulder puzzles you might wanna make in your game and it won't make any difference. Namely, you can re-use the variables in any number of puzzles. The switches must be set up individually for each puzzle though, as they recognise which puzzles have been solved and which rocks have been used, and allow the player to leave the map and the puzzle still be solved. I used 3 boulders when I was figuring this out. You can easily use more than that without it becoming more complex to set up, but you'll need the extra switches and variables. Variables Rock_X_Location - Stores X location of the boulder that the player is about to push. Rock_Y_Location - Stores Y location of the boulder that the player is about to push. Pushing_Towards_X - Stores X location that the boulder is currently being pushed to by the player. Pushing_Towards_Y - Stores Y location that the boulder is currently being pushed to by the player. Terrain_Tag - Stores terrain tag of the location it is being pushed to. Goal_X_Location - X location of first possible solution. Goal_Y_Location - Y location of first possible solution. Goal_2X_Location - - X location of second possible solution. Goal_2Y_Location - Y location of second possible solution. Goal_3X_Location- X location of third possible solution. Goal_3Y_Location - Y location of third possible solution. Switches Boulder1_Solved - Switches on if any boulder has been pushed into goal location 1. Boulder2_Solved - Switches on if any boulder has been pushed into goal location 2. Boulder3_Solved - Switches on if any boulder has been pushed into goal location 3. Boulder1_Used - Switches on if boulder 1 has been pushed into any goal location Boulder2_Used - Switches on if boulder 2 has been pushed into any goal location Boulder3_Used - Switches on if boulder 3 has been pushed into any goal location To give this a sense of meaning, here's the cave where I'm setting up this puzzle: You can see the three boulders. I've named them 'Boulder1', 'Boulder2', 'Boulder3' for convenience. The three 'empty' events are locations where the boulders can be pushed into to enable our hero to cross the water. These events are named 'Solved1', 'Solved2', 'Solved3'. You might notice that it's possible for either of the two boulders near where the hero is standing to be used for either of two goal locations. I have considered this. Let's look at the event pages. This is the first page of Boulder1. If you read the basic part of my tutorial first, you'll notice that the general structure is pretty similar. We check the rock's current position, which way the player is pushing it, it's new position, and the terrain tag of the new position. If the terrain tag is the one for water, it makes a 'splash' and falls in. Then comes the extra bit.... It gets the data for the variables 'Goal_X_Location', 'Goal_Y_Location' etc. from the positions of the events which are at the goal locations. We then need conditional branches to check whether the rock has been pushed into ANY of the possible goals in the area. This is done by using branches of the form: Conditional branch: Pushing_Towards_X = Goal_X_Location Pushing_Towards_Y = Goal_Y_Location Branch End Branch End Repeat this for each goal location. Within these conditional branches, we need to flick on the switches that indicate which boulder we have pushed into the water, and at which goal location. This is why I numbered my boulder events and goal events. If it's pushed into water (as recognised by the terrain tag), self switch A turns on, which is just a blank page. This is just so that the boulder is not able to move if it's in the water (eg. if the player stood at the waters edge and pushed). The reason I didn't use the A switch to allow the player to cross the boulder is because depending on where the boulder is placed, it might form either an East-West bridge or a North-South bridge. As such, this movement is tied to the 'goal' events which appear when the rock is moved into place. ((I used 'empty' comments for the sole purpose of spacing this out into sections so it looks neater and was easier for me to work on)) This event above is Boulder1. The other boulders look exactly the same, except that the switch turned on when they fall into place is 'Boulder2_Used' or 'Boulder3_Used', etc. etc. for however many boulders you have. ((My switches for this include the area name, in case I later want to use a similar puzzle on a different dungeon)) Okay, this has probably been slightly confusing. I'm trying hard to keep it as organised as I can and sometimes I have to look back and think things through again. Hopefully looking at the other pages of the events will help all these switches and variables make more sense. This is pages 2 and 3 of the boulder events: Page 2 is empty and is triggered whenever the boulder falls into water. It's just there so that it stays put and acts as an unmovable object. Page 3 is triggered when this particular boulder has been pushed into a goal location. It makes the original boulder event invisible. Now let's finally get to these 'goal' events... Page 1 is blank and has no image. Because having a crossing before a boulder has been pushed here would defeat the purpose. So, page 2... Looks rather familiar, huh? It's the same eventing as you may remember from the basic tutorial here, which triggers a self-switch when the player touches it and allows them to cross in a certain direction. This activates if the switch 'Boulder1_Solved' is on. Not to be confused with 'Boulder1_Used'. The 'solved' switches correspond to the goal or solution locations, and can be triggered by any boulder if it is pushed into the goal location. Then as you may guess, the B and C self-switch pages are exactly the same as before. .... done. Finally. Let's see it in action!(unfortunately without the pretty mapping this time)