In-Battle vs. Out-of-Battle?

[Hero_Claive]

Hey y'all,

Just a quick question I wanted to ask to everyone. Which do you find more important: A simpler battle system with tons of customization outside of it (e.g. FFV, Suikoden II) or a complex battle system but less customization/player choice (e.g. Tales, Radiant Historia)?

Obviously the ideal path would be to have both, like Xenoblade, Kingdom Hearts, or FFX, but for the sake of the question, let's assume you had to pick one.

In the context of my game, choosing to implement a complex battle system would force me to forego the nifty class-change system I had in place. Similarly, using a simple ATB battle system allows me a lot more freedom outside of battle. The flip side is that the complex battle system would make the game, characters, and their skills a lot more interesting. Just curious for your feedback! Feel free to mention your own game and how you went about these aspects!

 

[Poryg]

In this question there are so many what ifs that you cannot possibly choose one.
If you spend a lot of time in battles, then simple battles are going to make them very boring.
If you need to grind levels and stuff, then complex battles are definitely an enemy.
If there are cutscenes, then battles can be simple.
On the other hand if there aren't too many battles, then mechanics out of the battle are more important.
If you have complex out of battle mechanics, you can choose to have simple in battle mechanics as an accompaniment or complex battle mechanics pretty freely.

 

[Gonor]

I agree with @Poryg . There are a lot of what ifs.
And in addition I'd like to add that most times it's not either have complex battles (in-battle focus) or complex character customization (out of battle focus) but a good balance between the two.
Even if you have the most complex and challenging and fancy battle system people might not like your game due to the fact that character development is too linear.
On the other hand, if your character customization is too complex with hundreds of skills to choose from and then to equip for battle etc. (equipment falls into this category, too) then also, people might not like your game.

Character customization and battle design are important these days. Try to find a balance you think fits your game mechanics as well as the universe of your game.

So, what I'm saying is: Add a "balanced approach" to your poll.

In the context of my game, choosing to implement a complex battle system would force me to forego the nifty class-change system

Why? You can still have a complex battle system when using a class-change system. Balancing your battles will be more difficult, though.

 

[Wavelength]

I suppose In-Battle mechanics can stand on their own a little better, whereas Outside-of-Battle mechanics without equally interesting In-Battle mechanics will feel more like a disappointment.

In truth, though, the quality of the two types of mechanics are multiplicative. The better you make one, the more that people will appreciate the other. So I strongly recommend giving equal focus to both, and trying to ensure they each contain about the same complexity and depth as each other.

 

[Hero_Claive]

Yeah I get that it's hard to generalize an answer to a question like this, but the question is very relevant in my own project so I guess that's why I proposed it in the first place.

@Poryg : This definitely resonates with me. I think it's hard to step back sometimes and determine how your game ought be played (with lots of grinding or more focus on story, for example). My current game plays somewhat openly with lots of quests and places to explore, but ultimately hinges on the story's progression. I sort of used Xenoblade Chronicles as a model, where there's obviously a ton to do, but the story really defines the game.

@Gonor : The balanced option is the best option, yes, but I'm trying to ask when "balance" isn't a possibility, which would you prefer? Like I said, it's hard to make such a generalization, but like a lot of these threads I was really trying to get feedback I could apply to my own game.

As for your question: My advanced battle system is a system based on momentum, where characters turn red when "Angry", green when "Discouraged" and so on (different emotions change stats/skills/strategies etc). There's four different emotions to cover and eight playable characters, so for an SBS that's 32 sprites (96 if I were using Kaduki). If I were to use a class system where characters can change to, let's say, 10 different classes (I'd like it to be 20), make that 320 sprites. At that point, the scale of the whole project just seems too big. That's my dilemma.

 

[Gonor]

As for your question: My advanced battle system is a system based on momentum, where characters turn red when "Angry", green when "Discouraged" and so on (different emotions change stats/skills/strategies etc). There's four different emotions to cover and eight playable characters, so for an SBS that's 32 sprites (96 if I were using Kaduki). If I were to use a class system where characters can change to, let's say, 10 different classes (I'd like it to be 20), make that 320 sprites. At that point, the scale of the whole project just seems too big. That's my dilemma.

Oh wow, 320 would really be a lot of sprites. I see now, why both systems won't work.
The system itself sounds pretty interesting and I think I would then focus on the battles.

 

[kirbwarrior]

Using the examples you provided, I'd say FFV and Suikoden II did much better than the other games. And Suikoden II was pretty fantastic about hiding the complexities in battle. However;

As for your question: My advanced battle system is a system based on momentum, where characters turn red when "Angry", green when "Discouraged" and so on (different emotions change stats/skills/strategies etc). There's four different emotions to cover and eight playable characters, so for an SBS that's 32 sprites (96 if I were using Kaduki). If I were to use a class system where characters can change to, let's say, 10 different classes (I'd like it to be 20), make that 320 sprites. At that point, the scale of the whole project just seems too big. That's my dilemma.

You already have a large focus for in battle, so if you can't do both then it seems the choice is already made for you.

 

[Hero_Claive]

Well I haven't implemented the battle system yet, I just have a working version of it sitting in another game folder. There's definitely still a decision to be made.

 

[Manofdusk]

@Hero_Claive my immediate question when looking at your idea is: Why not simply have the standard state bubbles take care of your emotional states?

the second question is: Why not use Yanfly's visual state effects, create an animation that causes characters to slowly pulse a color, and use it?
http://yanfly.moe/2016/08/20/yep-114-visual-state-effects-rpg-maker-mv/

 

[Hero_Claive]

@Manofdusk Thanks for the suggestions.

1. I did this at first. To be honest, it looks basic and boring and doesn't feel intuitive. Seeing the characters light up in battle feels real to me. It feels like they're actually responding instead of being described by a small icon next to their HP bar. Just my thoughts, I'm positive others would feel the same way.

2. Thanks for finding that. I'm using Ace, but if you can find a similar script, I'd be more than grateful. For my demo, I've been using Victor's "State Graphics" which doesn't put an effect on actors, but rather changes their sprites altogether (hence the 96 sprite count). I've yet to see a script that adds effects instead of changing the sprite.

 

[Kes]

Bit of a work around, but have you thought of using Yanfly's Ace script State Animations?

Use the Animations tab to create a flashing coloured animation, add that to the State by putting the note <state ani: x> in the State's Note box (x = the animation id), then when the state is applied, you have your colour pulsing on the actor.

I don't want to go into too much detail as this isn't a 'How do I...?' section of the forum, but it's very straightforward.

 

[Hero_Claive]

Holy cow, that works perfectly. Can't believe I didn't find that sooner. Thanks @Kes !