The principle of having a role that functions differently depending similar factors that regular roles are able to get:
- How many players are in the game? (
activation.value, ratio and each)
- Was this attribute (or group of attributes activated? (
activation.value)
- How many thresholds were achieved from the player count? (
thresholds)
- Is this attribute unique? (
unique)
Searching each role for the attribute may conflict with roles that already have it... if they have it for a different purpose (and possibly from another builder / structure).
- Can attributes be grouped together or have variants selected? (
selection.*)
This one follows the same principle as selecting one from an array group (roles should have the possibility to share these attributes regardless of what is chosen, but there is also a likely possibility to include specific clauses that require or exclude certain roles - in turn, the performance will get worse with each adaptation).
The possibility of accepting any variability on the attribute assignment (range.minimum, range.maximum, activation.chance, etc.) increases the likelihood of failure while attempting to add the role. The chance of it failing after each enhancement, increases not only with my poor code, but also incorrect assignment if the role builders weren't configured correctly or if the assembler doesn't take the new values into consideration. If it is achieved, it would probably be a v2 deployment.
Related to the attribute handling for #6 and #7
The principle of having a role that functions differently depending similar factors that regular roles are able to get:
activation.value,ratioandeach)activation.value)thresholds)unique)selection.*)The possibility of accepting any variability on the attribute assignment (
range.minimum,range.maximum,activation.chance, etc.) increases the likelihood of failure while attempting to add the role. The chance of it failing after each enhancement, increases not only with my poor code, but also incorrect assignment if the role builders weren't configured correctly or if the assembler doesn't take the new values into consideration. If it is achieved, it would probably be a v2 deployment.Related to the attribute handling for #6 and #7