probably we should start by a watered down UI design principle;
i have two main designs: a) temporary changes; or b) normal/stacking changes
in general this is only about meter changes currently (i think)
a)
with temporary changes the phase effect application would only happen in that phase. and outside of the phase that change would not exist, so the current effect application would be basically unchanged, resetting meter values after a phase to the initial meter (or simply not backpropagating the changes).
The UI should probably indicate if there are temporary effects applied or not (and if possible also have a mouseover with effects accounting). E.g. by using a different color (not sure about accessibility).
The values presented for weapons would be the current values with the temporary before-combat effects applied.
So if one did not have any, the damage/shots... are shown in white; as soon as flanking kicks in, the value shown would be with the flanking bonus and e.g. in green color.
(This works well if there are not many sources of temporary effects).
About in-flight effects; this is obviously harder/impossible for the UI. E.g. when passing two systems in one jump; one could have a certain stealth on the first lane, a certain stealth in the first system (e.g. there is a scanning facility) which is relevant for blockade, another stealth on the next lane, another stealth on the second system, another stealth on the last starlane.
This would mean reevaluation of those in-flight effects every time a starlane is entered or a system is entered. We could of course also dumb down movement by dissallowing any passage - but i doubt anyone wants that.
b) normal/stacking effects
this has the advantage that a simple UI flow is backed by a similar process in the backend. E.g. if stealth changes in pre-movement phase because of fleet stance, it would the true value for movement/blockade/combat and won't be necessary to change.
with the temporary effects one would have to make sure to apply the effect on all those phases again. e.g. the fleet stance effect would be necessary to apply e.g. before-movement, before-combat...
the problem with such is when the effect should be temporary - one has to undo it; and sometimes it might be hard by how much .
With the extreme example of in-flight effects one in order to undo previous effect, one would have to figure out the bonus which was provided by the last flight segment and substract it
so i would rather go for temporary effects, because undoing effects is a lot more messy than reapplying. and if I consider phases a low-level feature, it is ok that it is ugly having to list multiple activation conditions.
- (usually and in most cases) UI shows the correct numbers which will be used in turn processing (e.g. movement, blockade, combat, effect processing...)
- for specific cases, expected values are shown and care should be taken to emphasize that the used values might be different depending on unknowns; currently this is mostly happening to movement orders, because blockade depends on enemy orders (e.g. enemy sends blockaders home) and also hidden information (e.g. an fleet blockades a out-of-detection planet)
- it is ok if unknowns like enemy orders (or hidden enemy ships) make those values deviate from those used
- this is considered a "low-level feature" and the burden is on the effect implementer to get this right (and we should document this caveat implementor). One should always figure out how to communicate the effect to the players.
i have two main designs: a) temporary changes; or b) normal/stacking changes
in general this is only about meter changes currently (i think)
a)
with temporary changes the phase effect application would only happen in that phase. and outside of the phase that change would not exist, so the current effect application would be basically unchanged, resetting meter values after a phase to the initial meter (or simply not backpropagating the changes).
The UI should probably indicate if there are temporary effects applied or not (and if possible also have a mouseover with effects accounting). E.g. by using a different color (not sure about accessibility).
The values presented for weapons would be the current values with the temporary before-combat effects applied.
So if one did not have any, the damage/shots... are shown in white; as soon as flanking kicks in, the value shown would be with the flanking bonus and e.g. in green color.
(This works well if there are not many sources of temporary effects).
About in-flight effects; this is obviously harder/impossible for the UI. E.g. when passing two systems in one jump; one could have a certain stealth on the first lane, a certain stealth in the first system (e.g. there is a scanning facility) which is relevant for blockade, another stealth on the next lane, another stealth on the second system, another stealth on the last starlane.
This would mean reevaluation of those in-flight effects every time a starlane is entered or a system is entered. We could of course also dumb down movement by dissallowing any passage - but i doubt anyone wants that.
b) normal/stacking effects
this has the advantage that a simple UI flow is backed by a similar process in the backend. E.g. if stealth changes in pre-movement phase because of fleet stance, it would the true value for movement/blockade/combat and won't be necessary to change.
with the temporary effects one would have to make sure to apply the effect on all those phases again. e.g. the fleet stance effect would be necessary to apply e.g. before-movement, before-combat...
the problem with such is when the effect should be temporary - one has to undo it; and sometimes it might be hard by how much .
With the extreme example of in-flight effects one in order to undo previous effect, one would have to figure out the bonus which was provided by the last flight segment and substract it
so i would rather go for temporary effects, because undoing effects is a lot more messy than reapplying. and if I consider phases a low-level feature, it is ok that it is ugly having to list multiple activation conditions.
Statistics: Posted by Ophiuchus — Fri Jun 21, 2024 8:16 am