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

Swayed Random Number Generation

A swayed goal system is a method of producing random results that more closely follow what people believe is a truly random distribution. When people see a set of randomly produced numbers they are quick to point out streaks or patterns they perceive as sections where the random number generator has broken down. These perceived patterns in combination with with the fairly common knowledge that most number generators aren't truly random leads people to believe that the quality of the random data they are receiving is flawed.

In fact, although no system used in today's gaming market is truly random, people do not usually have the capacity to see the flaws in the numbers produced. When they see a perfectly normal streak of numbers in a randomly generated set, their first response is to feel cheated. (note I say cheated as players who get a good pattern feel lucky and have no complaints about the system) A swayed goal system actually reduces the random elements of the system and yet produces data that looks far more random to a player.

The Math

ModChance = GoalChance / SwayVar
SwayVar = SwayVar – ( GoalChance – SuccessVar ) * SwayPotency

ModChance – This is the modified success rate that is checked.
GoalChance – This is the target success rate.
SwayVar – This bends the chance of the next success away from how far off of statistical chance it has been previously.
SwayPotency – This is how much the swayed goal system will interfere with standard statical chance.
SuccessVar – This is a 1 if the attempt was a success and a 0 if it was a failure.

How It Works

When the system starts, SwayVar is always 1, as it has not been modified by previous success or failure yet. As you do more and more attempts and fail, SwayVar keeps decreasing by the GoalChance, increasing the chance of future successes. If you ever get a success, SwayVar increases by the SuccessVar (1). This resets the chance of success in the system. The end result of this is that with a 20% goal rate, it is basically impossible to not get a 20% success rate in a set of 5 attempts. No more streaks of 3 successes followed by 15 failures. SwayPotency modifies both the amount subtracted and the amount added for success by a set percentage, allowing you to decrease the potency and increase the randomness of the system.

One final note for implementation. This system will regularly give you SuccessVar values over 1. This can not only nullify some of the streak based benefits of the system but will also push your average rate of success slightly above the GoalChance. Simply temporarily reducing the GoalChance to 0 while the SuccessVar is over 1.

Results

I made a little demo program to show the advantages of this system. We will be examining final success rate over 100 attempts and the longest streak of failure. This is done with a SwayPotency of 1 and a GoalChance of 20%.

Regular Rate .20 - .19 - .21 - .13 - .19
Swayed Rate .20 - .20 - .20 - .20 - .20
Regular Streak 13 - 10 - 18 - 12 - 13
Swayed Streak 08 - 08 - 07 - 06 - 06

As you can see, not only does the Swayed Rate hit closer to our GoalChance, but the Swayed Streak is significantly lower. Now a sharp player may look at our swayed numbers and realize that they are too regular. Because of this we have included the SwayPotency. Lets see the same setup with a SwayPotency of 20%.

Regular Rate .20 - .19 - .12 - .15 - .17
Swayed Rate .19 - .20 - .19 - .20 - .19
Regular Streak 12 - 16 - 20 - 16 - 13
Swayed Streak 10 - 09 - 09 - 9 - 09

Now we see a bit more variation, yet still are hitting closer to our goal with significantly less streaks. The SwayPotency can be tweaked to allow for the most streak control while still appearing to be a truly random system.

This is a powerful tool for game design but how would one go about using it and what pitfalls should they worry about when using it? I will get into those issues in my next posting.

Either Or

Well, either you have moved back through the archive and found my first post here, or you have located another dead blog with a single blurb. In fitting with my “Either Or” theme, I will be discussing a few aspects of design that will end up merging into one.

First is Battlefield 2's leveling system. Players chose jobs and as they play and do well, they will occasionally get upgrades to spend on improving the different classes. I am a big fan of the ability to level up in a fist person shooter. Not only does it add another aspect of play, but it rewards repeated play through multiple game sessions. The inability to reward repeated play is a major design flaw in round based online games. An earlier version of this system can be seen in Blizzard's Battle.net online ladder system although its purpose is skill based matchmaking. A simple account creation solution and minimal server support are all that are needed to make this player reward a reality.

Next on today's plate is the announced upgrade to CS:Source's weapon prices. Item prices will be dynamically modified based on how much money was spent on them the previous week. If everyone uses a particular gun, the price goes up. No love for the TMP? Then the price drops for me. If their algorithm is dynamic yet accurate enough, the system should do the weapon balancing without the need for developer input, Bayesian style. This is one of the first true economic systems I have seen implemented in a round based online game. All this needs for implementation is a simple feedback system and, once again, minimal server support.

The line between online matchmaking based games and MMO's is blurring and truly valuable things are being developed. Currently we have a simple mechanic that allows players to build an attachment to a character between usually separate rounds of play. We have a way of separating players by skill, allowing for truly skilled players to enjoy themselves without utterly destroying new consumers. Finally is a way to use the actions of the masses to fine tune design problems that before would require genius, trial and error, or just blind luck. I for one, welcome our new semi-genre overlords.