The traditional form of random battles can be found in many 8-bit & 16-bit RPGs; you’re walking along in an empty map and then all of a sudden, you switch to a separate battle screen that is full of enemies. A lot of people hate these kinds of random battles. However, despite their bad reputation, random encounters aren’t all bad. Let’s take a look at some of the pros and cons to random encounters.
Gives the player more opportunities to fight.
Makes boss encounters more unique by contrast.
Adds a level of unpredictability.
Can provide a resource management aspect to gameplay (try to save as much of your MP and items as possible for the boss).
Relatively easy to design & program.
Allows the player to grind XP/gold if they want.
Can become tedious busywork.
Can hurt the game’s flow.
Can break immersion.
Harder to balance.
In Breath of Death VII & Cthulhu Saves the World, here’s how we did our random encounters.
First, I’d decide about how many battles I wanted the player to fight in each dungeon. Then, I would activate a special debug mode in the game that would count the number of steps I take. With this mode counting my steps, I’d go through each dungeon twice. In the first trip, I’d make a beeline for the exit. In the second trip, I’d be very thorough and make some wrong turns & pick up every treasure chest. I’d jot down the step values for each style of going through the dungeon and determine an average between them. I would then use this average, along with the # of battles I want the player to fight to determine an average steps/battle ratio. Finally, I’d add a bit of randomization to the steps/battle ratio (so instead of walking 100 steps and always getting a battle on the 100th step, you might walk 50-150 steps before getting a battle) and put that in the actual game.
The actual battle compositions in our games weren’t entirely random. The game wouldn’t just randomly select a bunch of enemies from that dungeon and throw them at you. Rather, I’d design several enemy parties and the game would randomly pick one of those parties. Some of those enemy parties would have further randomization in enemy quantities – for example, one enemy party might be 2-3 of one enemy and 1-2 of an another so your actual result could be anywhere from 3-5 enemies. Finally, I had a couple of methods to make the dungeon feel like it was getting harder the further you went in. One method would be simply to assign different enemy parties to different maps, so for example, the first map of a dungeon would have easier sets of enemies than the final map of that dungeon. The other method would be to track how many battles in that dungeon the player has fought so far and then after a certain number is reached, switch to a harder set of possible enemy parties.
Then I would use all this information to determine how much XP & gold to give each monster type in order to have the player be at roughly the level of power I want them to be at for each part of the game. Finally, I’d decide upon a number of battles necessary to entirely clear out the dungeon of enemies. This small but significant addition to the traditional random battle formula (i.e. an ending in sight) did a lot to alleviate many player’s complaints about random encounters (although it’s also not without its own weakness).
Will we use the traditional form of random encounters again in a future game? Probably not, unless we’re specifically trying to do another 8-bit style game. In Rain-Slick 3 & 4, we use preset battles at set locations of the map. After that, we’ll probably switch to a system where monsters roam the maps and can be seen (and potentially avoided) in advance. Still, despite their old-school nature, I have a certain amount of fondness for well done random encounters and believe more interesting things could be done with them than has been done in the past. For example, why not have include some potential random encounters that have nothing to do with combat and instead add story or flesh out characters?