by: LadyBaskerville (original source)
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.
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.
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.
Then replace the Battle Processing with a bunch of nested Conditional Branches, like this:
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.
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.
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.
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.)
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:
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.
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!