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.
Personally I like random encounters. They're simple, fun, and make the game less predictable. I am apparently alone in this because everyone and their mother wants world enemies like in Chrono Trigger or some other game where enemies are shown. I'm willing to do this as I'd like someone to actually play the game, but at the same time I don't just want it it to be your run into them a fight thing. So is there a way to make it so that if the player "touches" the enemy sprite from behind they get a surprise round, and visa versa if the enemy "touches" the player's back?
If I understand that you are trying to say, then yes, this is possible. Unfortunately it requires a lot of redundancy in the coding, and a lot of ugly nested If statements if this is to be done using events. Basically you would have the enemy sprite have an event triggered via Event Touch, and the event page would look something like this:
Code:
Â
PlayerY = Player's Y Coordinate on map
EnemyY = Enemy's Y Coordinate on map
If Player is Facing UP
  If Enemy is Facing UP
    If PlayerY > EnemyY  (meaning the Player is below the Enemy, but "behind" him)
     JUMP TO LABEL: SurpriseAtkOnEnemy
    Else
     JUMP TO LABEL: SurpriseAtkOnPlayer
    End If
   End If
End If
Â
This only covers one block of If statements...there would be three other blocks covering the other possibilities, plus one more for "all other possibilities" (where there isn't a surprise attack because of the directions the player and enemy are facing).
As far as how to implement the "surprise" part of the battle, that's an entirely different subject, and really depends on what you mean by a surprise attack.
If you do decide to go ahead and implement this long set of If structures, it is highly recommended that you use a Common Event so that all enemies can just call that common event and if the code has to be changed, it needs only to be changed in one location.
Hopefully this helps a little. Let us know if you still have more questions.
1) How do you check if the player is behind the monster? There isn't a command for that. So what's important to check?
Well, first of all, for the player to be behind the monster, they have to both be facing the same direction when they interact. So we compare the direction that each is facing.
2) But that's not enough. Because if they're both facing the same way, all that it really says is that one is behind the other--not which one is in front. So we need to check that, too.
If, for example, both are facing up, the one who's Y coordinate is smaller is the one who's in front, and thus getting surprised.
If both are facing down, the larger Y coordinate is in front.
For left, the smaller X coordinate is in front. For right, the larger X coordinate is in front.
The good news about all this: You don't need to enter this stuff more than once, because it can actually be made into a common event that's called from the event code for the monster. All that you need to do is create one common event and call it from each monster event, since you can put "This Event" as an option in a common event.
Uh, let me know if that was unclear. I can probably mock up a screenshot.
Here's the example I had before but shown how it may look in RMXP:
Technically you will also have to have some way of preventing the SurpriseAtkOnHero code flowing straight into the SurpriseAtkOnEnemy code, either with another Jump to Label event or Exit Event Processing Event or something of that nature. I could only fit so much on the screen at once.
Hopefully this helps. Note that this stuff does require a good understanding of events in RMXP, so if this is still confusing, then perhaps you may want to consider looking at some of the basic tutorials about events in RMXP, specifically stuff to do with Switches, Variables, Labels, and Conditional Branches.
If you use the "Set a variable" method that I described, you won't use Jump to Label, and that'll prevent the code issue. (Resists urge to post the XKCD about Goto commands...)
That's a funny little cartoon. Gotos are bad to use in compiled languages but they're often hard to avoid in GUIs like RMXP's. I think they're fine to use in RMXP as long as you know what you're doing
But yeah, use whichever method you feel more comfortable with.
Okay, hopefully I won't get dinged for double posting, but this is the bit with the screenshots.
First, the surprise mechanic itself.
You might want to do that as a common event rather than reinputting all that in every single fight, but you get the idea, I trust-- Stun whichever side was surprised, giving a free turn to the other side. (You can do more than just stun them, of course-- there's a lot you can do with States if you want to.)
Note that this depends on what a variable is set to. (Also note that the surprise variable is reset immediately.) Here's where we set the variable-- a fairly complex common event that looks remarkably like screenshots we've seen earlier.
Things to note: This version checks if either side is surprised. Why not? It's fair for Oi! Punks to have a chance to do that.
This is a common event. It refers to "This Event's X" and Y. That's perfectly kosher. It will refer to the X and Y of the map event that called this event. Neat trick, huh? You can do that with Self Switches and Set Move Route, too.
I used an Else branch to determine if the player is surprised, without a conditional branch. Can you figure out why I could do that?
If they are both facing down and touching, which is the condition for surprise, Monster Y has to be either greater than or less than Player Y-- they can't be equal.. If they touch and aren't facing the same direction, the event doesn't even bother checking for surprise, because that's not the condition.
Anyway, now we need the actual enemy on the map. Meet the Oi! Punk:
Note that it's set to Event Touch-- if the critter walks onto the player, a fight starts, and vice versa.
Move Route is set to Random, Slow, and Low, but if I wanted to make sneaking up on the monster any kind of challenge, I'd change that, perhaps to a Move Route that turns towards the player, steps forward a few steps, and then waits or moves randomly a few times.
I couldn't resist putting in a few SFX for beating the monster. So sue me.
Naturally, I used a Self Switch to remove the monster from the battlefield once you kick the Oi! Punk's butts back to Brighton.
So, there you have it. A complete surprise system.
Unka, I'm running into 2 problems so far. The first is that when the player touches the enemy's back the enemy turns to face the player and negates the surprise check making it a normal battle. The second is that while the check seems to be working for the enemy surprising the player the state changes aren't going into effect.
Yeah I didn't even think about that first problem. That's not going to be easy to solve. I did a brief search for a script that will prevent specific events from facing the player when triggered, but I couldn't find anything. You may want to search some more, otherwise perhaps put a request in the Script Request forum. I'm sure it can't be that difficult to write.
I did try turning Direction Fix ON as the first event, but that doesn't work because the event faces the player immediately before the first event. I could give you a few ideas of how to do this event-based if you can't get a script, but it really depends on how the enemies are moving. Are they moving randomly, or do they have set move routes?
I'm not sure about your second question right now.
Actually the second question is already solved. I was an idiot and tested it with only a single enemy troop instead of multiples so it happened so quickly that I didn't even notice it ... maybe put some kind of delay in it.
Maybe you could adjust the enemy Move Route? Turn Direction Fix ON, then have the enemy change facing manually? Don't have time to test this right now, but it might work...
Random would be bad, no matter what, I think. Better to put a little thought into a move route anyway-- that way a player can try to figure out how to best exploit it.
