Framework Sneak Peek

[Seloun]

The problem with upping the damage reduction to 1.0 is that it favours guardians too much. Basically, heavy weapons (few shots with high damage) will work better than pistols (which get out lots of rounds of low damage) against targets with high damage reduction.

Setting the asymptotic damage reduction goal to 1.0 doesn't really imply much by itself as it is quite easy to design an item scaling that would still favor fast-firing weapons regardless of the goal (the only important point is the relative deltas between the weapons and the expected damage reduction; there's nothing that says weapons must be balanced against or near 0 damage reduction). The damage reduction goal doesn't imply that in general damage reductions would be equal to the damage done; it only speaks to the scaling. The absolute difference can be made arbitrarily large. The main point of the smaller scaling with the damage reduction goal change is that the value of damage reduction will vary at a closer rate to the value of damage.
What this is really addressing is the following: Should +1 to damage be equivalent in value to +1 in damage reduction?
Neither answer is inherently better, but they have different consequences. The original scaling implies that +1 damage is typically less than half as valuable as +1 in damage reduction asymptotically, since a 'heavy armor' target should roughly have half of the expected damage value (so the same increase in armor as damage implies twice as far in progression). Again, this is not necessarily a problem (you just make sure you account for it in your item development) but it's a way to start thinking about stat valuations.
Furthermore, a higher damage reduction target generally suggests a tighter grouping on the hit table multiplier as it stands now as otherwise crits become more and more overvalued (as armor increases relatively, crits become more and more important -> accuracy becomes more and more important); this is why the logic went from tighter scaling -> higher relative armor values -> reduced multipliers. One of the side effects of the reduced multipliers is also that crits are somewhat less crippling against lower than expected armor (more tolerant of low armor), which also may or may not be desirable.

[Lonestar51]

I would not agree with the assertion that crits are overvalued - as the base damage of the weapon plays a large part of it.

A sniper would get many crits, but the sniper weapon would have moderate damage and low rate of fire, thus it balances itself out.

----

Seloun, many of the things you write are technically correct, but maybe a bit too much seen from a PvP point of view: There may be ways to balance the different stats in ways other than nerfing the crits: There may be enemies with machine guns and others with overpowered sniper rifles (mayn crits if evasion is neglected and high base damage) and everything in between. For every enemy the ideal build would be different. Also some enemies would have high HP/low damage reduction and others reverse, which would favour different weapons.

This is not like PvP where the other players will flock to an "ideal" build and you need to follow the herd otherwise you cannot match them, here the developer (Jack) may add enemies of different kind which favour different builds, different classes etc.

[Anima_]

Actually keep in mind that the crit chance goes pretty fast against zero for negative deltas. Someone who has neither reduction nor evasion should die pretty fast. There will probably be a trade off between evasion and reduction in some way. Looking at the diagrams so far reduction is better against lower basedamage, while evasion is more powerful against higher basedamage.

Moving the table result to the reduction part still keeps the general function of the table (accuracy helps damage) while making it more clear how accuracy helps damage - accuracy is more beneficial if the target has more armor, while damage is better against softer targets. Applying the modifier to the damage part does this too, just in an indirect way. Moving it to reduction makes crits less painful for soft targets (I think you'd probably want this to narrow the gap between squishy and non-squishy somewhat, but whether or not this is desirable is out of scope from mechanics analysis). Mainly it separates the design/balance space of damage and accuracy a bit more (also probably works nicer with a continuous function should that be desirable).

So actually we have the opposite of this dynamic. The higher the reduction the higher the basedamage needs to be. I think this is more desirable at the moment.
An additional possibility would be to make the Thresholds and Multiplier variable instead of static. That would add interesting dimensions to armour choice for an example, if the different armour categories had different multipliers.

At the moment I won't change the table, but we will probably get back to it later in the development cycle. It's something that's pretty easily changed later on, so I want to concentrate more on the basics right now.
That's also the reason why I didn't answer that many points and posts in general, this is a pretty busy part in the process for me. I do read everything and take your suggestions into account, but I have to ask for your patience when it comes to answering it. Unfortunately I'm also not the fastest writer in English so these posts take often quite a bit of time.

[Seloun]

I'm not really advocating a particular scheme so much as trying to identify features of the mechanics.

Also, my position is not that crits are overvalued (period), but that crits become more and more valuable as reduction increases, if the base damage delta remains the same:

- 100 damage vs 50 reduction results in 50 damage on a regular (1.0x) hit; it does 100 damage on a critical hit (1.5x)
- 1000 damage vs 950 reduction results in 50 damage on a regular (1.0x) hit; it does 550 damage on a critical hit (1.5x)

In order to maintain symmetry in terms of the value of crit hits (which, again, may or may not be desirable; I am not suggesting one is better than the other), then, it is necessary for reductions to scale at some asymptotic ratio compared to damage (e.g. 2 damage per 1 reduction, so you end up with 1000 damage/500 reduction instead as the scaling in the latter part of the game). Again, this is not necessarily a bad thing. It is an observation that, should the reduction scale slower than damage, the value of reduction is likely to be higher per point than the value of damage since the balancing would occur at the expected value of reduction. Put another way, +10 reduction would represent further progress in the game than +10 damage would.

Please keep in mind that I am not saying that there is something wrong with the balance (this is an impossible statement given the amount of data available). However, what can be analyzed is the scaling, as we can be reasonably sure that values will change (typically go up) as the game progresses, and thus the mechanics will be used at different points of the curve. Again, I am not saying 'nerf crits!' as there is not enough data to reasonably suggest something like that (as noted, this is highly dependent on the actual environment - i.e. the choice of enemies and itemization and the actual scale values). What I'm saying is only what I've said, among which is that if reduction and damage scale evenly, crits become more valuable, and thus if crit valuation should stay the same (which is a design decision without an immediate, obvious answer) the reduction has to scale slower than the damage.

[Anima_]

That is true, but didn't I already say that we want to scale it only up to 0.5? Maybe I forgot to write it here. At that level the difference is only 100% of damage which is acceptable.
Interesting at that point would be that the same would happen with the reduction modifier.
- 100 damage vs 50 reduction Clean Hit: 100 - 1.0*50 = 50 damage, Critical Hit: 100-0.0*50 = 100 damage
- 1000 damage vs 950 reduction Clean Hit: 1000 - 1.0*950 = 50 damage, Critical Hit: 1000-0.0*950 = 1000 damage
So actually it would be even worse. Of course this numbers depend on the table used, but that goes both ways. (The 0.0 for critical hits comes from the experimental table, higher values gave disappointing results.)

To really solve the problem we would have to subtract reduction before we apply the multiplier. Then the relation between the hit level modifiers and the actual damage for each hit level would remain the same.
Might even be the better solution since getting crits is largely luck based. On the other hand having a recourse against high reduction enemies other than heavy weapons would be nice as well, even if the expected damage would still be much lower then for heavier weapons. Something to think over.

[Seloun]

That is true, but didn't I already say that we want to scale it only up to 0.5? Maybe I forgot to write it here. At that level the difference is only 100% of damage which is acceptable.

You did mention that - the computation was to explain why high reduction values tend to favor crit (again, this is not necessarily a bad thing, it's just a description of what happens).

With respect to how this interacts with the 0.5 being the desired top end ratio of reduction to damage:

Given the ratio of damage to reduction going only up to 0.5 means the same amount of reduction is 'further along' the game than for damage.

Assuming the 0.5 reduction to damage ratio, and that early in the game you are at 200 damage and 50 reduction:
- By the time you level/get gear/etc. enough to be at 400 damage (+200 damage) you would expect to be around maybe 150 reduction (+100 reduction). It would not be much more than that or you would be violating the your expected ratio.
- By the time you level/get gear/etc. enough to be at 250 reduction (+200 reduction) you would expect to be around maybe 600 damage (+400 damage). It would not be much less than that or you would be violating the expected ratio.
This is what I mean by the scaling. While these are example numbers, the issue is with the approximate rate of increases (~2 damage to 1 reduction) rather than the specific values. So gear with say +10 reduction is likely worth a lot more than gear with +10 damage.
That in of itself is not necessarily a problem, but it is a characteristic of the mechanics that we can derive independently without knowing more about the gameworld (which is why I bring it up; most other analysis requires more data, which is not available yet).

Interesting at that point would be that the same would happen with the reduction modifier.
- 100 damage vs 50 reduction Clean Hit: 100 - 1.0*50 = 50 damage, Critical Hit: 100-0.0*50 = 100 damage
- 1000 damage vs 950 reduction Clean Hit: 1000 - 1.0*950 = 50 damage, Critical Hit: 1000-0.0*950 = 1000 damage
So actually it would be even worse. Of course this numbers depend on the table used, but that goes both ways. (The 0.0 for critical hits comes from the experimental table, higher values gave disappointing results.)

You're correct here. The 'apply to reduction' is really an alternative to the 'apply to damage', and not really intended to be used with the 1.0 scaling as well (they are two different suggestions, to be applied separately). The computation I would show is using the (1.0,1.1,1.15,1.2) multipliers:
- 100 damage vs 50 reduction Clean Hit: 110 - 50 = 60 damage, Critical Hit: 120 - 50 = 70 damage
- 1000 damage vs 950 reduction Clean Hit: 1100 - 950 = 150 damage, Critical Hit: 1200 - 950 = 250 damage

70/60 ~= 116%, 250/150 ~= 167%, vs the original 200% and 1100%

What I meant before was that the smaller multiplier ranges would let +10 damage be closer in value to +10 reduction than the larger multipliers (whether this is good or bad is not a decision I am making).

To really solve the problem we would have to subtract reduction before we apply the multiplier. Then the relation between the hit level modifiers and the actual damage for each hit level would remain the same.

This does 'fix' this issue (problem is a strong term). The downside, though, is that's it's somewhat boring (not a coincidence; interesting almost always means more easily breakable).

Might even be the better solution since getting crits is largely luck based. On the other hand having a recourse against high reduction enemies other than heavy weapons would be nice as well, even if the expected damage would still be much lower then for heavier weapons. Something to think over.

Well, to be honest I would much rather prefer a completely or minimally luck-based results in games like these due to the save/load issue. One kind of mechanic could be:
- Shooting someone always hits (damage is still damage - reduction, with a small random range)
- Delta accuracy 'builds' on the target (maybe with a _small_ random range)
- If the total delta accuracy is over a threshold, it is a critical hit, and delta accuracy is cleared

For example, character A and B are shooting enemy C (assume a +/- 20% randomness to accuracy buildup):
- Char A shoots enemy C, hits normally (automatic) and builds up 11 (10 +/- 2) points of accuracy on the target
- Char B shoots enemy C, hits normally (automatic) and builds up 33 (35 +/- 7) more points of accuracy (44 total)
- on enemy C's turn, enemy C drops 4 (5 +/- 1) points through evasion (40 total)
- Char A shoots enemy C, hits normally (automatic) and builds up 12 (10 +/- 2) points of delta accuracy on the target (total 52), which is over the (example) crit threshold of 50, and thus also gets a crit. Built up accuracy on Char C goes to 0.

Obviously it doesn't have to be exactly like this, but a mechanic like that mostly removes the randomness from the battle, and makes targeting much more an interesting issue (you might not want to 'waste' a high accuracy built with a weaker critical attack, so you might have a good reason to spread around attacks). This could thematically also be represented like cover (shooting someone 'flushes' them from cover, which is what 'accuracy build up' could represent; the name could certainly be altered).

- A glancing hit might be what you get if your attack would drop the built-up accuracy to below 0.

- This could also let the player react with active defenses, since they can see how much of a danger they are in (if a character is sitting near threshold of accuracy built, it might be a good idea to take a defensive action).

- Crits being really big is less of an issue since you can control it much better. Even the tank might need a 'breather' if they get close to their threshold, since normal attacks do little to them while crits are still dangerous (this also means having a second tanky character is a lot more useful than in the first game).

[Anima_]

Attributes
In the context of the new framework an attribute is anything we use in the internal calculation. Some of the statistics shown to the player will not be attributes in that sense.
That makes only sense if we take a look at how attributes handled internally. Instead of a simple number every attribute is a list of attribute segments. These segments hold the actual attribute values and the final attribute value is the sum of all triggered segments.
Apart from the value every segment also holds a set of internal and external keywords each and a beginning and end time. These are the conditions for the segment to trigger.
That way we can have for example an ability that increases accuracy only when the character is in the open and the target in cover. This way we also realize damage resistances. A fire resistance would simply be a reduction segment with the external "Fire" keyword.

At the moment the following attributes are definitely in the game: HP, PP, Accuracy, Evasion, Damage, Reduction. In the end this may actually double, there is still a few mechanics in the air and some things that are static at the moment might become variable enough to need attributes.

Time keeping
Like Loren we will have a delay based system again. This time with a major twist, the delay is not between action execution and the next time you get to choose an action. Instead it's between choosing your action and that actions execution.

Code: Select all

Choose ----------->Execute Choose ---------> Execute

The main difference is that this system allows the interruption of actions and planing as well. Even in the limited prototype it was already pretty fun to take cover to escape a sniper action.
In addition we keep the total time, so effects will have an absolute duration. This is unlike Loren were effect length was measured in character turns.

Might have been a bit brief but I think those are the important bits about those two aspects so far.

[Seloun]

Apart from the value every segment also holds a set of internal and external keywords each and a beginning and end time. These are the conditions for the segment to trigger.
That way we can have for example an ability that increases accuracy only when the character is in the open and the target in cover. This way we also realize damage resistances. A fire resistance would simply be a reduction segment with the external "Fire" keyword.

Interesting. I assume this is more effort to make the framework easily extensible.

It's not quite clear though how you would generally apply this - for example, how do you know that 'Fire' means the target is on fire, and not the shooter is on fire? It's interesting you chose an example with a mixed condition check. You could certainly have the logic reside in the ability check itself, but that seems to mostly defeat the purpose of having the segments attached to the attribute (actually, since presumably the condition is not stored in the attribute, just the triggers, it's not clear how this is actually applicable). In the character is in the open/target is in cover example, it's not really easy to see how the segment concept helps here (what is the segment that's tied to target evasion or shooter accuracy that makes it work with the described ability?). It's easy to see how it would work if it's just based on target being in cover (segment off target's evasion) or an ability based on shooter being in the open (segment off shooter's accuracy) but not how to have something that checks both conditions are true.

A secondary, minor issue is that if you are actually using string literals in the implementation, it's notoriously easy to introduce an unintended category of effects (e.g. 'Fire' and 'fire') as a virtually silent bug. While there are some relatively simple workarounds (scanning data files against a known set of keywords, for example; basically a simple compiler) it sort of emphasizes that this is effectively trying to describe a metaprogramming language.

I suppose another possible minor issue is the efficiency, though with sorted lists it seems like you could keep the execution time to O(n) (though the sorting itself would impose costs).

Also, how do you keep track of what thing a segment came from? E.g. how do you know that 'Fire' segment is the one from your chestpiece and not from a buff (time check could resolve potentially resolve this) or a passive ability? There are a number of possible solutions (including the 'doesn't matter' one) but it seems like a potential area of fragility.

The main difference is that this system allows the interruption of actions and planing as well. Even in the limited prototype it was already pretty fun to take cover to escape a sniper action.
In addition we keep the total time, so effects will have an absolute duration. This is unlike Loren were effect length was measured in character turns.

Time independent of character turns is good.

The delay system is interesting, but also somewhat scary. It seems like quicker actions are going to be much stronger than their amortized time cost would indicate. Taking a turn later also seems to be more of an advantage (to a point) since you have far more information. A delay action seems very strong (anything with a short time delay even if it does nothing) which means actions intended as 'interrupt' actions are probably going to be very strong.

First suggestion: Don't have any really long delay actions (or very, very few for specific reasons, e.g. killer boss ability). Instead, make them multi-part actions if possible (instead of a snipe with a long timer, have a 'ready snipe' action, 'select target' action and 'snipe' action; more generally you might allow a 'ready snipe' action that builds up a buff on the shooter that gets consumed on the 'snipe' action, or something similar). if actions are roughly the same delay, most of the problems go away.

Second suggestion: Have abilities that have a post-action delay, even if most abilities don't. The problem is that otherwise interruption-style actions become very strong, since they generally have to be fast in order to be useful. If fast is not the same as short time cost, you can have an action that can work as an interrupt without the time cost being short (e.g. a reflex shot that goes off in 2 time units, but also has a 4 time unit recovery time afterwards is easier to balance than a 2 time unit shot). Implementation wise this could be an extra 'nothing' action automatically taken after the interrupt action (so interrupt actions are actually a queue of 2 actions).

[Anima_]

Interesting. I assume this is more effort to make the framework easily extensible.

Yes that was the idea. One of my earlier framework already had this concept, but we decided that it wasn't necessary for Loren since it would be a much lighter RPG then Planet Stronghold. Well things changed during development a bit, most of you probably noticed.

I should have explained a bit more what I meant with internal and external keywords. In the example the ability would be bound to the accuracy attribute of the shooter. We then test if the internal keywords are a subset of the shooters state and if the external keywords are a subset of the targets state.
For the Fire keyword, this would be exclusive to attacks. It wouldn't even show up on a normal check for reasons that have to do with the double wielding implementation.

We are planning to use a GUI based editor for that. That problem was a never ending source of bugs for Loren, even with the lesser use of keywords.

For the comparison we use pythons set implementation. So far the speed is acceptable.

All segments have a reference to their source and of course all sources know their segments.

The delay system is interesting, but also somewhat scary. It seems like quicker actions are going to be much stronger than their amortized time cost would indicate. Taking a turn later also seems to be more of an advantage (to a point) since you have far more information. A delay action seems very strong (anything with a short time delay even if it does nothing) which means actions intended as 'interrupt' actions are probably going to be very strong.

Yes it's totally scary. I was kinda shocked when Jack gave the go for it. Apart from execution speed, there will also be a measure how difficult it is to interrupt an action. But yes interrupts have the potential to become very powerful. That's a fact we will definitely keep in mind, but trying to balance it in vacuum will not yield many results.

Regarding the advantage of going last. It's true that it does give a certain planning potential to the slower characters. On the other hand it forces them to react to the faster characters, so the faster characters has control over the flow of battle.

[jack1974]

The delay system is interesting, but also somewhat scary. It seems like quicker actions are going to be much stronger than their amortized time cost would indicate. Taking a turn later also seems to be more of an advantage (to a point) since you have far more information. A delay action seems very strong (anything with a short time delay even if it does nothing) which means actions intended as 'interrupt' actions are probably going to be very strong.

Yes it's totally scary. I was kinda shocked when Jack gave the go for it. Apart from execution speed, there will also be a measure how difficult it is to interrupt an action. But yes interrupts have the potential to become very powerful. That's a fact we will definitely keep in mind, but trying to balance it in vacuum will not yield many results.

I'm the scarecrow
Jokes apart I wanted to use this system so there could also be an auto-combat option for lazy players - or simply for battles that are almost won. I liked that feature in some games like Heroes Of Might & Magic, and I'm sure the more casual players would like it too. While the game is not real-time, the battles should be much more frantic than a classic turn-based game like Loren, I mean you will need to consider several values before making your move. More like a chess match. It's surely going to be harder to balance (at Hard mode in particular, easier modes shouldn't be a problem) but I think it has also the potential to be even more fun than Loren's combat which was already cool IMHO.