Throwing around ideas around two-row battle system

[Zelgadis85]

I'm about to implement a battle system in my game that allows both actors and enemies to be assigned in either the front row or the back row, each with their advantages and disadvantages. I think I have the basics down alright, but still pondering about the numbers and possible pros and cons.

What I have currently in mind:

Front row has a passive Taunt that means that as long as there are actors or enemies alive in the front row, no member in the back can be targeted by normal attacks. Magic and certain skills are exempt from this rule. Additional advantages in the front row includes increased physical damage done (currently set at 20%).

Back row cannot be targeted by normal attacks as long as the front row stands, thanks to aforementioned Taunt passive state. But all physical damage done from the back row is decreased (currently by 25%).
Note: Back row actors / enemies automatically enter front row if no one from front row is alive anymore, to prevent issues.

Weapons are classified into melee and ranged weapons. Melee weapons cannot attack enemies in the back row. Ranged weapons can attack any enemy regardless of row, but they decrease the defense of the user to compensate (currently by -20%).

Magic is exempt from these rules. There are certain skills that provoke the opposing party to attack the user regardless of row.

I try to keep this rather simple but still somewhat engaging. If you have any good ideas or improvements, I'm all ears. Thanks to everyone in advance!

 

[Milennin]

What happens when your only character alive has melee equipped and the only enemy left is on the backrow? Or does the backrow shift to the front once the front is killed?

 

[Tiamat-86]

no special traits or buffs from rows but some attacks can hit whole row (generally stronger then attacks that ignore row hitting whole party)

edit: dont like linking traits to rows because of the row change effect when party member dies.
no issues with weapon range limitations though.

 

[Zelgadis85]

What happens when your only character alive has melee equipped and the only enemy left is on the backrow? Or does the backrow shift to the front once the front is killed?

Yeah, the back row becomes the new front row. I realized I missed this fact when I made the topic and edited it in, apparently at the same time as you replied.

no special traits or buffs from rows but some attacks can hit whole row (generally stronger then attacks that ignore row hitting whole party)

I'd like to keep the traits and buffs as they are, but your suggestion about row attacks are noted. Thanks!

 

[TheoAllen]

I have a two-rows system that is focused on an arcade experience rather than RPG here.

FREE - Looking for Testers (a closed tech demo)

Engine: RPG Maker VX Ace. Approximately to finish the game: 1 Hour ~ 2 Hours Summary of the game: The game is a derivation from the original game --> https://theoallen.itch.io/eremidia-rise-of-the-deep The game is going to be a boss rush game where you're going to fight 8 stages bosses...

forums.rpgmakerweb.com

While there is no public demo available to try (but I can give you if you want), I explained my two-rows system in the thread (and a gameplay footage). You're free to copy (and alter) my idea.

Note that the row system is exclusively for the player (to control the aggro), not the enemies. This way, I could still design a JRPG style boss battle without thinking about rows for the bosses.

 

[Zelgadis85]

@TheoAllen, your game looks good and while I would probably love to test it, I cannot find the time right now. There are some differences between our visions, though, such as I don't intend to utilize an armor system like yours in my game (looks fancy though). I also kinda want to have both sides of the battle to play on the same terms, so enemies could have a mage and a priest in the back row while there is a knight (or two) protecting them in the front. But to make it a bit easier on the player, magic and ranged weapons should be able to snipe those pests in the back whenever you have them available.

But, all things considered, I might change the style if I feel it becomes too tedious like it is right now. Maybe then I'll consider something like yours if I see it fits the overall theme of my game.

 

[TheoAllen]

such as I don't intend to utilize an armor system like yours in my game (looks fancy though)

That is fine, I just want to highlight my two-rows system and not the armor one (it came way later after the 2-rows system in fact).

I also kinda want to have both sides of the battle to play on the same terms, so enemies could have a mage and a priest in the back row while there is a knight (or two) protecting them in the front.

There are two reasons why I don't do this in my game
- Lore reason: you're fighting a bunch of monsters with no intelligence so that they are too dumb to form a back and front formation.
- Mechanic reason: as I have stated, I mostly concerned with boss battles. Sometimes, it is a single entity that does not require a row to function. And row only for non-boss battle also feels weird. The two-rows exclusive for the players are mainly for your tool to survive, control the aggro, and select the one who needs protection. I don't need this mechanic for enemies. Unless I'm making a PvP where both of the players need to be on equal ground. PvE does not need it.

I don't know about your game. Do you plan to have a boss battle?
How are you going to use a row formation for the boss if you have one?

But to make it a bit easier on the player, magic and ranged weapons should be able to snipe those pests in the back whenever you have them available.

This sounds like Darkest Dungeon, although I never play the game. But the game has rows of more than two, IIRC, it is 4 rows.

Speaking of yours specifically, unless most of not all of the character are able to cast magic or do a ranged attack so that they could be useful in both rows, there is likely that the characters are only suitable in either of the row.
This means that if it dies, your archer/mage now is in danger. Which, in the entire game, you will be locked to just use a single formation. Character A-B is only good at the front, then C-D only good for the back row. Meanwhile, mine focused on the dynamic so that each character has its own functionality in both rows and I aimed to make all of them useful whenever they are in either of the rows.

But then again, I don't know how do you make the playable characters.

I also kinda want to have both sides of the battle to play on the same terms, so enemies could have a mage and a priest in the back row while there is a knight (or two) protecting them in the front.

While this is a good example, are you planning to have all the encounters consisting of caster/ranger and tank for the rest of the game?

 

[Zelgadis85]

@TheoAllen, you raise some good points, which I will go through in a bit.

That is fine, I just want to highlight my two-rows system and not the armor one (it came way later after the 2-rows system in fact).


There are two reasons why I don't do this in my game
- Lore reason: you're fighting a bunch of monsters with no intelligence so that they are too dumb to form a back and front formation.
- Mechanic reason: as I have stated, I mostly concerned with boss battles. Sometimes, it is a single entity that does not require a row to function. And row only for non-boss battle also feels weird. The two-rows exclusive for the players are mainly for your tool to survive, control the aggro, and select the one who needs protection. I don't need this mechanic for enemies. Unless I'm making a PvP where both of the players need to be on equal ground. PvE does not need it.

I don't know about your game. Do you plan to have a boss battle?
How are you going to use a row formation for the boss if you have one?

The majority of random mob encounters are with creatures of little or no intelligence, but there are times when you must fight other humanoids as well. Therefore they should have some organized ranks in battle that make the combat a bit more difficult for the player. There might also be encounters that might reward you if you quickly take out the monsters in the front row (for example, someone or something is being attacked and you can take out the attackers to be rewarded in some way).

Regarding boss battles, of course my game will have them. What's a game without boss battles anyway? Well, in a more serious note, I too would like to make the boss battles stand out as something more than just being damage sponges or equipment checks. Hopefully I can make them like puzzles of some sort, where there might be multiple ways to clear these harder encounters.

The boss battles are not necessarily one-on-many encounters, the enemies can (and in many cases, will) have either assistants or backup available. In some encounters, they might be just out there to deal with the player, but sometimes they might cover the boss to allow him / her / it to prepare for a special move. And there might be a time when a major boss character actually is on the front while lesser minions support him from the back. Sometimes though, the enemies will just line up tidily on the front without any care.

This sounds like Darkest Dungeon, although I never play the game. But the game has rows of more than two, IIRC, it is 4 rows.

Speaking of yours specifically, unless most of not all of the character are able to cast magic or do a ranged attack so that they could be useful in both rows, there is likely that the characters are only suitable in either of the row.
This means that if it dies, your archer/mage now is in danger. Which, in the entire game, you will be locked to just use a single formation. Character A-B is only good at the front, then C-D only good for the back row. Meanwhile, mine focused on the dynamic so that each character has its own functionality in both rows and I aimed to make all of them useful whenever they are in either of the rows.

All characters should be able to equip either a melee weapon or a ranged weapon, depending on their class (which can be freely changed anywhere out of combat after acquiring them). Out of the nine planned PCs, only one comes pre-equipped with a bow, though. The majority will prefer to fight in the front, but they can be equipped with ranged weapons and taken to the back, if the player wishes.

And in the back row, characters can still attack with melee weapons, it's just that they do less damage. The back row is meant more for the frail characters who preferably use magic.

The battle will support a maximum of five people participating at once. Out of the first five you meet, you have a hot-blooded martial artist (who should really stay in the front), an archer and a priest. The other two are a bit of a specialist classes who can do well in either line.

While this is a good example, are you planning to have all the encounters consisting of caster/ranger and tank for the rest of the game?

As I mentioned above, this will not be the case for quite a bit of encounters, but the player will still be challenged by more intelligent enemies from time to time.

 

[TheoAllen]

Regarding boss battles, of course my game will have them. What's a game without boss battles anyway? Well, in a more serious note, I too would like to make the boss battles stand out as something more than just being damage sponges or equipment checks. Hopefully, I can make them like puzzles of some sort, where there might be multiple ways to clear these harder encounters.

The boss battles are not necessarily one-on-many encounters, the enemies can (and in many cases, will) have either assistants or backup available. In some encounters, they might be just out there to deal with the player, but sometimes they might cover the boss to allow him / her / it to prepare for a special move. And there might be a time when a major boss character actually is on the front while lesser minions support him from the back. Sometimes though, the enemies will just line up tidily on the front without any care.

Here is the problem (or may not actually a problem) with the many-to-many boss battle encounter which you need to consider.

• First of all, the boss battle will become easier the more you kill each of them. Then, this just behaves like a standard encounter. However, since it is a boss battle, you want to make this last longer than the standard encounter, thus, you still end up making a damage sponge for all the battle members after all.
• Continuing to the first one, assume it takes 3 turns to kill one boss enemy and you have 4 boss enemies. You need 12 turns to end the battle. It does not sound bad, but once you kill one of them or two, you know you are going to win. The last 6 turns are just an unnecessary turn to drag the battle, except if you want to drag the battle for resources sapping purposes, which might be not fun.
• "I can have the mobs covering the actual boss", the problem with this is when you kill the mob, then the actual boss is pretty much "naked". And it is possible that it is going to be the whole tactic in the game to deal with the boss battle.
• "Sometimes though, the enemies will just line up tidily on the front without any care", then this would mean that the actual row mechanic is not used. Are you saying that the row mechanic is optional?

Based on the current concept, can you think of many variants of boss battles yet? And by that, I don't mean a vague idea of "they will have an assistant to back them up". But an actual mechanic with a detailed breakdown. How many battle members and how the player should react to them.

I personally believe that for every design mechanic, you should start to think of the enemy or boss mechanic as soon as possible after you get the draft on how you control the PCs. Because that would be your whole game content.

All characters should be able to equip either a melee weapon or a ranged weapon, depending on their class (which can be freely changed anywhere out of combat after acquiring them).

This calls for an unrelated question.
"How dangerous is your battle? How often the party member will be knocked out in the battle?"

Why? because based on your weapon idea, there lies a problem.
The melee weapon has the drawback of having attacks reduced by 20% on the back row.
The ranged weapon has no attack drawback but has defense reduced by 20% (thus you're hoping that would make them ideal in the back row).

But if your front row characters knocked out, the ideal way would be swapping weapon from ranged to melee so that you don't have that drawback. Are you also planning to have a weapon swap or should you change the weapon outside the battle?

My idea for this is to have the player character has two weapon slot. One slot is used for a ranged attack in the back row, and another used for the front row. Just like every archer equipped with a dagger or gunner with bayonets. Of course, a two-handed weapon would take two slots and you will be using it for both rows. Thus the whole game would be optimizing the equipment and a plan B for an uncalled situation.

The battle will support a maximum of five people participating at once.

Now that you brought this up, I'm using 2-2 fixed formation.
What about yours? Is the amount of people in the front/back also fixed or will it be flexible? i.e, can it be 1 in the front and the rest are in the back? Or bring them on the front all together? Also how many troop members would be present on average per battle?

I would assume that you're going to use the 5v5 battle for "equality". Then there will be some problem.

• The more the battle members participating in the battle, the more it takes time to finish. Because you need to input each actor and you have 5. Because of that, the player may end up mashing the attack button for all of them so that they could proceed to the next turn. That does not take an account of the battle animation that is played.
• Five enemies also mean that it will take longer to finish. Except if that is what your whole game all about (like, it is a dungeon crawler or something), then that is fine. However, if your game also promotes map exploration and standard RPG design (talking to NPC, environment storytelling, etc), then I don't think making the battle last longer (by having more battle participants) is a good idea.
• "I can make them weak enough that it dies within a few attack or AoE", then it becomes a nuisance or just an exp/gold farm. The enemy does not have a chance to show their attack skill if they have any. Unless if your enemy encounter is just doing basic attack all times.

What I personally use is 4 party members for actors and generally 3 enemies. Sometimes 2 for a weaker encounter, but I find 3 is an ideal composition. Having 4 is just unnecessarily drag the random mob battle. Boss battle has a variety ranged from 1 to 5 troop members though.

----
I also brought up some question for you
- What kind of turn system would you like to use? A standard turn-based one? CTB? ATB? OTB? Or an instant turn/free turn like mine?
- Can you swap the party member back and forth in the middle of the battle? Or can you only do it outside the battle?

 

[Zelgadis85]

@TheoAllen, to make sure this reply doesn't become too long, I'm going to just answer your questions without direct quoting.

Assuming a full party of five PCs, I'd estimate the normal mob encounter to be over in the span of a few rounds (typically, from one to three, unless you're seriously underlevelled and/or equipped). It is alright if a boss battle takes, say, ten rounds to complete, if the combat is engaging (thus, I'd like to avoid simple gear checks and damage sponges). This could be in form of charging for a special attack which requires careful skill use to interrupt, and in case you fail, the boss deals some heavy damage or a variety of states to the party or a PC. The damage should be high enough to make the attack feel like a threat, but not enough to be a total nuisance (I really hate 1-hit party killers, unless the battle is scripted to happen so). In this case, the player's negligence may require to spend another turn to recover, thus allowing the boss (and his possible minions) a free chance to whack some more. Of course, the player should have a clue on how to interrupt this, or if they feel like the boss is already weakened enough, they might ignore the signs and just fight away, hoping the boss dies before the player does (more people than you might think actually do this, heck I do it too at times).

What I meant when I said that sometimes the enemies don't care about the rows is that not necessarily every boss encounter has the boss and the minions in separate rows, kinda forcing the player to concentrate on them in a certain order, but instead you might have two bloodthirsty warriors both "rushing to get the first kill" or something like that (I haven't really designed THAT many boss encounters yet). It may look like the row mechanic is optional in many mob fights, though, but that's alright with me, at least at this point. The player will be informed about rows early on.

The danger of encounters for a properly levelled and equipped party should be somewhat low (not that low that combat only feels like to slow down progress to the next area). Recovery items and magic are available from early on. All major encounters are preceded by a recovery and save point (unless I opt to have saving allowed everywhere, but I kinda dislike that mechanic, grown up on games from the 90s).

The formation is flexible, allowing you to put your entire party of five in either row as long as at least one actor is in the front. But you bring a good point on weapons though. I might add additional advantages and disadvantages on melee and ranged weapons if I can find a good balance there. I'd probably make the melee weapons have a larger attack than ranged weapons of the same level, but that requires some testing and trying things out.

I'd also estimate that a majority of mob encounters won't have five monsters out, so when the player has a full party, they have the advantage in numbers. I also do not want to discourage grinding if that is what the player wants to do, but in no way is grinding for levels and gear is supposed to be mandatory anywhere in the game (well, maybe if I make an optional postgame dungeon with superbosses...) This game is supposed to be a classical JRPG, not a dungeon crawler, so exploration and communication with the NPCs, as well as a good story, are major selling points of the game once it (hopefully) goes out.

My earlier prototype of the game had a weapon slot for ranged and a weapon slot for melee, and I might be implementing it here as well. Either that or allowing to change equipment in combat.

The game will run on CTB battle mechanic. There won't be party changing in battle. (These are the current plans).

I'll probably ask you to try the game out once I manage to release a version that is actually polished to the point of showing others. I'd really like to hear your feedback then.

 

[TheoAllen]

Alright then, I will trust you about your own game content (encounter, boss, etc). Because you're the only one who knows the detail. I'm just bringing up some concerns. I'm in no way would know what you have in mind and what you have done.

There won't be party changing in battle. (These are the current plans).

What I mean by the move back and forth was not about member swapping. But row changing.

I'll probably ask you to try the game out once I manage to release a version that is actually polished to the point of showing others. I'd really like to hear your feedback then.

Yes, in order to be able to give further feedback, I need more context than just the text of the mechanic description. I will wait until then. Also, we can exchange feedback on each other games.

 

[ave36]

I made a simplistic two-row battle system inspired by SNES era Final Fantasy games. Back Row is a state that makes the game draw an actor 10 px behind the normal position, is persistent and toggleable and gives 50% damage from physical attacks and 50% damage of physical attacks. Back Row can be entered by a character in combat from a Tactics skill group that also includes commands such as Wait, Guard and Escape. Caster type characters such as Geas, Melle and Krible start with back row status active.