Guide to On-Map Encounters

LadyBaskerville

Hell-poodle
Veteran
Joined
Sep 12, 2016
Messages
645
Reaction score
497
First Language
German
Primarily Uses
RMMV
Guide to On-Map Encounters

Hello everyone! In this tutorial I will show you how to create enemies as events on the map instead of random encounters. Everything in this tutorial can be done without plugins or script calls.

This tutorial consists of three sections. In the first section, we will set up a simple enemy event that sends the player into either a fixed or a random battle. The second section deals with respawning enemies and shows a way to let the player choose whether enemies should respawn when the player enters the map or not. Finally, we will create groups of enemies on the map that send the player into a single battle against all enemies in the group.

But before we start, there’s:

Step #0: Setting up the Database

Nothing fancy about this part. I’ve just prepared a few troops of the default enemies to use later.
Database_Troops.png
(One Slime, two Slimes, three Slimes ...)

Now we can get started!

Step #1: Creating basic enemies

On the map of your choice, create a new event and give it a monster graphic. (I’m using a slime, because I like slimes.) In this case, I’ve set the movement to Random. For a more aggressive monster, Approach might make more sense, or Custom for a patrolling guard or something … That’s completely up to you.

Note that the Trigger is set to Event Touch. That’s important. It means that the event starts when the player touches the event or the event touches the player.

Event_Simple.png
(And because it’s important, I drew a red rectangle around it.)

The contents are pretty self-explanatory. The player is sent into a battle against two Slimes (one of the troops I set up in Step #0). Once the battle is over, the Slime event is erased. (In the next section, we will go into further detail on what exactly Erase Event does.)

In this example, the player cannot escape from the battle. You can change that by checking the Can Escape option on Battle Processing (and maybe subtract some of the Party’s gold as a punishment for being such cowards …), but for the purpose of this tutorial, we will leave it like that.

Now we can copy and paste our Slime event all over the map for a Slime dungeon!

But wait – what about all the other Slime troops? Right now, only Slime*2 is being used. We need to change that. But instead of manually changing the Battle Processing of some of the Slimes, let’s choose randomly which troop the player has to fight.

At the top of the Slime Event Contents, set a variable to a random number between 1 and 100.

Variable_Random.png
(Let’s call this variable … uh, I don’t know … how about “Random”?)

Then replace the Battle Processing with a bunch of nested Conditional Branches, like this:

Event_Percent.png
(Above: A bunch of nested Conditional Branches.)

Let’s go through these.

If the random number we created is lower or equal to 25 (a probability of 25% in our setup), the Battle Processing will go to the single-Slime troop.

If that is not the case (the number is larger than 25) and the number is lower or equal to 50 (another 25% chance), the player has to fight two Slimes.

If the number is larger than 50 and lower or equal to 80 (30% chance), the battle is against three slimes.

Should the number be even larger (20% chance), the player will fight a four-Slime troop.

After all of this, the event is erased like before.

Step #2: Toggling respawn

One thing to keep in mind when using Erase Event is that the event will not be permanently gone. When the map is loaded the next time, it will reappear as if nothing happened. In our case that means the Slimes will respawn when the player leaves and reenters the map. That’s great if the player wants to grind; not so great if they just want to quickly pass through an area they have already completed, or if we as game designers want to completely remove the possibility of grinding for balancing reasons.

In the last case, the solution is simple: Instead of using Erase Event, turn a Self Switch (let’s say Self Switch A) on and add a new, blank Event Page to the event. Give this page the condition Self Switch A. Voila, no more respawning Slimes. Ever.

But what if we want to give the player the choice whether or not enemies should respawn? Or maybe we are not quite sure yet which system we want to implement in our final game, and want to leave both possibilities open to us during development. Let’s create a system that allows enemies to respawn depending on a switch.

Event_Toggle.png
(You talk to the crystal to turn the switch on or off. One of those sentences that don’t make much sense outside an RPGMaker tutorial.)

Now that we have a way to control the Respawn switch, let’s move back to the Slime. There’s only one line to add to the existing event.

Event_Enemy1.png
(Whoa! Both Erase Event AND Self Switch!)

Let’s set up a second Event Page. The Trigger is set to Parallel, meaning the event runs in the background if Self Switch A is on. The Conditional Branch checks whether the Respawn switch is on. If that is the case, Self Switch A is switched off and the Slime goes back to its original state. If not, the event is erased immediately, preventing the Parallel Process from going on forever and causing lag.

Event_Enemy2.png
(Red rectangles mean important stuff.)

What happens when the player defeats this Slime? Self Switch A is turned on, but the event is erased before the second page can run. If the player leaves and reenters the map, the event returns, but since Self Switch A is on, the second page runs. If the Respawn switch is on, the Slime respawns, if not, it is deleted again until the player reenters the map.

Step #3: Grouping enemies with Switches

So far, every single enemy event sends the player into a battle against one to four Slimes. One enemy on the map means one battle. If that’s the system you want to use, you may now – finally! – copy and paste your Slime event all over the map. You’re done! If you would rather have one enemy on the map mean one enemy in battle, keep reading.

I will uses bats for this example. Let’s create three identical Events (I called them “Bat#1” for reasons I will explain later) similar to our first Slime example with Battle Processing to Bat*3. Have them turn on a Switch – not a Self Switch – and create a second, empty page with that Switch as a condition. (I called the Switch “Defeated Bats#1” for the reasons I will explain later.)

Event_Group1.png
Event_Group2.png
(If you look closely, you might notice that a few things in the bottom left of the first page are different from the Slime event. Those are just for visuals, you don’t need to worry about them.)

Now, if the player encounters one of the three “Bat#1” events on the map, they fight a battle against three bats and after that, all three bats on the map are gone.

We can now make multiple groups of enemies like that. Let’s copy and paste one of the “Bat#1” events to a different part of the map. Change the name to “Bat#2”. Use a different switch for this bat (I used the one directly underneath “Defeated Bats#1” and called it “Defeated Bats#2”), and make sure to change the switch on both Event Pages. Maybe choose a different troop for this bat, e.g. Bat*2, and duplicate the event accordingly. In the end, your map should look similar to this:

Map_Groups.png
(And a poor, lonesome Slime in the middle, all by himself …)

But what about respawning? Right now, all bats will stay dead, even if the Respawn Switch is on. Let’s create one last event on an inaccessible part of the map (I use the upper left corner for something like this), set it to Parallel and have it turn the “Defeated” switches off if Respawn is on. Don’t forget to erase it after that, it only needs to run once when the player enters the map.

Event_Init_new.png
(You can use the Range option to control multiple switches at once. My “Defeated” switches have the IDs 22 and 23.)

And that’s it for this tutorial! I hope you enjoyed it and maybe got some new ideas about what to do with on-map encounters. There’s still much about this topic that I haven’t touched yet, and many aspects of this tutorial can be done using different methods (for example by remote-controlling Self Switches via script calls, many thanks to Dad3353 for pointing that out to me!)

If you have any questions about this tutorial or even suggestions for another one, feel free to leave a comment!
 
Last edited:

Raths Rants

Veteran
Veteran
Joined
Mar 9, 2014
Messages
90
Reaction score
13
First Language
English
Primarily Uses
I have been toying with the idea of using this as a common event. When the common event is edited/updated, All events calling it don't have to be updated individually.


I remember reading somewhere that too many common events lag your game. Any insight on that?
 

LadyBaskerville

Hell-poodle
Veteran
Joined
Sep 12, 2016
Messages
645
Reaction score
497
First Language
German
Primarily Uses
RMMV
Using a Common Event is a good idea, especially if the logic for choosing the enemy troop is the same on many enemy events. You might already know this, but I recently found out that you can even use Self Switches / Erase Event in a Common Event - these commands will apply to the event from which the Common Event is called.


Lag from Common Events is usually only caused if the event runs constantly on Parallel Process in the background (60 times a second, in the worst case). If the Common Events are only called once from inside an enemy event, for example, it shoudn't cause any problems since the Common Events are "inactive" for the rest of the time.
 

Raths Rants

Veteran
Veteran
Joined
Mar 9, 2014
Messages
90
Reaction score
13
First Language
English
Primarily Uses
Thanks for the clarification!
 

Phil32

Veteran
Veteran
Joined
May 31, 2016
Messages
69
Reaction score
11
First Language
English
Primarily Uses
Didn't even think of doing a variable for some randomness to what kind of encounter you can get. Very smart and helpful! Thanks!
 

Doktor_Q

I'm not a real doktor, but I am a real Q
Veteran
Joined
Aug 1, 2016
Messages
652
Reaction score
379
First Language
English
Primarily Uses
RMMV
Rather than a parallel process, could you could use an auto-run event for the enemy respawn page? Or would that cause some lag or delays?


Also, I could see setting up a lot more complicated respawning conditions, like a countdown of room changes before they return, or comparing the "time of death" with the current time, to set a respawn timer. It would probably require a plugin for the keeping track of numbers per event, though.
 

LadyBaskerville

Hell-poodle
Veteran
Joined
Sep 12, 2016
Messages
645
Reaction score
497
First Language
German
Primarily Uses
RMMV
Autorun should work as well, since the event turns itself to a different page immediately. When there are are many enemies on the map, however, or some "cutscene event" (also set to autorun) is executed, it might take longer for the enemy events to react, since autorun events are executed one at a time while multiple parallel processes can run simultaneously.


Your respawning conditions are good ideas! I would make a single variable to track the number of room changes / set it equal to the current system time (script call?) or the number of steps the player has made and update it when needed. When an enemy is defeated, I would store the current value of that variable somewhere seperately for each enemy (Self Variables would probably make it a lot more practical). Then before the enemy respawns it's just a matter of comparing the two variables and deciding whether it should respawn already or be deleted again until the player re-enters the map.
 

Harrumi

Veteran
Veteran
Joined
Dec 13, 2017
Messages
168
Reaction score
541
First Language
English
Primarily Uses
RMMV
Guide to On-Map Encounters


Hello everyone! In this tutorial I will show you how to create enemies as events on the map instead of random encounters. Everything in this tutorial can be done without plugins or script calls.


This tutorial consists of three sections. In the first section, we will set up a simple enemy event that sends the player into either a fixed or a random battle. The second section deals with respawning enemies and shows a way to let the player choose whether enemies should respawn when the player enters the map or not. Finally, we will create groups of enemies on the map that send the player into a single battle against all enemies in the group.


But before we start, there’s:


Step #0: Setting up the Database

Nothing fancy about this part. I’ve just prepared a few troops of the default enemies to use later.


View attachment 48582


(One Slime, two Slimes, three Slimes ...)



Now we can get started!


Step #1: Creating basic enemies

On the map of your choice, create a new event and give it a monster graphic. (I’m using a slime, because I like slimes.) In this case, I’ve set the movement to Random. For a more aggressive monster, Approach might make more sense, or Custom for a patrolling guard or something … That’s completely up to you.


Note that the Trigger is set to Event Touch. That’s important. It means that the event starts when the player touches the event or the event touches the player.


View attachment 48585


(And because it’s important, I drew a red rectangle around it.)


The contents are pretty self-explanatory. The player is sent into a battle against two Slimes (one of the troops I set up in Step #0). Once the battle is over, the Slime event is erased. (In the next section, we will go into further detail on what exactly Erase Event does.)


In this example, the player cannot escape from the battle. You can change that by checking the Can Escape option on Battle Processing (and maybe subtract some of the Party’s gold as a punishment for being such cowards …), but for the purpose of this tutorial, we will leave it like that.


Now we can copy and paste our Slime event all over the map for a Slime dungeon!


But wait – what about all the other Slime troops? Right now, only Slime*2 is being used. We need to change that. But instead of manually changing the Battle Processing of some of the Slimes, let’s choose randomly which troop the player has to fight.


At the top of the Slime Event Contents, set a variable to a random number between 1 and 100.


View attachment 48586


(Let’s call this variable … uh, I don’t know … how about “Random”?)


Then replace the Battle Processing with a bunch of nested Conditional Branches, like this:


View attachment 48590


(Above: A bunch of nested Conditional Branches.)


Let’s go through these.


If the random number we created is lower or equal to 25 (a probability of 25% in our setup), the Battle Processing will go to the single-Slime troop.


If that is not the case (the number is larger than 25) and the number is lower or equal to 50 (another 25% chance), the player has to fight two Slimes.


If the number is larger than 50 and lower or equal to 80 (30% chance), the battle is against three slimes.


Should the number be even larger (20% chance), the player will fight a four-Slime troop.


After all of this, the event is erased like before.


Step #2: Toggling respawn

One thing to keep in mind when using Erase Event is that the event will not be permanently gone. When the map is loaded the next time, it will reappear as if nothing happened. In our case that means the Slimes will respawn when the player leaves and reenters the map. That’s great if the player wants to grind; not so great if they just want to quickly pass through an area they have already completed, or if we as game designers want to completely remove the possibility of grinding for balancing reasons.


In the last case, the solution is simple: Instead of using Erase Event, turn a Self Switch (let’s say Self Switch A) on and add a new, blank Event Page to the event. Give this page the condition Self Switch A. Voila, no more respawning Slimes. Ever.


But what if we want to give the player the choice whether or not enemies should respawn? Or maybe we are not quite sure yet which system we want to implement in our final game, and want to leave both possibilities open to us during development. Let’s create a system that allows enemies to respawn depending on a switch.


View attachment 48598


(You talk to the crystal to turn the switch on or off. One of those sentences that don’t make much sense outside an RPGMaker tutorial.)


Now that we have a way to control the Respawn switch, let’s move back to the Slime. There’s only one line to add to the existing event.


View attachment 48604


(Whoa! Both Erase Event AND Self Switch!)


Let’s set up a second Event Page. The Trigger is set to Parallel, meaning the event runs in the background if Self Switch A is on. The Conditional Branch checks whether the Respawn switch is on. If that is the case, Self Switch A is switched off and the Slime goes back to its original state. If not, the event is erased immediately, preventing the Parallel Process from going on forever and causing lag.


View attachment 48605


(Red rectangles mean important stuff.)


What happens when the player defeats this Slime? Self Switch A is turned on, but the event is erased before the second page can run. If the player leaves and reenters the map, the event returns, but since Self Switch A is on, the second page runs. If the Respawn switch is on, the Slime respawns, if not, it is deleted again until the player reenters the map.



Step #3: Grouping enemies with Switches

So far, every single enemy event sends the player into a battle against one to four Slimes. One enemy on the map means one battle. If that’s the system you want to use, you may now – finally! – copy and paste your Slime event all over the map. You’re done! If you would rather have one enemy on the map mean one enemy in battle, keep reading.


I will uses bats for this example. Let’s create three identical Events (I called them “Bat#1” for reasons I will explain later) similar to our first Slime example with Battle Processing to Bat*3. Have them turn on a Switch – not a Self Switch – and create a second, empty page with that Switch as a condition. (I called the Switch “Defeated Bats#1” for the reasons I will explain later.)


View attachment 48608


View attachment 48609


(If you look closely, you might notice that a few things in the bottom left of the first page are different from the Slime event. Those are just for visuals, you don’t need to worry about them.)


Now, if the player encounters one of the three “Bat#1” events on the map, they fight a battle against three bats and after that, all three bats on the map are gone.


We can now make multiple groups of enemies like that. Let’s copy and paste one of the “Bat#1” events to a different part of the map. Change the name to “Bat#2”. Use a different switch for this bat (I used the one directly underneath “Defeated Bats#1” and called it “Defeated Bats#2”), and make sure to change the switch on both Event Pages. Maybe choose a different troop for this bat, e.g. Bat*2, and duplicate the event accordingly. In the end, your map should look similar to this:


View attachment 48615


(And a poor, lonesome Slime in the middle, all by himself …)


But what about respawning? Right now, all bats will stay dead, even if the Respawn Switch is on. Let’s create one last event on an inaccessible part of the map (I use the upper left corner for something like this), set it to Parallel and have it turn the “Defeated” switches off if Respawn is on. Don’t forget to erase it after that, it only needs to run once when the player enters the map.


View attachment 48617


(You can use the Range option to control multiple switches at once. My “Defeated” switches have the IDs 22 and 23.)



And that’s it for this tutorial! I hope you enjoyed it and maybe got some new ideas about what to do with on-map encounters. There’s still much about this topic that I haven’t touched yet, and many aspects of this tutorial can be done using different methods (for example by remote-controlling Self Switches via script calls, many thanks to Dad3353 for pointing that out to me!)


If you have any questions about this tutorial or even suggestions for another one, feel free to leave a comment!

Thank you! You legit fixed a problem I had going on conflicting with yanfly region restrictions. My next question, is possible to make it so the event has a chance of happening instead of it being a sure thing?
 

LadyBaskerville

Hell-poodle
Veteran
Joined
Sep 12, 2016
Messages
645
Reaction score
497
First Language
German
Primarily Uses
RMMV
To give the enemy a random chance to appear at all, I would make the current first page conditioned by a self switch, and then add a new page to the event as the new first page. Set it to Parallel, so it executes immediately when the map is loaded. On that page, set a variable to a random number and use a conditional branch to determine the outcome (like with the troop variations above): If the random variable is below (or above) a certain value, turn on the self switch you used as a condition for what used to be the first event page - that way, the event will proceed like normal. In the else branch, erase the event instead, so it will be gone until the map is re-entered. (If you want, I can put together some example screenshots tomorrow; it's a bit confusing just with text.)
Does this help, or were you looking for something different?
 

Harrumi

Veteran
Veteran
Joined
Dec 13, 2017
Messages
168
Reaction score
541
First Language
English
Primarily Uses
RMMV
Yes absolutely it does! However, if you don't mind, screenshots would be lovely. Thank you. :)
 

LadyBaskerville

Hell-poodle
Veteran
Joined
Sep 12, 2016
Messages
645
Reaction score
497
First Language
German
Primarily Uses
RMMV
Alright :) I'll put them up tomorrow, since I already shut down my PC for the night.
 

Harrumi

Veteran
Veteran
Joined
Dec 13, 2017
Messages
168
Reaction score
541
First Language
English
Primarily Uses
RMMV
Thank you very much!! I appreciate it!
 

Canini

Veteran
Veteran
Joined
Mar 29, 2016
Messages
990
Reaction score
662
First Language
Swedish
Primarily Uses
RMVXA
Very nice tutorial. The game I am working on now uses a ABS but a similiar system with enemies as events.
 

LadyBaskerville

Hell-poodle
Veteran
Joined
Sep 12, 2016
Messages
645
Reaction score
497
First Language
German
Primarily Uses
RMMV
@Harrumi Here are the screenshots:
First page: With this random variable + conditional branch setup, the enemy has a 3/5 chance to appear each time the map is entered. (But once it appears, it stays no matter how many times the player leaves and reenters the map.) I used Self Switch B for "enemy appears", because in my setup Self Switch A is already used for "enemy is dead".
RandomlyAppear1.png

Second page: This is exactly the same as previously, only now it is conditioned by the same Self Switch that had a chance to turn on on the first page. RandomlyAppear2.png

Third page: If you do the respawn switch setup, make to turn off both Self Switches when the enemy respawns. If you don't use a self switch for "enemy is dead" and just erase the event when the player defeats the enemy, you don't need this page.RandomlyAppear3.png
 

Harrumi

Veteran
Veteran
Joined
Dec 13, 2017
Messages
168
Reaction score
541
First Language
English
Primarily Uses
RMMV
Thank you! you're amazing, if there was a love button I'd be pressing it!
 

Bryy Miller

Veteran
Veteran
Joined
Aug 7, 2017
Messages
46
Reaction score
73
First Language
English
Primarily Uses
RMMV
I'm going to add this as a pick-up to my unfinished, unstarted list for February.
 

Pyrathas

Veteran
Veteran
Joined
Jul 8, 2018
Messages
91
Reaction score
29
First Language
English
Primarily Uses
RMMV
I saw this once in Dragon Warrior (I think) back in the day for GBC. I'm glad I found this It is exactly what I was looking for!
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Profile Posts

For anyone who has uploaded a game to Steam and wonders if they actually check your game's build when you first upload it, I can personally vouch for Steam.
6 more towns to make in my game. SIX. not done with interiors yet but SIX EXTERIORS.
what to do when you come across a person that has stated "What if I say, f*** their EULA? I could probably get away with it." concerning asset packs sold here... on this site ...
So a guy enters in a bar and walks up to the counter. He looks the bartender with a mysterious look and asks him...
I've wondered for a while now... what is it about the YED SV plugin that just doesn't do transformations... I feel it's how it looks up the battlers honestly.

Forum statistics

Threads
93,494
Messages
912,965
Members
123,029
Latest member
AkieTsuki-02
Top