Swayed Random Number Implementation

Last post I discussed how a swayed random number system works and showed some examples. Now you want to implement it but are worried about the specific advantages pitfalls coming your way. I hear your pain and will try to cover both sides then end with a quick code implementation for your convenience.

Swayed Uses

If we are thinking about blatantly obvious random systems in games, no greater irritant comes to mind then hit / miss chances. Survival is taken out of the player's control if they get an unlucky string of misses on an otherwise high hit chance, especially if it is a slow attack rate. With a swayed system, the chance of missing repeatedly becomes far less probable.

The same advantage can be provided with the second most common blatant random system. Drop rates or the distribution of items on monsters can be modified to not only avoid the irritating streak of monsters who just won't drop what you need, but also to allow greater accuracy to the GoalChance. This allows designers to be more sure of the time or effort players will be spending on the task.

Finally, consider the advantage casino games would gain from the more accurate success rate. Even a minor SwayPotency would tighten the actual handouts from systems to more accurately represent the GoalChance. This would lower the overhead a casino would need to keep in cash to prepare for unexpected turns in payouts.

Maximizing The SwayVar's Value

Since SwayVar is designed to even out the experience in a particular period of play it doesn't need to be saved. If the player quits, goes to a new level, or perhaps just switches tasks the variable can be dumped. The worst thing you do by throwing out SwayVar is return the system to its GoalChance. You can have different SwayVar's for each system you want to control but since it is basically just a number between 0 and 1 you can have multiple systems use the same variable. This is where we run into our first problems.

If you combine a slow system with a quick system all advantage for the slow system will be lost. If I decide to use the same SwayVar for hit chance and the drop rate for the quest I am doing, I will probably be using SwayVar for about 20 hit checks between each drop check. This means although the overall system will be balanced, players will not see the effect on the drop rate as the system is fully cycled between each check.

If you combine a high GoalChance system with a low GoalChance system the problems get even worse. Now I am alternating between two drop rates, one that has an 80% chance to drop and one that has a 5% chance. An early miss on the 80% can allow me to get a much faster drop on the 5% when the SwayVar is low. You could always decide to make SwayVar a percentage of the GoalChance but this would reverse the effect. An early success on the 5% would make it take forever to get the first easy 80%.

So remember, SwayVar can be shared amongst any number of systems as long as they have a similar check rate and a similar GoalChance. You can also use the same variable if the systems are in different periods of play but at that point it may just be easier to throw out the old SwayVar and get a new one.

Code

Declare TempGoalChance
Declare RandomNumber

Get GoalChance
Get SwayVar
Get SwayPotency

If ( SwayVar > 1 )
–– TempGoalChance = 0
Else
–– TempGoalChance = GoalChance
End

If ( Random(0 to 1) < TempGoalChance / SwayVar)
–– SuccessVar = 1
–– Other Success Things
Else
–– SuccessVar = 0
–– Other Failure Things
End

SwayVar = SwayVar – ( GoalChance – SuccessVar ) * SwayPotency