Basic idea/big picture
There should be an API to consistently do checks for things that can fail. A Check is something an entity attempts. It has a certain threshold that needs to be overcome with a random result. The higher the threshold, the harder it is to succeed the check.
There can be bonuses or penalties to a check increasing or lowering the threshold.
An example is the detection of an enemy element. One element has vision at the location of another element. To actually detect that element, a Check is done. It takes different factors into account:
From the viewing element
The Vision (its SignalStrength) at the target's location
Height advantage: It is easier to see something from top down
Stationary or moving
From the detected element
The terrain
If it is moving, stationary or dug in ("hiding")
the size
Now all those parameters are mixed into a Check and it is asked if it succeeds. That is done by rolling a Random number.
Details
Currently we simply use propbabilities ranging from 0.0 to 1.0 and see if Random.nextDouble(0.0, 1.0) is larger for random events. That is ok for simple checks. But as stated in the big picture there can be lots of factors impacting how well a check goes. There are bonuses and penalties and I find it hard to express those in "adding/subracting to a probability". In the example above the seeing element might have 0.5 vision. This means a 50% chance to see the enemy. But then it is in a forest, so you subtract 0.1 from it. resulting in 40% chance. It is also dug in, so another 0.08 down, but the height advantage adds another 0.05 and so on...
What happens when the result is outside of 0.0 to 1.0? This feels strange, uncomfortable und hard to model. Pen and paper role play games have lots of different systems to do checks and they might be insiring. For example in dungeons and dragons a check is done by throwing a 20 sided die and adding a bonus. The threshold to overcome is the DC. In our example the base DC to detect an enemy might be 10. Hiding adds 2, forest adds 2. The throw has a bonus of +3 for height and good vision. Something like that.
The Check-API should be simple and use whatever system under the hood so we can easily fine tune or change it. But using dice seems to open the possibility to easily tune the distributions.
I am not sure if we need fine grained bonus values (+1, +2, +3, +whatever). It is probably enough to have something like CheckBonus.small/medium/large and stack those onto a check to make it harder or easier.
Technical background
The functionality described in this issue should reside in an own util module. It offers an extensible class Check that gets bonuses and penalties and a Random. At creation time it rolls its value and the simply has a succeeds field that is either true or false.
This API is then used throughout the project whenever something random happens. In the appropriate locations we define extensions of Check and/or corresponding extension functions for stuff like VisionCheck, HitCheck, DamageCheck (oh, maybe we also need different checks not resulting in simple booleans... but lets start simple ;) ) which might be instantiated with Random.visionCheck(...parameters...).
I would go for implementing a dice system. Either using a d20 for all checks or using growing dice for easier checks.
Basic idea/big picture There should be an API to consistently do checks for things that can fail. A
Checkis something an entity attempts. It has a certain threshold that needs to be overcome with a random result. The higher the threshold, the harder it is to succeed the check.There can be bonuses or penalties to a check increasing or lowering the threshold.
An example is the detection of an enemy element. One element has vision at the location of another element. To actually detect that element, a
Checkis done. It takes different factors into account:Vision(itsSignalStrength) at the target's locationNow all those parameters are mixed into a
Checkand it is asked if itsucceeds. That is done by rolling aRandomnumber.Details Currently we simply use propbabilities ranging from 0.0 to 1.0 and see if
Random.nextDouble(0.0, 1.0)is larger for random events. That is ok for simple checks. But as stated in the big picture there can be lots of factors impacting how well a check goes. There are bonuses and penalties and I find it hard to express those in "adding/subracting to a probability". In the example above the seeing element might have 0.5 vision. This means a 50% chance to see the enemy. But then it is in a forest, so you subtract 0.1 from it. resulting in 40% chance. It is also dug in, so another 0.08 down, but the height advantage adds another 0.05 and so on... What happens when the result is outside of 0.0 to 1.0? This feels strange, uncomfortable und hard to model. Pen and paper role play games have lots of different systems to do checks and they might be insiring. For example in dungeons and dragons a check is done by throwing a 20 sided die and adding a bonus. The threshold to overcome is the DC. In our example the base DC to detect an enemy might be 10. Hiding adds 2, forest adds 2. The throw has a bonus of +3 for height and good vision. Something like that.The
Check-API should be simple and use whatever system under the hood so we can easily fine tune or change it. But using dice seems to open the possibility to easily tune the distributions.I am not sure if we need fine grained bonus values (+1, +2, +3, +whatever). It is probably enough to have something like
CheckBonus.small/medium/largeand stack those onto a check to make it harder or easier.Technical background The functionality described in this issue should reside in an own
utilmodule. It offers an extensible classCheckthat gets bonuses and penalties and aRandom. At creation time it rolls its value and the simply has asucceedsfield that is either true or false. This API is then used throughout the project whenever something random happens. In the appropriate locations we define extensions ofCheckand/or corresponding extension functions for stuff likeVisionCheck,HitCheck,DamageCheck(oh, maybe we also need different checks not resulting in simple booleans... but lets start simple ;) ) which might be instantiated withRandom.visionCheck(...parameters...).I would go for implementing a dice system. Either using a d20 for all checks or using growing dice for easier checks.