Framework Sneak Peek

Discuss the sequel to Planet Stronghold here
Post Reply
User avatar
Anima_
Druid
Posts: 343
Joined: Fri Mar 02, 2012 2:44 pm
Location: Germany
Contact:

Re: Framework Sneak Peek

Post by Anima_ » Tue Jul 30, 2013 5:39 pm

jack1974 wrote:I don't think, also many enemies won't really have "ammo", since are "creatures", some attack with melee, and so on. I am thinking that the ammo feature is more to balance the game, than to add realism.
Of course, ammunition is only used for enemies that use guns. Others don't have to care about that. (Technically they get attacks with 0 ammunition cost.)
RPG Programmer for Winterwolves, currently working on: Amber's Magic Shop
Part-time emotionless AI

Seloun
Young scout
Posts: 43
Joined: Sat Jan 19, 2013 9:37 pm

Re: Framework Sneak Peek

Post by Seloun » Wed Jul 31, 2013 6:24 am

Anima_ wrote:
Seloun wrote: That does beg the question, though - what happens if you run out ammo? Or will it only cover special ammo? Special ammo only seems safer, or perhaps an extra-long action to dig ammo out of your backpack instead of somewhere convenient? The main issue I would see regarding covering regular ammo is that the opportunity cost of bringing items becomes pretty high if regular ammo took item slots too (OTOH, in principle item usage should replace shooting and thus ammo, mitigating the impact somewhat, at least for items that aren't heavily specialized).
You pray that your team will finish the enemy quickly while taking cover or act as an obvious distraction and catch bullets? (No you can't use them even if you catch them.)
It was planned in the first place that at least one slot will be used for a magazine. Nothing has really changed in that regard.
This does result in an interesting design dilemma - since presumably you can always use an item slot on a magazine, you always have to consider the opportunity cost of the magazine you're giving up when deciding to bring an item, which means that the item you're bringing has to be worth at least the magazine you didn't bring. This is probably okay in terms of balancing weapon fire and item usage, since it's just a trade between longevity and flexibility (the options the item choice brings versus shooting for longer amount of time), and if the item ends up using up about the same amount of time as the magazine would have, everyone would still sort of 'run dry' at the same time.

That seems to imply though that most or all actions should be limited resources during at least the individual combat if they replicate things item slots can provide, unless they're very, very weak compared to the item choice (even then, magazine + unlimited option is probably more attractive than limited, stronger option unless the item option is extremely strong). If we take psionics as an example of player options that replicate item functions (shooting, healing, etc. - not sure what design space will be exclusive of item slots), it seems like it would make sense to make psionic resources non-regenerating (I think this is already planned?) and also to have an item slot trade-off (since this analysis suggests that item slots correlate pretty strongly to combat longevity otherwise). So item slots should probably be inversely correlated with psionic abilities (or anything else that provides an alternate longevity resources).

User avatar
Anima_
Druid
Posts: 343
Joined: Fri Mar 02, 2012 2:44 pm
Location: Germany
Contact:

Re: Framework Sneak Peek

Post by Anima_ » Wed Jul 31, 2013 1:44 pm

Psionic Points don't regenerate and psionics have few item slots and low equipment capacity.
Also the usefulness of magazines is inversely proportional to the number of magazines already equipped.
RPG Programmer for Winterwolves, currently working on: Amber's Magic Shop
Part-time emotionless AI

User avatar
jack1974
Pack leader
Posts: 13303
Joined: Thu Jun 16, 2005 4:43 pm

Re: Framework Sneak Peek

Post by jack1974 » Sat Aug 03, 2013 5:27 pm

I thought about two things today (finally had peace at home so I could do an amazing thing: THINK! :lol:):
1) about the ammo problem: it could be an incentive to swap the party members who fight. I am not sure yet how Anima wanted to handle this, but in the first game all your party members were available (unless for plot reasons) and you could select 4 out of 8 that would take part in the fight. So, if we allow the same thing, the ammo problem could be solved this way, each soldier carries an amount of ammo, so you would have an incentive to swap the soldiers between battles. Depending how the inventory is implemented though might be very simple to swap weapons/ammo between party members. Another idea was that if a party member is down in the battle, beside resurrecting him/her you could also choose to swap him/her with one of the other ones in "reserve". It might be also cool that in practice there was NO WAY to resurrect a KO player, except replacing him/her with the backup, and meanwhile he would get healed every turn. A bit like tag-team fights where the non-fighting characters slowly regain HP/PP
2) unavailable characters and max health damage: another idea, probably good only for the "iron mode" was that after every battle, each character would lose HP and PP based on how much hits they take and how much PP they use, to simulate injuries/fatigue. It would be another reason/incentive to rotate the party roster and not always use 4 characters through the whole game. Of course after each mission they would recover the full HP/PP.

those are just two random ideas that I thought to post to get feedback, but if they're horrible feel free to say it :)

Seloun
Young scout
Posts: 43
Joined: Sat Jan 19, 2013 9:37 pm

Re: Framework Sneak Peek

Post by Seloun » Sat Aug 03, 2013 8:36 pm

jack1974 wrote:I thought about two things today (finally had peace at home so I could do an amazing thing: THINK! :lol:):
1) about the ammo problem: it could be an incentive to swap the party members who fight. I am not sure yet how Anima wanted to handle this, but in the first game all your party members were available (unless for plot reasons) and you could select 4 out of 8 that would take part in the fight. So, if we allow the same thing, the ammo problem could be solved this way, each soldier carries an amount of ammo, so you would have an incentive to swap the soldiers between battles. Depending how the inventory is implemented though might be very simple to swap weapons/ammo between party members. Another idea was that if a party member is down in the battle, beside resurrecting him/her you could also choose to swap him/her with one of the other ones in "reserve". It might be also cool that in practice there was NO WAY to resurrect a KO player, except replacing him/her with the backup, and meanwhile he would get healed every turn. A bit like tag-team fights where the non-fighting characters slowly regain HP/PP
2) unavailable characters and max health damage: another idea, probably good only for the "iron mode" was that after every battle, each character would lose HP and PP based on how much hits they take and how much PP they use, to simulate injuries/fatigue. It would be another reason/incentive to rotate the party roster and not always use 4 characters through the whole game. Of course after each mission they would recover the full HP/PP.

those are just two random ideas that I thought to post to get feedback, but if they're horrible feel free to say it :)
I think balancing around ammo not regenerating after each battle would make it pretty challenging, since now you have to balance the entire mission as a whole for ammo consumption, and there will likely be a lot of variance in that (someone who's good enough to get by an early fight with little ammo probably doesn't need the ammo in the later fight as much as the person who has to use a lot of ammo to get through the first fight). Likewise for permanent (at least over the mission) resources; I don't know that you want to make it mandatory to rotate everyone each mission. Also, it'd feel like you had to save your 'A' team for the boss, and had to slog through the minions with a less than ideal setup.

I think a character swapping mechanic could be pretty good, though, and could indirectly address item space limitations if you could rotate back-up characters with specific roles without too much penalty (like the guy who specializes in fire against enemies vulnerable to fire). This would also help mitigate the penalty of not being spoiled (e.g. knowing beforehand you need the fire ammo), which is also pretty good. Also encourages specialization and the value of narrow application items and abilities, which I think is a good thing.

I don't think it's really necessary for the inactive players to regenerate though; if you had to manage the inactive players every fight, it's not really much different from having everyone active anyway. A simple but possibly sufficient solution might be to allow one swap; maybe a second if you have the initiative or zero if you're the one surprised (but if swapping was allowed at all, I'd make zero-swap situations pretty rare and/or telegraphed beforehand, as it would likely have significant impact on strategy). Alternatively for a more general approach, allow players to have less than 4 people groups; any empty slot would have an action with a moderately long usage time to 'call up' a reserve member; if an active character is disabled, or uses a retreat command, his slot becomes empty (and thus open to another 'call up'). Somewhat more complicated, and you'd still want to limit the usage somehow (e.g. once you retreat/disabled, you're done for the fight). The main downside to this approach is again whether or not this is sufficiently differentiated from having the whole party there.

Yet another possibility - you set up your 'lineup' beforehand, and each of the four positions is assigned to specific characters. For example, position A might be occupied by character 1 and 3, and while you can swap between the two, you can't have both at once (since both are assigned to position A); this provides a pretty flexible swapping mechanism but still differentiates it somewhat from just having everyone there. Other pre-formed groups could also work (e.g. everyone has a partner, and pairs get swapped in or out).

User avatar
Anima_
Druid
Posts: 343
Joined: Fri Mar 02, 2012 2:44 pm
Location: Germany
Contact:

Re: Framework Sneak Peek

Post by Anima_ » Mon Aug 26, 2013 5:09 pm

About Speed

The Speed attribute affects several things in battle.
  1. Tie breaker if several people act on the same time count. The faster character will act first.
  2. Changes the execution time of skills. At the moment Speed/10 is subtracted from the execution time. The minimum execution time for all actions is 80% base execution time though. Negative Speed consequently will increase the execution time.
  3. Speed is greatly reduced under Cover.
  4. Sets the starting time for the character to 200-Speed, capped at 0.
  5. Starting time sets the initial amount of Fortitude every character gets.
The calculation for the initial Fortitude value is a bit complicated. It can be broken down to the following three values:
  • Delta t: slowest character time - fastest character time
  • Delta character: character time - fastest character time
  • Delta team: own team slowest character time - enemy team fastest character time
The final calculation is:
Fortitude * (1.0 - (delta character*max(0, delta team)/delta t²)
Delta t is only there for normalisation. So the performance of each character is defined by her own speed and the performance of the whole team.
There are two noteworthy effects. The fastest character always has a full Fortitude pool regardless of the team performance. If the slowest character of Team A is faster then every character in Team B all members of Team A will have a full pool. Both are the results of a 0 in one part of the multiplication.
RPG Programmer for Winterwolves, currently working on: Amber's Magic Shop
Part-time emotionless AI

Seloun
Young scout
Posts: 43
Joined: Sat Jan 19, 2013 9:37 pm

Re: Framework Sneak Peek

Post by Seloun » Tue Aug 27, 2013 5:29 am

Comments on speed mechanics -

2) Doesn't that form make speed more and more useful as you have more of it? Instead, better linear would be to treat speed as an increase in actions per time, rather than a decrease in time per action (given the relatively conservative cap, the effect is not that pronounced, however):

execution time = (base execution time) / (1 + Speed/800)

if you want to maintain 80% at Speed 200. I'm also assuming (possibly incorrectly) that you meant Speed/10 percent is subtracted from the base execution time; if not, this becomes harder to evaluate without specifics, due to nonlinearities, except that speed will have a (more) weird ROI in that model (increasingly valuable until the cap, where it loses most of its value, and speed being less valuable per point for longer actions).

3) Seems like a lot rides on that statement - in particular, how the reduction is handled (percentage from zero, or subtraction of constant, or something else?) Also suspect that this would be better handled as not a raw speed reduction but something which impact some/all of the derived values of speed (e.g. model it as an increased time for actions rather than as a speed reduction) to avoid unintended weirdness; conceptually more accurate anyway (being in cover doesn't make you actually slower, though it may make your actions take longer to complete). In particular, it's not clear if a) you can start in cover and b) if so, if that really should affect your start time and/or starting fortitude.

4) Is there any reason not to use (fastest speed in play) rather than 200? Only thing I can think of is if there's something which doesn't count as the person in play (environmental effects?) but even in those cases it seems like a speed could be assigned to those.


Fortitude, etc:

Except for the bit about the cap at 200, the delta values seem simpler written in terms of Speed (unless there are non-speed factors which will affect Start Time not listed here and should affect starting Fortitude):

dt = highest speed - lowest speed
d(char) = highest speed - character speed
d(team) = highest enemy speed - slowest friendly speed

It seems slightly strange that if everyone on your team is faster than everyone on the enemy team, except your slowest is very slightly slower than their fastest, you get a very different set of results than if their fastest was very slightly slower than your slowest. E.g. Speed 100, 90, 70, 50 vs 51 looks very different from Speed 100, 90, 70, 50 vs 49. Nevertheless I can see arguments for that sort of behavior in the model (one slow guy hurts the whole team's performance).

A somewhat different model which seems to preserve the intent might be:

cutoff speed = speed of slowest person on either side who is still faster than the entirety of the enemy team
fortitude multiplier = min( (character speed - slowest speed)/(cutoff speed - slowest speed), 1.0 )

which results in everyone who's faster than the entire opposing team starting with full fortitude, and everyone else scaled accordingly.


Overall it does feel like Speed is going to be *extremely* strong; in quick battles it'll be valuable to end threats quickly due to having strong initiative effects due to the starting fortitude; in long battles the extra actions are likely going to be decisive. If there's really a team level impact on Speed, it seems like everyone is going to have to prioritize it.

User avatar
Anima_
Druid
Posts: 343
Joined: Fri Mar 02, 2012 2:44 pm
Location: Germany
Contact:

Re: Framework Sneak Peek

Post by Anima_ » Tue Aug 27, 2013 7:39 am

Thanks for the critic, Seloun.
@2
The reduction is absolute. So with Speed 50 and an action with 100 execution time we get execution time 95.
I can see the argument for making the divisor a function of the base execution time ( something like Speed*base_execution_time/1000) Which results in 10% of speed if the action has execution time 100 and 5% of Speed if the execution time is 50.

At the moment I'd like to keep it simple and then adjust accordingly during the play test if speed becomes a problem. It certainly would smooth out the investment.

@3
The speed reduction only involves the execution time checks at the moment. The reduction is a normal segment, so it can be character specific, though you could treat it like a constant with additional modifiers based on character. Definitely should have mentioned that.
So it doesn't affect anything else at the moment.

@4
The difference is of course that using 200 caps the speed advantage naturally. It also makes the starting times more predictable for the interaction with timed events. I'm not totally opposed to the dynamic window version though.

@ Fortitude
The difference is actually rather minimal, at most you loose a single point thanks to cut off from int conversion. (The value on the left is the start time. The first four are Team A, the rest Team B.):

Code: Select all

50	1
75	0.9988888889
100	0.9977777778
125	0.9966666667
200	0
200	0
200	0
124	0.5066666667
If the last character has starting time 125 we have the first four at 1 and the last character at 0.5.

The reason I used time was that it saved me the more expensive attribute calls since it was already calculated.
RPG Programmer for Winterwolves, currently working on: Amber's Magic Shop
Part-time emotionless AI

Seloun
Young scout
Posts: 43
Joined: Sat Jan 19, 2013 9:37 pm

Re: Framework Sneak Peek

Post by Seloun » Wed Aug 28, 2013 4:33 am

Absolute reduction is interesting, though tougher to analyze without knowing the expected action times and Speed values (though it seems implied 200 Speed should be the cap). The main issue is that it ends up benefitting fast actions a lot more, though conversely it means the cover penalties and any other abilities that impact Speed also hurt fast actions more. Probably workable if there are viable ways to reduce Speed (and since cover reduces Speed, that's already sort of in there) and if the abilities are balanced at some point besides Speed = 0 (probably simplest way is just to identify a target speed and apply the +/- from that point, e.g. (Speed - 50)/10, instead of specifying the skill delay at 0). It does introduce some odd breakpoints, but if Speed is fairly dynamic in battle (fair number of ways to adjust it up or down mid-fight) the breakpoints become more interesting than a downside. Also probably means to be careful to have a spectrum of delays in viable actions for each class/specialization.


Re: Fortitude calc -

I'd forgotten that d(team) isn't symmetric (i.e. d(team) for one team is not -d(team) of the other team), which is what confused me. That seems to emphasize the issue of the group speed thing, though - having a slow guy on your team ends up reducing the entire group's starting fortitude, which seems somewhat odd. I can see how that can be explained in fluff, and it introduces an interesting dynamic, but it does seem like it means Speed is going to be pretty important to everyone on your team (maybe can't really afford to bring a slow guy).

User avatar
Anima_
Druid
Posts: 343
Joined: Fri Mar 02, 2012 2:44 pm
Location: Germany
Contact:

Re: Framework Sneak Peek

Post by Anima_ » Thu Aug 29, 2013 9:26 am

The range I'm currently working with is 50 - 200, where 50 only goes to actions like reload or change position. Standard attacks won't go over 150 either. Speed should stay lower than 200, actually going over 100 should indicate a build focus. I'm also thinking about synchronizing the Speed percentage and the maximum reduction. So 10% of Speed would mean that the maximum reduction is 10 % of the base execution time.

The opening speed will only influence the first phase of combat. Remember that having higher speed comes with lower values in other attributes.
RPG Programmer for Winterwolves, currently working on: Amber's Magic Shop
Part-time emotionless AI

Post Reply