A few of the thoughts I've been having lately on some relatively straight-forward yet interesting moves we could potentially launch in our upcoming release. Curious to see thoughts on these basic concepts before I really dig down to flesh them out.

High-cost, mid-damage maneuver that increases in damage the lower the target's health is (execution move, basically).

No-damage, high-cost move that allows your OTHER characters to act immediately (for the guard leader specifically). Think Inspiration or Battle Tactics for the high concept. Give this to a single character, and make it a bit pricey.

A Cleave maneuver that deals damage to a selected target, and a percentage of that damage to enemies adjacent to it. Maybe make this one available to everyone, since it's relatively low value.

A counter-strike maneuver that deals minor damage, with an immediate major damage swing against the next target to attack that character during their cooldown -- it's a risk, but with high pay-off. Might need a cooldown to avoid being spammed if down to a single character.

A recover or guarded strike move with basic damage, but heals the user a small amount. Potentially useful if you're afraid of losing the character.

2. I was on this one until I noticed it said characters. I think this one is alright, although because you're giving it to the most powerful character so that the weaker two can act immediately, I feel the cost shouldn't be super high. Basically, I think this could work nicely if it's balanced out okay.

3. This is not possible with the current code. Targets are either an actor, an actor's attack point (leg, etc), or an entire party. To do this we would need to add a target type that can select multiple targets, and add some logic to figure out if enemies are "adjacent" to one another. I like the idea in general though. But it will take a while to implement something like this (definitely won't be ready for next month's release)

4. Also something that we'd need to add coding support to do, but I like it. Maybe the initial attack also applies a "provoke" effect on the enemy so that it is much more likely that the enemy will attack that character, and hence trigger the counter-attack?

5. Sounds nice. Would be cool if it returned maybe 20% of the damage dealt, so players could target the weakest enemies to get the maximum healing effect.

I like what you're on to here, a lot. We need battle code development to be more active to open up some of these types of skills though. I don't have the bandwidth to work on this myself right now, but maybe we can hire another programmer or two to focus on this aspect of the code (it really needs a dedicated "owner"). Architek is doing some work here, but I don't think that he alone will be able to handle everything we want to change/add here by himself.

Roots wrote:3. This is not possible with the current code. Targets are either an actor, an actor's attack point (leg, etc), or an entire party. To do this we would need to add a target type that can select multiple targets, and add some logic to figure out if enemies are "adjacent" to one another. I like the idea in general though. But it will take a while to implement something like this (definitely won't be ready for next month's release)

Hmmm...would the current code allow us to randomize a second target to take minor damage? That would have a similar effect in the short term, at least.

4. Also something that we'd need to add coding support to do, but I like it. Maybe the initial attack also applies a "provoke" effect on the enemy so that it is much more likely that the enemy will attack that character, and hence trigger the counter-attack?

That makes it much less of a risk though...but is possibly better for gameplay. I'd say a large boost, but not a sure one: maybe between 25% and 40% additional weighting.

5. Sounds nice. Would be cool if it returned maybe 20% of the damage dealt, so players could target the weakest enemies to get the maximum healing effect.

A nice addition. Might want to make sure the more vulnerable opponents aren't hard to distinguish though.

Djinn_in_Tonic wrote:Hmmm...would the current code allow us to randomize a second target to take minor damage? That would have a similar effect in the short term, at least.

No. The function gets passed a BattleTarget that contains the list of targets that should be affected. We'd still need to add a new target type that distinguishes between "primary target" and "secondary target". We'd also need to consider the UI implications for this as well. The target types are shown as icons along side each skill to indicate who it targets (ally or enemy) and how many (single or all). We could make the "all" icon be more generalized to mean "multiple" (which may or may not be all). And if the target selects a group instead of the whole party, we'd need to indicate in the UI which actors in the group would be affected. The UI part is as much of a problem we'd have to solve as the code that executes the action itself.

On another note, I'm not sure how I feel about "positioning" type abilities. That is, abilities which affect targets differently depending on where they are positioned on the battlefield. I know many games do this, but those games usually make the position of characters and enemies dynamic (that is, their position on the screen changes during battle, whether a move was manually requested by the user or its randomly generated movement). In Allacrost, the position of actors on the battlefield is fixed, which makes positioning type abilities much less interesting since you can't change your tactics as you notice that enemies are grouped together in a line, or use an ability that groups enemies more closely together. We'd have to develop some algorithms to make the same encounter (ie 3 slimes and 2 skeletons) have different positions for each battle to make this at least moderately more interesting.

Roots wrote:On another note, I'm not sure how I feel about "positioning" type abilities. That is, abilities which affect targets differently depending on where they are positioned on the battlefield. I know many games do this, but those games usually make the position of characters and enemies dynamic (that is, their position on the screen changes during battle, whether a move was manually requested by the user or its randomly generated movement). In Allacrost, the position of actors on the battlefield is fixed, which makes positioning type abilities much less interesting since you can't change your tactics as you notice that enemies are grouped together in a line, or use an ability that groups enemies more closely together. We'd have to develop some algorithms to make the same encounter (ie 3 slimes and 2 skeletons) have different positions for each battle to make this at least moderately more interesting.

Seems reasonable. I was aiming merely for something between "hits one guy" and "hits everyone," but you have a point that it's not as interesting as it could be.

I think we could maybe add a skill type that has a primary target and secondary targets. For example, a skill that deals a lot of damage to an enemy, and deals minor damage to all other enemies. Or a skill that attacks one enemy and heals each character for a percentage of the damage dealt. I think that's something that could definitely fit within our radar. It would still take some work to implement something like that, but might be reasonable to expect support for that by the end of this year, provided we have enough active developers to support it (which right now, we don't).

Roots wrote:I think we could maybe add a skill type that has a primary target and secondary targets. For example, a skill that deals a lot of damage to an enemy, and deals minor damage to all other enemies. Or a skill that attacks one enemy and heals each character for a percentage of the damage dealt. I think that's something that could definitely fit within our radar. It would still take some work to implement something like that, but might be reasonable to expect support for that by the end of this year, provided we have enough active developers to support it (which right now, we don't).

I'll sideline that sort of design for the moment then.

Should have some planning numbers by Monday of these ideas: busy weekend, or I'd have them sooner.

Alright...basic ideas, with a bit more math behind them. Note that we currently only have 4 moves coded in though so, unless we want to put in more moves per character or DIFFERENT basic moves per character, we'll have to cut some of these.

Slash: Basic attack, as coded in. Given across all three characters. Recovers 1-2 SP with use, perhaps? Gives it a reason to possibly be used. Alternatively, make Guarded Strike, below, into the default attack?

Precision Strike: Higher accuracy basic attack, with a 25-40% chance to spike for either bonus damage (probably in the realm of +50%), or a "vulnerable" status that increases damage from the next source that hits the target. 2 SP.

Finishing Blow: Deals basic attack damage against a target at full health, up to basic attack damage * 3.5 against a target with 0 health. Effectively a double-strength attack against a target with ~40% health, and growing in strength from then on. 3-4 SP. Possibly consider immediately cooling down if it kills something? Might add some fun strategy to its use.

Guarded Strike: Deals moderate damage (basic attack * 1.5, possibly), and returns 25% of damage dealt as health. I'd *prefer* to do returns (and possibly in-combat healing) as Shields instead, so you don't grind down your Fatigue so quickly over long battles [and maybe up the percentage of Fatigue lost to damage, to encourage more strategic defensive play), but we don't have support for that right now.

Clarion Call / Rallying Cry: Refreshes other characters, if this code is currently possible. Might not be. 4 SP cost, and quite a long cooldown. Given only to the Guard Captain.

Thoughts on the specific implementations? Numbers are placeholders, since until I test them it'll be hard to get down exact values.

I love everything you suggested. I'm totally fine with throwing out our current set of skills (there was no design thought at all put into them and they were mostly just to demonstrate certain features). I'm also alright if we want some of the characters to have unique moves. Just keep in mind that both Mark and Lukar are playable in only the early portion of the game, then are never part of the party again (think Biggs and Wedge from the opening to FFVI). As a player, I'd be frustrated if Lukar had a super cool ability but I never got to see or use it again in the game. Should be alright though as long as we have those skills used by other characters.

Other thoughts:1) I really like the idea of making an enemy vulnerable. However, we have no way to convey that an enemy is in a vulnerable state unless it's a status effect. We also do not have a way currently to say "this condition is active until the following action occurs". The best we could do to implement something like this right now is to cause the skill to afflict the enemy with a timed status effect that lowers the enemy's physical defense. But both the duration time and the amount that defense is decreased would be fixed into the status effect.

Is using a status effect sufficient for our designs? Or do you feel we need something that can take effect for a number of turns, or a number of actions (ie, vulnerable for the next 2 attacks as opposed to vulnerable for the next 20 seconds)?

2) I'm not sure what you meant by everything regarding guarded strike. What are "shields"? Why do they reduce fatigue accumulation? Why don't we have support for them right now? (We can do simple defensive bonuses via status effects at the moment)

3) Not sure what you mean by "refreshes" other characters (healing? remove status effects?). I'm pretty sure we could support this right now. While it is presumed that all actions that take a target type of "party", we could easily iterate through each actor in the character party when implementing this skill, and not apply the effect to the character that is the same as the one executing the action. So, 99% sure we can do whatever this is.

4) I'm sensing a trend in your design proposals where the current target types are not enough (those are: "self", "single actor", "single actor - specific point", and "all actors in party". Specifically, you seem to want actions to apply to groups of actors, but not necessarily all of them. Do we want to change the "all actors in party" type to be a "multiple actors" type (which may or may not include all actors in party)? Feels like this would be a good step forward in terms of flexibility.

Roots wrote:Is using a status effect sufficient for our designs? Or do you feel we need something that can take effect for a number of turns, or a number of actions (ie, vulnerable for the next 2 attacks as opposed to vulnerable for the next 20 seconds)?

It's sufficient, but the "per attack" situation lets us predict the damage better than an "X seconds" situation. That alone might make us want to consider an "X actions" format as well.

2) I'm not sure what you meant by everything regarding guarded strike. What are "shields"? Why do they reduce fatigue accumulation? Why don't we have support for them right now? (We can do simple defensive bonuses via status effects at the moment)

Shields would, effectively, be health that doesn't count as health when lost, and therefore doesn't trigger extra fatigue.You won't accumulate extra fatigue as a result, which is the one downside of healing. I didn't think our current status effect situation could accommodate that but, if it can, we're golden.

3) Not sure what you mean by "refreshes" other characters (healing? remove status effects?). I'm pretty sure we could support this right now. While it is presumed that all actions that take a target type of "party", we could easily iterate through each actor in the character party when implementing this skill, and not apply the effect to the character that is the same as the one executing the action. So, 99% sure we can do whatever this is.

By "refreshes" I mean "allows to act immediately, regardless of their current cooldown state."

4) I'm sensing a trend in your design proposals where the current target types are not enough (those are: "self", "single actor", "single actor - specific point", and "all actors in party". Specifically, you seem to want actions to apply to groups of actors, but not necessarily all of them. Do we want to change the "all actors in party" type to be a "multiple actors" type (which may or may not include all actors in party)? Feels like this would be a good step forward in terms of flexibility.

Absolutely. I'd like to do the same with enemies as well: I think it opens up a LOT of room for flexibility.

I love the concept of shields, and I don't think that will be too difficult to implement. Although we'll need to figure out a way to display it in the battle UI.

Arkitech is still active. He mostly communicates on the project page and not so much on the forums. But yeah, we're down to a bare bones crew right now I'm afraid. This is just the way it is with a project like this. People get busy with their lives and have to step away, and they usually don't give anyone on the project a heads up about it. We probably need to do another recruitment run soon to rebuild our numbers.

Since we are temporarily on the topic of doing stuff, Roots I remember you mentioning that you needed some help with map scripting. If you have something in mind I could work on a ticket on that + more battle code stuff? Just send tickets my way.

There's something I feel we need to make a decision on with regard to these actions. We've been talking about thinking about the effect of actions in number of turns (ie, grant a shield that lasts for 2 turns). This is easy to understand, but keep in mind that our battle system is an active-time based one, not a turn-based one. Each actor takes a different amount of time to finish a "turn", based on their agility (determines length of the idle state) and the action that they execute (determines the length of the warn-up state). So if you say a character has a shield for two turns, this could have a very different effect based on the character, as one might take 14 seconds for an average turn while another takes 8 seconds, meaning that the shield has a more beneficial effect for slower characters. I'm not sure if this is a desired behavior.

Another thing to keep in mind is that status effects are truly time-based and not turn-based. They last a specific amount of time regardless of who the actor inflicts, which I think makes sense. It would be odd if poison lasted only 6 seconds for one actor and 12 seconds for another. If we mix both time-based effects and turn-based effects, I think we'd add an unnecessary amount of confusion and complexity to the battle system. Instead, I think we should choose one or the other and make all effects follow that system (except maybe in some really rare occasions). And I vote for time-based since A) we already have this working and all implemented effects are already time-based, and B) we've been designing this game for a time-based system for a very long time, and switching at this point seems like it would require a lot of work and not necessarily make the game significantly better. Thoughts on that?

If we do decide to stick with a time-based system, it's worth taking a fresh look to figure out our formula for determining the length of the idle state, since this more or less determines how long a "turn" is for an actor (not counting the warm-up time). I believe that right now what we do is we look at the agility rating for all actors at the start of the battle. We figure out who has the highest agility, and assign them a fixed idle time value (let's call it Tmin, and I think it's 10 seconds long right now? I'm not positive on that though). So at the start of every battle you'll always have at least one actor with an idle time of Tmin. The time of other actors depends on the ratio of their agility rating compared to the agility corresponding to Tmin. For example, let's say we have four actors in a battle with agility ratings of [40, 20, 30, 45]. The 20 agility actor would be assigned a value of Tmin. The time for the 40 agility actor would be double that (Tmin * 40/20). And so on.

Is this system alright for determining idle times in battle? Or do we want something else?

Roots wrote:There's something I feel we need to make a decision on with regard to these actions. We've been talking about thinking about the effect of actions in number of turns (ie, grant a shield that lasts for 2 turns). This is easy to understand, but keep in mind that our battle system is an active-time based one, not a turn-based one. Each actor takes a different amount of time to finish a "turn", based on their agility (determines length of the idle state) and the action that they execute (determines the length of the warn-up state). So if you say a character has a shield for two turns, this could have a very different effect based on the character, as one might take 14 seconds for an average turn while another takes 8 seconds, meaning that the shield has a more beneficial effect for slower characters. I'm not sure if this is a desired behavior.

I haven't been talking about "turns," actually. The shields I suggested would persist until destroyed: others might last a specific amount of time. The only other mechanic I was using was more of a counter system -- an effect that triggers the next two times you're attacked, for example.

If we do decide to stick with a time-based system, it's worth taking a fresh look to figure out our formula for determining the length of the idle state, since this more or less determines how long a "turn" is for an actor (not counting the warm-up time). I believe that right now what we do is we look at the agility rating for all actors at the start of the battle. We figure out who has the highest agility, and assign them a fixed idle time value (let's call it Tmin, and I think it's 10 seconds long right now? I'm not positive on that though). So at the start of every battle you'll always have at least one actor with an idle time of Tmin. The time of other actors depends on the ratio of their agility rating compared to the agility corresponding to Tmin. For example, let's say we have four actors in a battle with agility ratings of [40, 20, 30, 45]. The 20 agility actor would be assigned a value of Tmin. The time for the 40 agility actor would be double that (Tmin * 40/20). And so on.

This is a little odd, since it means the same actor acts at different rates in different fights. I'd much rather pick a default time for EVERYONE (or at least for different classes of enemy) and have Agility scores modify that, even if it means we need a bigger range for Agility -- I think having your character timing consistent is best, especially if abilities also have timed duration effects. Otherwise 8 seconds might not have the same effect in two different battles with different Tmin values.

Djinn_in_Tonic wrote:This is a little odd, since it means the same actor acts at different rates in different fights. I'd much rather pick a default time for EVERYONE (or at least for different classes of enemy) and have Agility scores modify that, even if it means we need a bigger range for Agility -- I think having your character timing consistent is best, especially if abilities also have timed duration effects. Otherwise 8 seconds might not have the same effect in two different battles with different Tmin values.

This is true, and I've been concerned about it as well. I think you are spot on that character timings need to be consistent because if characters are super fast (say 2 seconds of idle time) the player doesn't have enough time to input commands and the flow of the battle would feel interrupted. Now if enemies are that fast, it doesn't matter as much because their actions are auto-selected by the AI.

Maybe a new algorithm could work like this:- Take the average of all character's agility ratings and call it A'. A' always corresponds to a default idle time (let's say 8 seconds).- Now take the ratio of each character's agility to A'. This determines their idle time (ie, if character X has agility 8 and A' is 10, then their idle time would be 10/8 * 8s = 10s)- Do the same with all enemies. A very fast enemy with agility of 50 would act in 10/50 * 8s = 1.6s. A very slow enemy with agility of 2 would be 10/2 * 8 = 40s

Obviously we'll need to refine it some more, but this could be a step in the right direction. Maybe we have some hard limits in place so that the action time for an actor is never faster than 3 seconds and never slower than 20 seconds? I'm not sure. I'd much rather you figure something out for us here Djinn, since this is the kind of thing you are good at. Just remember that we're also going to have modifiers to action speed as well (that will max at +/- something like 40% speed).