Mom, almost 2 years after the completion of the Three Kingdoms ~Strategic Edition, drawing five stars will always be a way to multiply and flourish. It will always be a week to keep the bottom. My mind is sufficiently Buddhist, so I began to attempt metaphysics, such as
-
Better luck at zero!
-
If you choose a few friendships first and then a few high-level ones, you will get good products.
-
The chances of getting good things are different between the diamonds you spend money on and the diamonds you send in the game.
-
Go to the special places on the map, such as Jiuzhaigou, and come back on a good day.
1. Pseudo-random algorithm
At present, the random algorithms in software are all pseudo-random algorithms. They look random, but they are deterministic! A pseudo-random generator that gets the same sequence as long as the seeds are the same. A simple pseudo-random generator adds a large number to the number and then redeems the other to get the next number. Usually this seemingly random generator is just about evenly distributed in the frequency of sequence elements. There are naturally other ways to evaluate different types of random distributions. As with true random, pseudorandom may have the same elements in succession. However, for random playback of a music player, users will feel that this is not random either. So there is also a deliberate way to eliminate this continuous and identical element, making users feel more random.
At first glance, it seems that pseudo-random algorithms are predictable, but on the one hand, it is hard to predict when a card-drawing algorithm is executed on the server, and when a card-drawing request is sent from the client to the server, and the server is assigned to a different node, which accepts execution time. On the other hand, concurrent requests are made. You don't know if your next card draw will be 11111 or not. To sum up, the pseudo-random algorithm mentioned above is random, but with the support of architecture and concurrent operation, the random algorithm is difficult to predict.
2. Pseudo-random algorithm - > to Bottom
If we first assume that the probability of drawing a card in each game is the same as that officially announced, if a person's face is too dark to be at the extreme of the probability of drawing a card, 100 times they are not.
The lottery costs 1 yuan each time, 1%Chances are you get something worth 90 yuan. A considerable number of participants will feel that if I try my luck first, in case I can't do it, I will get it 100 times in a row, with a small loss. But in fact, the chances of 100 consecutive draws failing are as high as 36.6%-Over 1/3 Proportion. Even after 300 successive pumps, there are still 4.9%The chances are low. That is, if the game has 100,000 players, 4,900 people won 300 consecutive lottery drawings.
3. Tapping algorithm strategy
Different strategies lead to different practices
-
Pure probability random is a pseudo probability, but it is not human controllable after all. Especially when the random number generator is randomly applied to full-service players and all logic, it can be basically determined as the average distribution probability, then what is drawn is face and configured probability. For some players, there are absolutely no kills or top draws, as well as draws once. This experience is the worst when considering the comprehensive experience (those that are drawn once will be recognized as entrustment by others who cannot be drawn, abuse planning in the forums, and finally get out of the hole).
-
The customization probability can be customized from the random number generator or the user's own behavior statistics, for example, when it is not drawn, multiple sampling will increase the probability; If you do, it reduces the probability and gives you a more stable card drawing experience as a whole to achieve the goal of how much you spend and how much you get. But because it's still probable, it's still rocking up and down. Overall, this experience is better than the first one, but it is still not transparent to users and there is the possibility of being scolded
-
The scoring system does not tell you the specific probability, but the player knows it well. Simply put, draw one time to give you an integral, the integral is enough to give directly, the integral is not enough to do nothing. It's a disguised purchase. There is no luck, just pack it for you. Everyone trades fairly. Don't argue about it. However, this practice lacks the pleasure of pumping, in fact, the stimulation point is insufficient. Experience peace, no bullying.
-
The bottom probability is that your face is too dark, so I'll let you do it once to prevent you from retreating, but most of the time you'll experience the pleasure of pumping good stuff out of your card. 5 Total control I increase the overall probability of card drawing, but I want to control the full output, such as 1 hour SSR can only produce 5, enough for this 1 hour will not be out, this will allow players to find some point in time (so-called superstitious card drawing), of course, the server may adjust this time, try not to let players find the rule, this is fighting bravery.
-
Invisible VIP Privilege Are you a high V, don't be happy too soon, you may not be as likely as low V to draw card. Small V will give them more money under the stimulation of something good. You are all high V, you won't be snapped up. Some game schemes are so anti-human. Overall, now the card drawing has reached the level of big data, don't think about taking advantage of the game company's cheapness, it's almost as little as disguised gambling. You just draw, how can the game company make money?
4. Common pseudo-random algorithms
4.1.PRD
4.1.1. Birth and Application
PRD algorithm was born with Warcraft 3, so it can be said that it was born to solve the problem of the probability of critical attack in the game. It is now widely used in the calculation of critical strike probability with MOBA games such as Dota2, LoL and other highly competitive games.
4.1.2. Why was it born?
If the probability of a critical attack is calculated using a real algorithm, then there will be some problems that affect the player's game experience and even the balance of the game. We can calculate:
The rate of one-character assault is 50%, or 0.5%. So if the character makes 100 attacks, ideally, it should produce 50, then what attack will all these 50 attacks generate? For this hypothesis, the probability of one attack and no one is 0.5. For 100 attacks and 50 attacks, the probability is 0.5 ^100 wherever the 50 attacks are placed. This creates a strange situation: the probability that these 50 attacks are evenly distributed among 100 attacks is the same as that of 50 consecutive attacks at the beginning and 50 consecutive attacks at the end.
It can be inferred that the above conclusions are certain even if the probability of a critical attack is 0.3, 0.7, etc.
This should be avoided for more competitive games. Take MOBA games as an example. In a game, one or two key battles usually determine the final winner or loser. If you use the above probability calculation to conclude, it is very likely that the player's luck will affect one or two battles, and ultimately determine the overall game's winner or loser.
Therefore, for competitive games, we should make the distribution of attacks as uniform as possible, that is, for the case of 50 of the 100 attacks mentioned above, we hope that the probability of 50 attacks evenly distributed in 100 attacks is much greater than the probability of 50 attacks concentrated in a certain area.
More simply, for a 0.5 critical attack rate, we hope that players will hit once every other attack, that is, the player's attack will always be a critical attack, no critical attack, no critical attack...
But there are still drawbacks. The goal of our game is to add randomness to the game itself, but we don't want players'luck to have a big impact on the results. If you follow the above calculation, then when the player character's critical rate is 0.5, if the player does not have a critical attack on this attack, the player will know exactly that his next attack will be a critical one. That way, our game loses the randomness brought by the hit rate and loses some gameplay.
Therefore, we need to come up with a random operation method that can achieve a good balance between randomness and uniformity, so the PRD algorithm comes into being.
4.1.3. Algorithms
The representation of the PRD algorithm is very simple:
P(N) = C * N
N denotes the number of current attacks, P(N) denotes the attack rate of the current attack, and C is a probability increment. If we have a critical attack from this attack, we need to reset N to 1, and if this attack does not produce a critical attack, N + 1.
For ease of understanding, here is a direct example:
Set our current player character critical rate to 0.5, then C = 0.3 for the PRD algorithm
The actual chance of a critical strike at the time of the first attack, that is, P(1) = 0.3 * 1 = 0.3, if no critical attack, N + 1, N = 2
The actual chance of a critical attack at this time is P(2) = 0.3 * 2 = 0.6, if no critical attack, N + 1, N = 3
The actual chance of a critical strike on the third attack is P(3) = 0.3 * 3 = 0.9. This attack will generate a critical strike for most players, but if the player is a non-emirate, there will still be no critical strike. That's OK, N + 1, N = 4
The fourth attack, P(4) = 0.3 * 4 = 1.2 >= 1, is bound to strike this time.
You can see that with the PRD algorithm, there is still randomness, that is, the player's luck factor, about whether an attack will strike or not, but even the player with the worst luck will still strike on the fourth attack, so the PRD algorithm can preserve the randomness and reduce the impact of player's luck factor on the game results.
The example above shows that the PRD algorithm will prevent the player from continuing to hit, and the PRD algorithm will also prevent the player from continuing to hit.
The same is true:
P(1) = 0.3 * 1 = 0.3 if there is no critical N + 1
P(2) = 0.3 * 2 = 0.6 if there is no critical N + 1
P(3) = 0.3 * 3 = 0.9, if we do this, we'll reset N to 1 then
P(4) = 0.3 * 1 = 0.3
You can see that after each critical attack, the next one will be reset to the initial critical rate of 0.3, which is also the lowest critical rate throughout the operation.
Therefore, in the PRD operation, the probability of a continuous attack is affected by C, which is a value smaller than the target attack rate, so the probability of a continuous attack is small.
using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;
using System.IO;
using System.Text;
using System.Threading;
public class PRDCalcC : EditorWindow
{
private static readonly string obj = "lock";
private static Dictionary<int, int> prdDic = new Dictionary<int, int>();
private string infoStr = "";
private string dataStr = "In data operations....";
[MenuItem("Tools/PRD_C")]
static void ShowWindow()
{
GetWindow<PRDCalcC>();
}
private void OnGUI()
{
EditorGUILayout.BeginVertical();
if (GUILayout.Button("Operational data"))
{
// Calculate all PRD C values in the 1% - 100% critical range
for (int i = 0; i <= 100; ++i)
{
int j = i;
// Creating a thread is responsible for calculating C-values specifically
Thread thread = new Thread(() =>
{
double p = i * 1d / 100d; // Violence Rate Shown to Players
double c = CFromP(p); // PRD algorithm burst increment
int ic = (int)Math.Round(c * 100, 0); // Convert percentage decimal to integer
lock (obj)
{
prdDic[j] = ic; // Results of calculation are stored in a dictionary
}
});
thread.Start();
}
}
GUILayout.Label(dataStr);
if (prdDic.Count == 101)
{
dataStr = "Data operation completed";
if (GUILayout.Button("Click Generate Profile"))
{
try
{
CreateXml();
infoStr = "Profile generated successfully!";
}
catch (Exception e)
{
infoStr = "Profile generation failed! The error is:" + e;
}
}
}
GUILayout.Label(infoStr);
EditorGUILayout.EndVertical();
}
///
///Generate XML file
///
private void CreateXml()
{
string path = EditorUtility.OpenFolderPanel("Select Target Folder", "", "") + @"/prd.xml";
StringBuilder sb = new StringBuilder();
sb.Append(@"<?xml version=""1.0"" encoding=""UTF - 8"" standalone=""yes""?>");
sb.Append('\n');
sb.Append(@"<root xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"">");
sb.Append('\n');
string xml = null;
lock (obj)
{
// Extract multithreaded data from the dictionary in the main thread and parse it
foreach(var pair in prdDic)
{
sb.Append("<item>\n");
sb.Append(" <p>" + pair.Key + "</p>\n");
sb.Append(" <c>" + pair.Value + "</c>\n");
sb.Append("</item>\n");
}
xml = sb.ToString();
sb.Clear();
xml.Remove(xml.Length - 1);
}
using(FileStream fs = Directory.Exists(path) ? File.OpenWrite(path) : File.Create(path))
{
byte[] bytes = Encoding.UTF8.GetBytes(xml);
fs.Write(bytes, 0, bytes.Length);
fs.Flush();
fs.Close();
}
lock (obj)
{
prdDic.Clear();
}
}
///
///Based on the incoming C value, calculate the average critical rate for the minimum critical range at that C value
///
private static double PFromC(double c)
{
double dCurP = 0d;
double dPreSuccessP = 0d;
double dPE = 0;
int nMaxFail = (int)Math.Ceiling(1d / c);
for (int i = 1; i <= nMaxFail; ++i)
{
dCurP = Math.Min(1d, i * c) * (1 - dPreSuccessP);
dPreSuccessP += dCurP;
dPE += i * dCurP;
}
return 1d / dPE;
}
///
///Calculate the coefficient C in the PRD algorithm based on the incoming critical attack rate
///
private static double CFromP(double p)
{
double dUp = p;
double dLow = 0d;
double dMid = p;
double dPLast = 1d;
while (true)
{
dMid = (dUp + dLow) / 2d;
double dPtested = PFromC(dMid);
if (Math.Abs(dPtested - dPLast) <= 0.00005d) break;
if (dPtested > p) dUp = dMid;
else dLow = dMid;
dPLast = dPtested;
}
return dMid;
}
}
4.2 shuffling algorithm
The most typical application of shuffling algorithms is the random play of a music player.
In the early days, the random play of the player was true random.
But users quickly find that they often encounter the same song playing in succession, or switch back and forth between several songs several times in succession, while some other songs cannot be played hundreds of times.
To solve this problem, the player changes True Random to a shuffling algorithm.
The so-called shuffling algorithm is that if you have 20 songs in your song list, create an array of 1 to 20 and shuffle the 20 numbers like shuffling.
As we can see from the music player, when we click on the previous song after we play it randomly, it is the previous song, not the random one.
4. Summary
- Random algorithms in a software or game are mixed, such as Bouncers in the League of Heroes, Swordsmen, and Pittsburgh policewomen
- Mathematically, there is no Euclidean and no euclidean, just like life, persistence always results
- It's not necessary to keep in mind. You're playing games. Don't let them play.