Controlling Combat Complexity

[Soryuju]

"Simple but deep" is a common paradigm of good combat systems in RPGs. We want mechanics which afford players plenty of opportunities to make meaningful decisions, but we don't want to overwhelm them with heaps of different rules to memorize, especially early on.

(This applies to the non-combat aspects of games as well, though in this topic, I'd like to focus on combat specifically.)

The problem is that as developers, we know our battles inside and out. Throughout the long process of development, we become more familiar with the quirks and details of our systems than any of our players will likely ever be, and the rules we've come to find intuitive may look very different from outside perspectives.

So as a developer, how do you keep the number and complexity of your mechanics in check as your combat systems naturally evolve during development? What's your method for screening new ideas to make sure they're deepening your game rather than just expanding it?

 

[Bellflowers]

Having people play test your builds over and over, pointing out what you changed each time or stating what it is you want to try is pretty much objectively the best way to gauge whether your game is too complex. If you can tell they are confused by how something works or abuse it in a way you didnt intent that is simpler for them then you know you've put complexity over fun.

another thing is that "meaningful decisions" come second to decisions that would ultimately entertain the player. If you have to choose between the two pick the latter every single time

 

[bgillisp]

If your combat system requires an encyclopedia to keep track of all of the acronyms as you have so many different numbers to measure...you made it too complex.

Big offenders of this that I've played are:
Enchanted Arms
Record of Agarest War, though most of that was outside battle and in how you leveled players and got items. In battle it wasn't quite as bad, but it still affected battle due to needing those items from obscure currency #5 to be able to survive.

 

[Milennin]

Best to come up with a few core mechanics and build around those, than to pick as many things you can find that look cool and put them together.

For skills, make skill descriptions easy to understand (without obscuring important information), and make effects have noticeable impact.
For depth, it's important that there should be multiple ways of approaching combat situations, all that are viable in their own way, but that play out differently, so players can feel like they're in control and get to make meaningful choices rather than being railroaded into picking the one superior option in every scenario.
And always remember: less is more.

 

[Soryuju]

Having people play test your builds over and over, pointing out what you changed each time or stating what it is you want to try is pretty much objectively the best way to gauge whether your game is too complex. If you can tell they are confused by how something works or abuse it in a way you didnt intent that is simpler for them then you know you've put complexity over fun.

Running playtests and getting actual concrete feedback is definitely preferable to just guessing at what players can handle, I agree. I was just curious if people had benchmarks for managing complexity while they were still in the earlier design phases and gathering playtest feedback wasn't yet feasible. I know redesigning after playtesting is all but inevitable, but it'd be nice to make smart design choices early on and perhaps reduce the amount that needs to be scrapped later.

@bgillisp

I definitely agree that games with dozens of terms and numbers to keep track of can be more of a chore than entertainment. In particular, I get tired of stat-heavy games which obscure good and bad decisions from the player behind similar attributes such as "armor," "physical resistance," and "damage reduction." I know some people love sitting down with spreadsheets to figure out optimal builds/strategies/skill rotations, but I get burned out on games quickly when I'm spending more time calculating how to play than I am actually playing.

@Milennin

The "few core mechanics" approach seems solid and is what I've been trying to adhere to during my own design process. Sometimes I do wonder if familiar mechanics from other RPGs (like elemental weaknesses) get a pass, though, or if I should be weighing those more equally with my unique mechanics when trying to gauge how complicated combat is overall.

This thread isn't about my game in particular, but I've been attempting to monitor the complexity of my own combat by keeping a list of the major systems the player will regularly interact with (things like "character classes," "all actions cost resources," "buffs and debuffs," "elemental weaknesses/resists," "passive abilities," etc.). I recently came up with an idea that fit very nicely with some of my existing mechanics, but it pushed my list up to 10 items, which spurred me to start thinking about what point the system might become too messy for players to readily dive into. And while making that sort of mistake may just be a natural part of development, if I can already see the pitfall, I figure that I should at least attempt to steer around it.

 

[velan235]

define the core mechanic , and build around it , and don't extend it too much.

I really like for what persona 5 did with the combat. it revovles around hitting weakness and you gain extra turn. if you hit all enemy weakness , you'll get AoE attack that most of the time clear the mobs.

simple , you hit weakness and win. most people could learn this even if they are new to the series.

but here is some twist. did you have the right element for the weakness? if yes , then after some time , your MP depleted, how would you manage your resources?

into mid game , you'll find 'no weakness' enemy, which there are another way to beat them (ie. using bad status) , or some enemies that still stand after AoE bonus.

there are some twist in the future , but it still stay true with weakness mechanic (IIRC , even the final boss still resolve around weakness mechanic)

so I think defining the core mechanic is a must , then later you can add some twist to the mechanic. make it simple and compact but enough twist so player will have many ways to beat the mechanic

 

[Aesica]

One word: Transparency. Allow me to elaborate:

• Stats. I swear, just about every rpgmaker game I've tried out is like HAI HERE'S YOUR TOTALLY-DIFFERENT-THAN-OTHER-RPGMAKER-GAME STATS, AND LOTS OF THEM! Okay great, but what do they do? I was recently playing Skyborn, a fairly well-received rpgmaker game, and while good overall, I ended up eventually turning to google to figure out WTF each stat was for. Turns out I'd been building my characters (especially the main one) completely wrong because of which stats boosted which abilities. Please explain your stats clearly to players, especially if you insist on having a whole bunch of newly made-up ones.
• Skill descriptions. When I learn the "Inferno" spell, a description of "Damages all enemies" isn't very helpful. How strong is it compared to other spells? Does it apply any debuffs, such as damage over time? If so, how strong is that damage over time and how long does it last? Does it deal fire damage or does this game have some sort of weird alternate element system?
• Libra/Scan. If you're using elemental damage, especially several different types, and want it to be more than just an annoying guessing game for players or something they ignore entirely, please include some way to scan foes to determine their weaknesses and strengths. Bonus points if you create your own note tags for including descriptions of the enemies that give a rough idea of what to expect. For example, "The Fire Drake is known for unleashing devastating torrents of flame after it takes a deep breath" will let the player know that, when they see the Fire Drake use "Deep Breath," something worth guarding against will be hitting them next round. Note that Yanfly even has a very basic copypasta Libra you can use if you don't feel like writing your own.

In short, give the players access to information because, as was said in the original post, we developers know our stuff inside and out--we know which enemies are weak to what attacks, we know how strong each skill is in relation to the others, we know of any and all secondary effects a given skill my have, we know which enemies do what, etc. Someone playing for the first time does not, so show them the ropes instead of forcing them to go off and find a guide.

 

[Eschaton]

I will add a caveat to posts made by @Milennin and @velan235, that whatever skills you add to your game need to support your game's core mechanic, or core challenge.

You're making a game on RPG Maker, which means that your core mechanic/challenge is for the player to deplete their enemy's HP to zero before the enemy depletes the player's to zero. A player's skill is determined by the rate at which they can deplete the enemy's HP; the faster HP disappears, the more skilled the player is. In most RPGs, DPS is a direct measure of the player's skill. In most RPGs, incoming DPS is a direct measure of difficulty. Another measure of difficulty is how the enemy can adjust incoming DPS and survive longer. Enemies that can hit hard and keep the player from hitting them hard are even harder.

Now, let's put another layer around this mechanic. The skills you add to the game should really just affect the rate at which damage is dealt or received. Buffs and elemental weakness exploitation are pretty classical means of adjusting this rate.

All things added to gameplay should have as few degrees of separation from "DPS or adjusting DPS" as possible. Because of this, skills that don't do damage such as "Defend/Guard/Wait" are hardly used. So, I suggest that all skills should do damage, even skills designed to adjust the rate of damage per turn.

An enemy buffing itself to slow the rate at which the player depletes the enemy's HP should serve as a little side challenge that briefly diverts the player's attention from the core challenge. After the buff is defeated, the player should be routed back into the core mechanic/challenge of depleting HP. To defeat this side-challenge, the player should have a reliable toolset to counter these enemy buffs. The ability of an enemy to counter the player's buffs can add more difficulty to the enemy, particularly if they are smart enough to use it.

This is all a description of function. Designing things to be purely functional is kind of boring. The other side of this coin is flavor. In addition to the skills you design being functional, they need to be flavorful. They need to be a part of the world and be an extension of the character using that skill. Skills should be as much a gameplay mechanic as it is a part of the story. Flavor should be second to function, but flavor is just as necessary.

But above form and function is a trait that all skills must have: the player must see them as reliable. If a skill doesn't do damage or reliably adjust DPS (read: add a status effect), then that skill is worthless. If the player's first use of a sleep spell doesn't put the enemy they choose to use it on, even a boss, they will never use that sleep spell again. So, in addition to having high-but-not-too-high success rates, things like flavor text and even the enemy's graphics need to convey to the player what skills might be useful. And a precedent should be set early that the skills the players learn will be reliable and useful going forward.

In my opinion, healing is something else outside the typical "DPS or adjusting DPS" mechanics. Depending on how you design your game, you might not even need healing mechanics, and usually stem from enemies having gigantic HP pools but doing relatively little damage to the player, while players have tiny HP pools but do immense damage. Some could argue that such mechanics are imbalanced and require a healing option (for the player of course) to keep balanced, but those ratios are also the norm in JRPGs (the trend-setters Dragon Quest and especially Final Fantasy in particular). But if enemy and player have comparable HP/DPS ratios, you might not even need to bother with healing mechanics during combat, and could completely restore HP after combat ends. I'd consider healing to be a tertiary component to be planned and implemented after the "DPS and adjusting DPS" core mechanics.

Stealth and tanking are just mechanics that can adjust outgoing and incoming DPS based on implementation; in fact, stealth and tanking are flavor rather than function when you really think about it.

Stealing mechanics distract the player from core gameplay if it doesn't do damage, and is particularly useless if the player can't rely on it to work at a reasonable rate. In my experience, stealing doesn't see a lot of use.

Summoning is interesting in that they're really just expensive and flashy spells in some games, or means of controlling enemy behavior or crowd control in others.

After the core "DPS and adjsuting DPS" paradigm and the tertiary healing mechanics are implemented, stealth, tanking, stealing, summoning, and any other flavor-over-function mechanics should be designed and implemented last and should be useful and reliable and not distract too long from just doing HP damage.

But this is my personal design philosophy. Take it with a grain of salt.