Hello everyone,
(you can skip to mechanics if you don't want to read the intro).
I'm currently working on a battle system for my game. I think I've learned from my past experiences developing games that I need to be vigilant about how complex I make things.
I have a tendency to over-complicate things to the point where it gets bogged in details. I often stumble upon indie games who are a lot of fun with very simple designs, art wise or mechanic wise.
Anyhow, this time around,
I want to make sure my foundations are simple and fun. The reason I'm creating this thread here is to discuss with other members User Interface (U.I.) and the mechanics I have in mind so I can get some feedback. When you're alone developing something, you are so close to it you sometimes miss what others perceive as glaring flaws.
Mechanics: Initial Core Concepts:1.
Health Unit: I'd like to keep everything low not unlike
The Darkest Dungeon. I'd like to stay within the realm of 1 to 10 if at all possible. I like low numbers, they are more representatives as abstractions than high numbers.
2.
Character Health: I'm thinking the player character would start with something around 10 health. This should give you an idea of what damage increments represent what to the player.
3.
Stamina:
a. I want stamina to be a critical aspect of battle management. In other words, spamming attacks should not be an option, there should be more strategy to it.

b. This bar represents the stamina bar. It can be considered as magic points to some extent. The difference being that every action in battle requires to spend stamina.
c.
Stamina regenerates over time. So, unlike magic points, you can never run out.
d. Actions have a different stamina point (SP) cost. Blocking might cost
x, while a certain attack might cost
y and a different attack cost
z.
4.
Danger Meter:
Under punching bag in the picture below, you'll notice a skull with a meter next to it. That'd be the Danger Meter. Much like the stamina bar, it fills up over time. It's similar to the active time battle of
Final Fantasy in that aspect.

I'd like the A.I. to select a random attack from database when the meter is filled up.
5. Actions in battle.a. In the picture with the punching bag, you'll notice four circles of four different colors. The idea was to assign a specific action (out of battle) for each color. The colors would then be distributed in the action bar:

b. The yellow arrow moves from left to right. The player needs to press an interaction key to stop when the action he/she wants is selected.
c. When the action is selected, it triggers in battle, reducing the stamina.
d. In other words: three things are dynamic in battle: the stamina bar regenerates, the danger bar for the enemy and the yellow arrow.
Self-Criticism:1. Too. Complex. See what I meant when I said I tend make things too complex. There are too many variables right now so I want to reduce it.
2. Streamlining:One way to simplify things would be to get rid of the various colors altogether. This also solves assigning actions to various colors. It's too complex for the score of game I'm going for.
One way would be to have two colors on the bar: green (success) and red (failure).

When you succeed, you get to choose an action from a list of action. When you fail, you lose some stamina as penalty.
Every time, the segmented bars layout are randomized when a selection is made, whether it's green (success) or red (failure).
3. Problem with #2.:
It's still a two step process; make the right selection AND THEN choose an action. Still needlessly complex.
4. Another alternative:
Keep the 4 colors but have them assigned to one action each. In other words, the player doesn't assign an action to a color. It's more simple that way I feel.
Red: Miss
Green: Hit (weak attack)
Yellow: dodge
Purple: Hit (strong attack)
That way, it'd be a bit tactical without being overly complex.
5. Dodging:
Dodging successfully should be rewarding to the player. Only... what's the best way of dealing with that mechanic in particular?
You can't ask the player
to trigger the dodging at the exact same time the enemy attacks, that would be impossible.
I was thinking of this: when the player selects dodging (yellow) he holds down the interaction key. During that time, stamina decreases instead of regenerating but he is
actively dodging. During that time, any attack triggered by the enemy is automatically dodged.
It adds a layer of complexity but I don't know how to otherwise handle it.
6. Player stats vs enemy stats:
I'd like the player stats to be processed with the enemy stats. A skilled enemy would mean more red areas on the battle meter (more chances to miss) while an unskilled one would mean more green and purple areas.
This means adding some sort of combat proficiency attribute to the player character and each foe in the game. I feel like it's doable and not overly complex.
7. Weak hits VS Strong hits.What would be the difference between the two. I'm thinking of a risk/reward system. Green hits should be more prevalent and easier to target with the arrow while purple hits should be fewer and harder to target (but provide more damage output).
Logically, I'd need to have a different stamina cost for the weak hits and the strong hits. But then there wouldn't be enough of an advantage to select purple hits.
I could just change strong hits with critical hits and have both normal green hits and purple hits have the same stamina cost. That'd be more simple to handle.
8. Long range vs melee:
As it stands right now, I'd like players to be able to move in battle BUT that really adds complexity to the whole thing.
Each tiled movement should cost stamina for the player and danger meter for the foe.
I need to be careful not to be in a situation where the player can just move away continuously when the foe comes closer.
How would I handle long range combat then? In melee I can contrast the player's combat stat with the monster... but what about ranged attacks though?
Then again, I could have a in-built artificial foe statistic based on the distance separating the player with the monster to proceed with my contrasting. I.e.: four tiles: 4 Five tiles: 5 Six tiles: six... etc...
That could work. But again, it adds a lot of complexity to the whole thing.
So this is what I have in mind. As you can see, a lot of brainstorming going on. I'd like to have a conversation about those mechanics with you guys.
Thanks for reading!
Z.