‍Reviving Dead Minions

The first way we can give our boss backup is by letting them bring defeated monsters back to life. Our battle troop needs our boss enemy along with as many minions as we want (in this case, we’ll have two goblins as the minions). We don’t need any special events here, since we can give our boss the power to revive its minions with a skill.

While we could use the default Raise skills, those don’t heal the targets fully so it’s better to make our boss a unique healing skill to fully heal a dead ally. This also lets us adjust the MP cost if we want so our boss can continuously bring back its minions or make sure there’s a limit.

Once we’re happy with the skill, we can add it to our boss’ Action Patterns and our boss is ready to revive its fallen minions!

Then we can playtest the battle to make sure it’s all working properly. We can also make adjustments while testing to make sure it’ll be fun for our players. If our boss is reviving minions way too often then we could lower the skill’s rating or set it to only be used on certain turns or when our boss’ HP is low. Or if we wanted to make the battle more challenging we could change the skill to revive every dead minion at once, and make our players reconsider leaving the boss for last.

Summoning a Random Number of Minions

Now that our boss can revive allies to ‘summon’ more minions to the battle, we can consider other aspects of the battle. What if this boss is one that you have to defeat multiple times throughout the game? It could feel repetitive if our boss always has two minions at its side, so what if we randomized the number of possible minions? That way our players can’t know just how many goblins they’ll be facing (will it be just one? Seven?) alongside the boss, so they’ll make sure to heal and prepare before jumping into battle.

For this tutorial we’ll stick with two possible minions, so let’s put our goblins next to our boss. But this time, we need to right click on them in the window and check the ‘Appear Mid-Battle’ option. This will fade them out in the window and if we were to playtest right now then we’d be facing the boss without any minions.

With our minions hidden by default, we can move on to the battle event where they’ll be randomly summoned. The first thing we need to decide is when these minions are going to appear by setting the Conditions section for the battle event page. We could have them appear later in the battle by choosing a specific turn or when our boss’ HP starts to get low, but for ease of testing, let’s have them appear on Turn 0, right at the start of the battle.

Then we can actually make our goblins appear. The simplest way to do this is to set a variable to randomly choose a number between 1 and 2, and then have a conditional branch set to run if the variable is 1 (meaning it should run 50% of the time). When that conditional branch runs, it will have the goblin show up with the Enemy Appear command that can be found on the third page of event commands. Then we can just copy and paste that for each possible minion, making sure to change the targeted enemy in the Enemy Appear command each time.

When we’ve prepared all of our minions, we can playtest to make sure they’re appearing properly. Since we set them to appear at the start of battle it’s easy to restart and make sure that our minions are randomly showing up.

Now, this works perfectly well, but by default the Enemy Appear command just has our goblins fade into existence. What if we wanted a bit of extra flair when our minions show up? Let’s make it so that an animation plays on each minion when it appears and a message plays to tell the players that it was the boss who summoned them. To play an animation on each summoned enemy, let’s put a conditional branch that checks to see if the enemy has appeared after all our summoning sections and then use the Show Battle Command on the goblin that was checked. Here we’ll also turn Switch 1 On, which we’ll get to in a moment. Each possibly summoned goblin needs their own conditional branch, to make sure that the animation will play on the right enemy, so for this example we’ll be making two.

Why not just have the animation play in the first conditional branch? We could do that, but if we have to include any waits or delays when we’re making the goblin appear (such as if we include extra effects) then by default each animation will play fully before the next animation starts. By setting up our animations to play after all our enemies have appeared, we can make them all play at once.

As for our message, we can use a conditional branch that runs if our Switch 1 is On and put our message inside that so that it will only run if at least one goblin was summoned. We can also turn Off our switch there, in case we need it later.

Once we’ve put it all together, our event page looks like this:

Then we can playtest a few more times to make sure it’s working and that our animations and message play properly.

Summoning Random Minions

Our boss can revive minions and have a random number of them appear in battle now, but why limit ourselves to just goblin minions? What if we let our boss possibly summon other enemies, making each time our players face them even more different?

First thing we’ll need are some different enemies, so let’s head over to the enemy tab and give our goblins some company. A devil and zombie sound good, so we can set them up with different stats and skills so that during battles it really feels like we’re facing off against new foes and not just reskinned goblins. It would be best if we can also group them together in the database so that there aren’t random enemies between them, for a reason we’ll get to later.

Our setup will be similar to how we would make just a goblin appear at first, but this time instead of setting our variable to a random number between 1 and 2 we’ll set it to a number between 1 and 4. Then we can add two new conditional branches (one for each new enemy) for if the variable equals 2 or 3, and add in an Enemy Transform command to change our goblin into a devil or zombie. We also want to include a 1 frame wait between the transformation and the enemy’s appearance because the engine needs a moment to update the battler. If we don’t include that wait, there’s a chance that our enemy will be invisible!

Remember how we wanted to have our enemies grouped next to each other in the database? That was because we can shorten the whole sequence if we use a script call, $gameTroop.members()[FOE].transform(ENEMYID); where we’d replace FOE with our enemy’s troop id (since it starts at 0 we need to subtract one from the order we added enemies in, so if our enemy is the second one added to the troop its id would be 1) and ENEMYID would be whatever we wanted it to change in to. Since our enemies are grouped next to each other, we can make it so our random variable chooses between all of those enemy ids plus one. In this case, our enemies ids are 1 to 3, so our variable will choose between 1 and 4. Then our conditional branch can check if the variable is lower than 4, and if so then our enemy will transform using $gameTroop.members()[1].transform($gameVariables.value(1)); .

Once we’ve set up a summoning section for each possible minion, we can playtest and see them all appear!

And now our bosses can summon some extra help when in battle! Bosses aren’t the only places we could use this though, as long as we have 1 enemy not set to ‘Appear Mid-Battle’ we could use these concepts to randomize normal battles without having to make tons of different troops. Where would you use this type of battle events?

‍