Enemy Encounters: What You're Doing Wrong

Pretty much every RPG makes use of battle encounters as its primary gameplay mechanic. In some RPGs, battles are the only real gameplay in the whole game—I’ve seen lots of games where the whole purpose of walking around on some maps is to just go from one battle to another. Most of the time, your characters’ skills, stats, items, etc are all based around their uses in battle. The battle system is the core of nearly every RPG, but it seems like lots of RPG designers put relatively little thought into the battles themselves.

Enemy Encounters: What You're Doing Wrong

There are lots of ways to handle RPG battles; not just the battle system itself, but even elements of the game that surround and connect to them. This article is going to cover some aspects of battle systems that deserve more thought than RPG designers may realize.

Encounter Types

Most battles happen on a different screen than the regular map screen: the player will encounter a monster and the entire perspective of the game will shift. This disconnect between map exploration and battle scenarios is a trademark of 2D RPGs. There’s more than one way to initiate these encounters; and the different possibilities have their own strengths and weaknesses.

The default encounter type (and by far the most popular) in RPG Maker is the random encounter. There are some notable disadvantages to this; mainly in that it can cause tremendous frustration for the player. If he’s trying to get somewhere, the monster encounters are just going to be getting in his way. If he wants to grind, then he needs to walk around in circles waiting for a monster.


The alternative is to have the enemies visible roaming around the map; when they bump into the player, the battle starts. This method adds an extra gameplay scenario as the player dodges or races monsters on the map. It does have its own difficulties: it requires more unique monster sprites and some amount of balancing is required when it comes to monster placement and respawning.

Don’t feel limited by those two methods; you can use one of them and put your own tweak on it to add to the gameplay, or you can come up with other ways—for example, battles that are only triggered via story events. I would strongly suggest that you don’t use a mixture of the two primary methods: a player will get easily confused and overwhelmed if some battles are initiated randomly while others are represented on the map. That’s the kind of inconsistency that we should avoid in game design.

Whichever approach you take, you should make sure to incorporate it into the battle itself. For example, if you use on-map encounters, there are a bunch of things that you can do that take advantage of the system. Here’s an easy example: first strikes. If the player sneaks up behind the monster, he has initiative in battle; but if the monster gets the player from behind, the enemies have the initiative. You could even do more with the events on the map: instead of having the monster reward an item or gold in the battle screen, maybe the monster sprite can turn into a treasure chest after it is defeated.

It’s a little more difficult to find ways to make random encounters more interesting. At the very least; taking an approach similar to the Pokémon tall-grass example would be able to circumvent a lot of player frustration. You can also have items, skills or equipment that change the rate of encounters. If the player has more control over these, he will be less likely to get frustrated and blame the designer. I’ve also seen games that feature an “encounter rate meter” or some sort; so the player has a visual clue that lets him know when to expect the next battle. Just make sure that whatever you do, your encounter rates aren’t too high or too random. There is nothing worse than being bombarded with random battles after taking only one or two steps.

What you’re doing wrong: not incorporating the encounter method into the battles and the rest of the game.

Battle Length, Difficulty and Complexity

This is something that game designers will talk about a lot: many RPG Maker users will be proud to admit that they put a lot of work into making their battles difficult and force the player to use strategy. They don’t want the player to be able to “just press attack” to get through the whole battle. That’s awesome; it’s a good start.

Unfortunately, it isn’t always the best option. While that’s great for most battles, you need to be able to balance that with the fact that the player will be getting into a lot of battles. If each battle requires a lot of strategy while the player figures out the best method to defeat the enemy; and how to best spend his MP, etc—then the player will quickly become frustrated.

Remember the player’s goal in each section of your game. For example, if the player is trying to solve a puzzle within a dungeon, throwing a bunch of difficult battles at him is only going to get in the way of that goal. In fact, by the time he has gone through five or six tough fights, he might not even remember what the original goal was. In places with specific goals that demand the player’s attention, you might want to set a very low encounter rate, or possibly no encounters at all. Let’s face it: sometimes battles just get in the way.


Battle difficulty and complexity can be good; but that has to be balanced with the amount of battles. Remember that the most valuable thing to a player is his time. If your battles are too long, then the player will get frustrated. If your battles come about too often, he’ll also get frustrated. If you want your game to include complex and difficult battles, there should be less of them. If your game’s battles are more about brute strength and grinding through, then you can have a little more. If—like most games—you have some of each, you’re going to need to do a bit of testing to find the perfect ratio. It’s important to settle on a balance somewhere in the middle. And remember—if you have to, err on the side of making things easier for the players. If you want your player to get through your game to enjoy your oh-so-awesome story twists, then don’t make it a chore for him to get there.

What you’re doing wrong: stalling the player when he wants to progress through your game.

Grinding

A lot of people hate grinding. Some people enjoy it. When you’re designing your RPG encounters, it’s important to find a way to keep both groups happy. I’ve played games where grinding is necessary to continue—and that can get very boring. I’ve also played games that take the opposite approach and don’t allow the player to grind (this can happen with enemies that level with the hero, which almost seems to make leveling pointless in the first place).

Typically, you don’t want to force your player (or expect him) to grind—it goes back to the idea of preventing your player from progressing through the game. On the other hand, if a player wants to grind, the game should find a way to reward him for it without breaking the balance of the whole game.


When a player grinds, he does it in order to feel his characters get stronger. He needs a tangible reward, and that typically isn’t just money or item-drops. The reward for a player who likes to grind is to feel the change in battle pace—the enemies fall faster. When you balance a section of your game, try to build this progression into the enemies so it feels natural. At the beginning of the area, the enemies may be difficult, but at the end, the player should be strong enough to “spam the attack button” and come through unscathed. That is the kind of progression that players look for when they grind, and if you can incorporate that into the natural balance of your enemies, then you should be able to satisfy both groups of players.

Obviously this depends on the mechanics of your game, but as a general rule: the player should feel a significant difference when fighting enemies at the beginning of an area and when fighting the same enemy at the end of the area. Whether you use random encounters, on-map encounters, or something else—it’s going to require some careful balancing and lots of playtesting in order to achieve the perfect “experience ramp” in each area of your game.

What you’re doing wrong: making grinding necessary and/or not making it rewarding.

A very good tutorial! It's certainly given me a few ideas for my project, especially the different types of encounter. Until now I had only considered on map/standard random encounters.

Your tutorials are always good and fun to read, I especially like your use of pictures and the captions undernearth them :3 Thanks for another great tutorial, frieza! :3

Every time you make a tut I'm impressed, dude thanks for this great work!

I politely disagree. I think using both together is a very good idea when done correctly. One of the bigger problems with using visible monsters only is that clearing out a dungeon leaves it totally deserted forever. Adding in low frequency random encounters makes sure that a dungeon is never completely deserted, and the player still does battle even if they go out of their way to avoid it. If the player has to backtrack to solve puzzles or search side-tracks for more loot, they wont get bored (nor will they get bombarded with too many randoms).

The thing that makes it confusing is that this method is not status quo. As long as you, as a designer, understand that it is not an obvious convention then you can take a few steps to make sure the player understands that there are both random battles AND visible monsters. As long as you make the player aware of it, and then use this system consistently throughout your game, there shouldn't be any problems.

Great article. I really enjoy your series; you've got some great game-design pointers and I like the discussions that they inspire.

Or just... you know... have them respawn. :\

if a player is going out of his way to avoid battles... then he wants to avoid battles. throwing a random battle at him when he clearly doesn't want to fight is just being mean to the player. and in modern game design, that's a bad idea. you want to work WITH your player, not against him. figure out what he wants to do, and help him, and reward him for it.

honestly dude it sounds like you're arguing against your own point here. if a player has to backtrack to solve puzzles, the last thing he wants to do is deal with random battles that get in the way and make it take longer.

now i'm not saying that YOUR WRONG. the points you raise aren't very strong, but you're right that yes it could work if it's done correctly. i'm sure that there are some game designers out there who can mesh the methods perfectly. and if you can do that, awesome! but it's going to take work and lots of thinking—you can't just put them together and say "welp that's that".

really, if you want to do that kind of thing just to be different, you're doing it for the wrong reasons. every choice you make must lead to making the game MORE FUN for the player. making it more frustrating is only going to make him not want to play the game.

Nice tutorial. You always put a lot of thought into what makes the game more interesting, or more fun, for the player, and that's something I think we can forget about sometimes when we become so engrossed in the way WE think the game should play (when we know the right way and the wrong way to play). It's good to be pulled back and reminded of how players might feel about different aspects of the game.

And you've just given me an idea for something a little unique that I can add to mine, to make the grinders and the non-grinders happier :)

You are correct there. I got distracted with some of the points of implementation which are irrelevant since it's entirely up to the designer to make it work (which we both agree on). Please allow me to retract my previous post and start fresh.

Here are the points that I really wanted to make:

1. A system using both is not confusing if it is introduced correctly and used consistently (just like any other unconventional system). This system is not that outlandish, would take only a minimal effort to teach to the player, and has no learning curve.

2. The pros and cons of such a system have the potential to solve (and possibly create) unpleasant gameplay situations just like every other system. These need to be explored and considered by the designer before choosing this, or any other, system.

3. The abilities of the designer, and the type of player the game is designed for, will determine the success of such a system.

4. Implementation of this system can take the same amount of time and care as any other system.

I'll admit my original post was a little bit muddy but I did not expect a lot of resistance. As a veteran member of this forum, your words have a lot of influence over newer, inexperienced designers that are looking for guidance. I only wish to establish that this system shouldn't be so strongly suggested against. Can we agree on that?

yeah that's cool. my point wasn't "don't do this ever", it's "don't do this unless you really know what you're doing". it's fair to say that about anything. even the tiest ideas can turn out okay if they are implemented well. the vast majority of people (especially rm users) wouldn't implement it well, though.

my thing with the confusion wasn't just the basic confusion, but the additional frustration that's possible from such a system. if you are avoiding an enemy, and then a random encounter happens, it will invalidate the player's attempt to avoid the battle in the first place. that kind of thing will turn a player off.

my biggest thesis when it comes to game design is that the designer should work WITH the player. challenge him, yet—but never frustrate him. let him do what he wants to do, and reward him for it.

either way, i only mentioned combining the two methods as a small aside within the article. it doesn't really warrant much discussion.

It could be a good addition to your Tutorial to give examples of some of the alternatives to either system, and what has been done with each system to change it and the pros and cons of them.

For example, as you mentioned, the Random Battles in Pokemon were limited to Tall Grass, Water, and Caves (and in later iterations, deep sand.) They were implemented this way because Pokemon's gameplay somewhat relies on randomness and some grinding to find certain Pokemon, and to level your existing Pokemon. They offered an alternative, avoiding the grass or using the various Repel items to avoid the Random combats. However, to ensure that you weren't just bypassing content and your Pokemon were actually battling and getting some levels, they placed Trainers which are non-random, semi-mandatory battles. They were usually slightly more difficult, but significantly less in number. They also offered a higher experience reward and Money. This was so that they didn't feel like a chore ("aww man, mandatory battles are lame.") and so that they could as developers at least assume you weren't walking around with a level 5 Bulbasaur all game. They also weren't ALL mandatory, so you could avoid them through clever movements and such. This offered a sort of Puzzle element for those that would choose to seek it. Sometimes, engaging a trainer was a way to get an item sooner (by moving them out of the way of a box of bushes that would normally only be accessible with Cut.)

An important thing to note though is that the developers KNEW that some players wouldn't be interested in Random Battles, and offered you ways to avoid them. They also used this in an interesting way with the Flash ability. Certain dungeons were dark, which would ultimately lead to you wandering around aimlessly, possibly missing the exit and being led down dead ends. A player who enjoyed random battles would find that they could progress without teaching a Pokemon the Flash ability, with a little persistence. However, lots of players might have walked into a cave like that and said Frick that I am teaching my Pikachu Flash so I can see where I am going! I thought this was sort of interesting, anyways.