Turn Range Limits on Effects
From main article,
- The variable “Galaxy.EventFrequency” is used by event spawning objects to account for user preference. It’s up to each object to use this variable (or not) when determining whether or not an event is fired.
- The variable “Galaxy.CurrentTurn” can be used by event spawning objects to modify the chance of an event occurring dependant upon the number of turn elapsed. For example, Space Monsters might not spawn prior to turn 30.
Pondering about how this would work...
Initially I thought we might need some additional conditions or somesuch to deal with stuff only happening after certain game turns. Then I thought we might be able to just use the Chance condition to turn things on after X game turns, assuming that the Chance condition can deal with changes outside the range [0, 1]. If it can, and anything > 1 is guaranteed to happen (chance condition matches everything), and anything less than 0 is guaranteed not to happen (ie. Chance condition matches nothing), then we could use a chance condition like so:
<Condition::Chance> <chance>Galaxy.CurrentTurn - START_TURN + 1</chance> </Condition::Chance>
This give a negative or zero chance until Galaxy.CurrentTurn = START_TURN, at and after which it would return a positive chance, which would presumably ensure the event only happens on or after START_TURN, if the condition is used as an activation condition for the appropriate effects group of the event spawning special.
However this is rather limiting... in that it's not so simple to make events turn on at START_TURN then off again at END_TURN. It could be done, by using an expression for chance that's parabolic in Galaxy.CurrentTurn, rather than linear as above, but this is rather complicated.
Alternatively, we could use two or more chance conditions in an effects group activation condition (under and And condition), both of which would need to be met in order for the effect to fire. We'd then use linear expressions for before and after certain turns as chance conditions as above, establishing a start and end turn for the effect. This would probably be a bit easier to understand than using a parabolic relation or other complicated math expression.
However, it might be better to have some sort of "NumericComparison" condition. This would allow numeric parameters to be compared with >, <, =, <=, >= and !=, which would provide easy-to write effects groups and powerful functionality.
Good point. When I wrote it, I hadn't considered exactly how gameturns would be tested. Though we could do just as well with a specific condition to test the current game turn.
Presumably we might also want to have "if-elseif-else" structures, but this is probably too complicated to bother coding into the engine, and can be accomplished using separate effects groups with appropriate conditions and well-thought-out event / special design.
It would be very useful to have some additional run-time and effect-interacting properties on objects, or at least specials.
The one I'm thinking of in particular is a Timer. This would be an integer number that counts down to, or up from (?) zero, one number per turn, and which could be used with numeric comparisons or chance conditions in order to turn things on and off or make things happen after a certain amount of time.
A Timer could be specially made for that purpose, or could be implemented as a sort of general-purpose register within an object / special for use in coordinating effects.
Objects / events / specials would interact with the register or timer just like they do for other variables: through an effect to set the value, and through expressions like Source.Timer or Target.Register to access the value.
I suspect tzlaine will have issues with anything this complicated, but I do think there is a use for it, as various suggestions have been made for effects or events that require some sort of timer / turn counter to function properly. Whether from this it's a big additional objection by tzlaine to making a general-purpose register, I'm not sure... If it was limited to a timer, then the only effect needed would be something like "ResetSpecialTimer", and there'd be no need to have an effec to actually do the incrementing of the timer. If we did have a general-purpose register available, we'd definitely need to make it quite clear that this is for very limited use, and most conditions should be based on the state of the Galaxy, not anything that would get us into complicated an impossible to understand or debug circular dependencies and such...