Como posso impedir que pequenas vantagens numéricas dominem a balança de um encontro?

27

Estou mexendo há algum tempo com um jogo e estou tendo muitos problemas com algo:

Eu tenho dois caracteres, cada um com atributos (cerca de dez) em um intervalo (entre 1 e 20). Eu quero usar esses atributos para gerar um 'roll', de modo que o roll mais alto ganhe esse encontro específico. Vale a pena notar que os dois personagens não estão se danificando / se defendendo. Ambos estão rolando para ver se passam no que eu acho que poderíamos chamar de verificação de habilidade. Ambos estão rolando para passar / falhar contra um valor comum. Eles não interagem um com o outro.

No entanto, quando um dos personagens tem até uma pequena vantagem numérica, qualquer fórmula que eu crie resulta no que é sempre ligeiramente superior, ganhando uma grande maioria do tempo. Isso é indesejável.

Tentei ponderar o atributo 'mais relevante' para o teste em 80% e a soma dos outros atributos em 20%. Também tentei comparar médias para produzir uma diferença relativa e usá-la para aumentar o caráter mais fraco. Ambas as abordagens resultaram nas vantagens significativas que estou tentando remover (por exemplo, se eu executar o encontro 5.000 vezes, produz regularmente um lado vencendo todos os 5.000).

A adição de um componente "sorte" só é importante, ao que parece, se for ponderado de alguma forma a favor do personagem menor, e eu não consegui um bom equilíbrio lá.

Que abordagens posso adotar para atenuar o impacto de uma pequena vantagem numérica, mas ainda preservar e aumentar essa vantagem à medida que a diferença relativa de atributos aumenta?


Por solicitação, aqui estão os detalhes que tenho até agora. Algumas coisas que eu ainda não descobri, então elas permanecem generalidades:

No momento, o rolo é gerado como

0.8 * (mainAttribute) + 0.2 (1/3 * subAttA + 1/3 * subAttB * 1/3 subAttC)

Atualmente, isso produz números na vizinhança de 4,0. Os atributos são gerados aleatoriamente entre os intervalos especificados. O teste atual usa um caractere com atributos de 2 a 4 e o oponente entre 3 e 5. Previsivelmente, esse resultado produz médias próximas a 3 e 4, respectivamente.

Com essa vantagem de um ponto, eu gostaria de ver a vitória mais forte das duas na área de 55% a 60% do tempo, com isso aumentando para ganhar cerca de 80% das vezes, com uma vantagem média de atributo de 5 ou 6, 90% com vantagens de 7 ou 8, deixando espaço para uma vitória improvável quando a diferença aumenta. Eu preferiria nunca ter vitórias garantidas, mas talvez as coisas se tornem muito improváveis ​​- com a vitória de 99,5% ou 99,6% do tempo em que a diferença fica muito grande.

A fórmula atual produz um número não aleatório. A aleatoriedade vem da seleção de quais atributos são relevantes. Nem todos os atributos são usados ​​para cada rolo. É possível que aquele com os atributos mais fracos em geral seja mais forte nas áreas relevantes para essa jogada e roube uma vitória. Mas, previsivelmente, isso acontece raramente.

Minha próxima tentativa foi avaliar seus pontos fortes relativos, medindo uma média de todas as estatísticas de cada um, dividindo-os um contra o outro e usando esse valor para dar um pequeno impulso ao personagem menor. Isso suavizou as coisas um pouco, mas ainda tinha uma tendência pronunciada de produzir coisas como 5.000 vitórias para um cara em cada 5.000 tentativas.

ffenliv
fonte
2
Você diz que a "função é gerada", mas depois publica uma fórmula que sempre gera um número fixo. Onde está a aleatoriedade?
Philipp
11
Então, se eu entendi direito, a única aleatoriedade na mecânica do jogo é a escolha aleatória do atributo principal?
Philipp
2
Mas como o @Philipp implica, 5000 tentativas renderão exatamente os mesmos resultados? Ou você gerar novos atributos cada simulação
Felsir
11
Como exatamente um dos dois vence, se eles não estão interagindo um com o outro? Parece haver alguns dados ausentes aqui?
Erik
11
O rolo que cada um produz é comparado a uma meta que eles precisam atingir. Se um alcança e o outro não, esse ganha. Se os dois alcançarem, a maior das duas vitórias. Se nenhum deles alcança, nenhum deles entende. No improvável empate, eles dividiram o ponto. Por 'não interagir', eu quis dizer não bater ou defender um ao outro no sentido tradicional, pois é para lá que parte da discussão inicial é direcionada.
Ffenliv 18/07/2016

Respostas:

36

O problema com sua abordagem é que você decide o resultado do combate no momento em que decide o status principal. Quando você tem quatro estatísticas principais, e o lutador é apenas melhor em uma delas, a chance de vitória é sempre 1 em 4, não importa quão grandes sejam as diferenças. Quando você deseja obter resultados mais refinados, precisa de mais aleatoriedade.

Primeiro de tudo, acho que você pode manter sua escolha aleatória para o atributo principal e também pode manter sua fórmula, se quiser. É o número que representa quanto de vantagem esse combatente tem nesse encontro específico. Para o restante deste post, vou me referir a isso como justo power.

Um método que eu usei em muitos jogos e que me serviu muito bem quando se trata de um duelo entre duas coisas com um certo poweré rolar um número aleatório de ponto flutuante entre 0e powerpara ambos e ver quem rolou mais alto. Aqui está uma lista dos resultados esperados deste método. As porcentagens não são calculadas, mas geradas experimentalmente, executando 100000 lutas por combinação e contagem de iterações e contando quem venceu com que frequência:

PowerA | PowerB | Win chance of A
  9    |   1    |    94.5%
  8    |   2    |    87.5%
  7    |   3    |    78.6%
  6    |   4    |    66.6%
  5    |   5    |    50.0%
  4    |   6    |    33.3%
  3    |   7    |    21.5%
  2    |   8    |    12.5%
  1    |   9    |    5.5%

O bom desse algoritmo é que ele é dimensionado, independentemente do tamanho dos números com os quais você esteja lidando. A chance de 0,3 vs 0,7 é a mesma de 3 vs 7, 300 vs. 700 ou 3.000.000.000 vs. 7.000.000.000.

Quando isso ainda é imprevisível para o seu gosto, você pode tornar o combate mais previsível rolando vários números aleatórios para cada combatente e somando-os. Devido à lei de grandes números , muitos eventos aleatórios se igualam e resultam em resultados mais previsíveis. Aqui está uma tabela com um número diferente de iterações.

| A | B | Iterations
|   |   |       1 |     2 |     3 |     4 |     5 |     6 |     7 |     8 |     9 |
-----------------------------------------------------------------------------------
| 9 | 1 |   94.5% | 99.3% | 99.9% |100.0% |100.0% |100.0% |100.0% |100.0% |100.0% | 
| 8 | 2 |   87.4% | 96.3% | 98.8% | 99.5% | 99.8% |100.0% |100.0% |100.0% |100.0% | 
| 7 | 3 |   78.7% | 89.2% | 94.0% | 96.6% | 97.8% | 98.9% | 99.2% | 99.6% | 99.7% | 
| 6 | 4 |   66.8% | 74.3% | 79.2% | 82.9% | 85.7% | 88.0% | 89.9% | 91.2% | 92.5% | 
| 5 | 5 |   50.0% | 50.0% | 50.0% | 50.0% | 50.0% | 50.0% | 50.0% | 50.0% | 50.0% | 
| 4 | 6 |   33.6% | 25.6% | 20.9% | 17.1% | 14.7% | 12.0% | 10.2% |  8.9% |  7.5% | 
| 3 | 7 |   21.4% | 10.7% |  6.0% |  3.5% |  2.0% |  1.2% |  0.7% |  0.4% |  0.3% | 
| 2 | 8 |   12.7% |  3.7% |  1.2% |  0.4% |  0.1% |  0.1% |  0.0% |  0.0% |  0.0% | 
| 1 | 9 |    5.5% |  0.7% |  0.1% |  0.0% |  0.0% |  0.0% |  0.0% |  0.0% |  0.0% | 

Os resultados de 100% e 0% na tabela acima são uma ilusão devido a diferenças de arredondamento. A menos que o powerde um combatente seja exatamente 0, sempre há a possibilidade de ele vencer. Isso simplesmente não aconteceu no teste acima, então você pode esperar que seja abaixo de 1: 100000.

Você também pode observar algumas pequenas irregularidades que podem ser atribuídas às alterações de humor do java.lang.Random e podem não aparecer quando você executa o código novamente com uma semente diferente.

O programa que eu usei para gerar esta tabela (Java).

public class Main {

    private static Random random = new Random();
    private static final int SAMPLES = 100000;

    public static void main(String[] args) {        
        for (int i = 1; i < 10; i++) {
            double powerA = 10.0 - i;
            double powerB = i;
            System.out.print("| ");
            System.out.print((int)powerA);
            System.out.print(" | ");
            System.out.print((int)powerB);
            System.out.print(" |   ");

            for (int iterations = 1; iterations < 10; iterations++) {
                int wins = 0;
                for (int j = 0; j < SAMPLES; j++) {
                    if (fight(powerA, powerB, iterations)) wins++;
                }
                System.out.print(String.format("%2.1f", 100.0 * (double)wins / (double)SAMPLES));
                System.out.print("% | ");
            }
            System.out.print("\n");
        }       
    }

    private static boolean fight(double powerA, double powerB, int iterations) {        
        double sumA = 0.0f;
        double sumB = 0.0f;     
        for (int i = 0; i < iterations; i++) {
            sumA += random.nextDouble() * powerA;
            sumB += random.nextDouble() * powerB;

        }       
        return sumA > sumB;
    }
}

Se você deseja usar esse código em seu jogo, ele está licenciado sob a WTF Public License Versão 2, publicada por Sam Hocevar .

Philipp
fonte
Esta é uma abordagem interessante. Em algumas das minhas tentativas, eu meio que fiz isso. Vou ligar isso e tentar. Muito Obrigado.
Ffenliv 18/07
10
As porcentagens em sua primeira tabela podem ser calculadas exatamente como 1 - powerA / ( 2 * powerB ).
Kyle
2
@ Kyle Isso só funciona enquanto powerA < powerB. Quando o powerA for maior, você precisará mudar para powerB / (2 * powerA).
19416 Dorus
11
Não sei se o StackExchange ToS permite que você se desvie da licença obrigatória do site em conteúdo e código, mesmo que sua licença seja mais permissiva que a deles. Obviamente, é impossível descobrir se é o MIT proposto ou ainda o CC.
Lars Viklund
5
@LarsViklund Você está iniciando uma discussão off-topic aqui, mas não, isso está incorreto. A licença para stackexchange não é exclusiva, o que significa que ainda estou livre para doar minha propriedade intelectual sob quaisquer outros termos de licença quando desejar. Minhas contribuições têm licença dupla sob CC-BY-SA (conforme exigido pelo Stackexchange) e WTFPL. Você pode escolher sob qual condição deseja usar minhas contribuições.
19716 Philipp
13

Seu erro é usar uma abordagem "baseada em dados". Você está em um computador e pode usar qualquer sistema que desejar. Faça uma tabela que transforme a diferença de valores em uma chance de% de idade para vencer e, em seguida, você pode definir os valores para absolutamente o que quiser, por exemplo

Difference (A-B) | %chance A wins
-----------------|---------------
+5 or greater    | 100%
+4               | 95%
+3               | 85%
+2               | 70%
+1               | 55%
0                | 50%

(Você só precisa fazer metade da mesa, basta sempre escolher A como aquela com o status mais alto)

Obviamente, esses números são apenas um exemplo, você pode fazer com que ele siga a distribuição que lhe agrada.

Jack Aidley
fonte
2
Embora atualmente esteja trabalhando com um sistema baseado na resposta aceita, isso é bastante simples e também pode ser uma boa solução para mim. Eu sabia que o bom e velho StackExchange viria para mim.
Ffenliv 19/07/19
5

Essa é uma pergunta bastante profunda, honestamente, do ponto de vista da mecânica do jogo. Mas há algumas coisas que podem ajudar.

Primeiro, é por isso que a maioria dos jogos tem um componente separado para acerto e dano, onde há um "teste" para ver se você acerta e, em seguida, um "teste" contra uma tabela ou intervalo de dano para o personagem em questão. Isso também leva a alguns arquétipos padrão entre os gêneros, nos quais você pode ter personagens menores e mais rápidos que têm menos pontos de vida, mas causam mais dano (magos de canhão de vidro, certos tipos de malandros) e personagens maiores e blindados que sofrem menos danos (tanques, guerreiros )

Isso leva a um equilíbrio natural, onde o personagem menor pode ser frágil, mas evita ser atingido com frequência devido a uma habilidade do tipo agilidade, e também equilibra o campo de jogo, causando mais dano (uma mágica ou um efeito venenoso que causa dano ao personagem). Tempo). O tanque pode ser mais lento e ser atingido com mais frequência, mas muitas vezes tem um enorme poço de saúde ou pontos de vida para sustentar, no entanto, tende a causar menos dano por golpe (ou dano por segundo).

O pano de fundo para isso é o motivo pelo qual muitos jogos passam continuamente pelo equilíbrio de armas, classes e estatísticas. World ou Warcraft, Destiny, Diablo, Battlefield: qualquer tipo de jogo em qualquer gênero geralmente passa pelo equilíbrio e ajuste ao longo do tempo.

Isso pode não ser uma resposta direta, mas você pediu idéias gerais. Então, vamos também avaliar o sistema de jogo.

Como esses atributos funcionam? Se todo o resto for igual (sem arquétipo, sem armadura, ou melhores armas ou outros enfeites), é absolutamente provável que qualquer pequeno ganho jogue as coisas fortemente a favor de um lado. A adição de facetas ao combate complica qualquer sistema, mas também permite mais flexibilidade.

Jesse Williams
fonte
Como um aparte, acho que essa é uma excelente pergunta e pode levar a discussões muito interessantes sobre mecânica de jogo. É possível que isso acabe se tornando baseado em opiniões, por isso é importante ter cuidado com essas tangentes (este jogo é melhor que este e assim por diante), mas há alguns fundamentos envolvidos que podem ser esclarecedores à medida que mais pessoas postam.
Jesse Williams
Divertidamente, eu tinha um mecânico de 'acerto' e 'dano' em primeiro lugar, mas o descartei por motivos que não me lembro mais (e foi apenas ontem. Minha memória é um pouco ... fraca). Devo ser claro, os personagens não estão atacando / se defendendo. Não há componente de dano. É uma checagem de habilidades, onde ambas são checadas contra um valor comum para ver se o teste 'passa'. Não há interação entre as duas que estão competindo.
Ffenliv 18/07/2016
2

Há duas grandes coisas.

Primeiro, lembre-se de que você está em um computador. Você pode criar qualquer sistema que desejar. Não há necessidade de se limitar a um lançamento de d20, embora isso seja fácil de entender para os jogadores. Coisas como rolar 6 dados d6 são fáceis em um computador e fornecem muito menos resultados aleatórios.

Segundo, olhando para outros sistemas como o D&D, é óbvio que eles simplesmente diminuem bastante o efeito dos atributos. Em vez de fazer com que sua estatística base adicione 80% de seu valor à regra, reduza a escala e torne sua adição mais sutil. Em D&D, por exemplo, se você tem 18 de destreza, recebe apenas 4 como bônus na sua classe de armadura.

Portanto, resumidamente, tudo o que você precisa fazer é diminuir o tamanho do seu domínio para se ajustar melhor ao seu alcance. Mas, qualitativamente, eu pensaria que olhar para outros sistemas e criar coisas que pareçam menos matemáticas tornariam um sistema mais satisfatório para o jogador.

Yudrist
fonte
1d20 ou 6d6 ou 5d4 - os resultados não são mais ou menos aleatórios, você apenas altera o intervalo. Aleatório é aleatório. Reduzir o alcance e o domínio não é suficiente para equilibrar um sistema. É provável que apenas desenhe as coisas por mais tempo.
Jesse Williams
8
@JesseWilliams isso não é verdade. 1d20 tem uma chance igual de obter qualquer um dos valores possíveis. Com 5d4, é muito mais provável que você consiga 12 ou 13 do que 20.
Rob Watts
Vários rolos também ocultam falhas nos geradores de números, o que é especialmente importante nos computadores. De fato, combinar rolos em um nível de bit a bit é praticamente a base de muitos geradores.
Yudrist 19/07/16
Eu estou corrigido.
Jesse Williams
3
@ RobWatts que ainda não é mais ou menos aleatório, é apenas uma distribuição diferente. Ter informações sobre "rolagens" anteriores não permite que você faça uma melhor previsão de resultados futuros (ignorando falhas no RNG), por isso é igualmente aleatório.
chbaker0
1

Que tal isso: adicione uma constante, por exemplo, 1000, a todos os atributos envolvidos. Então a diferença relativa se torna muito pequena.

Alex
fonte
1

Conheça seus números

Acrescentando um pouco à resposta de Philipp , a saber, que rand [x] comparado a rand [y] nem sempre produz o que se espera. Abaixo de uma tabela onde comparamos A e B. Ambos A e B têm os valores 1 ... 10. Comparamos de duas maneiras (nota: rand () neste caso gera números inteiros, isto é, rolos):

  1. rand [A]> rand [B]
  2. rand [A] ≥ rand [B] (ou seja, maior ou igual a)

Além disso, comparamos

  1. rand [A * 1000000]> rand [B * 1000000]
    (neste caso, é irrelevante se é> ou ≥ porque estão tão perto). Esses grandes números estão entre parênteses.

As células contêm% 's. Cada resultado contém 1 milhão de iterações (feitas usando o Dyalog APL ).

┌────────────┬────────────┬────────────┬────────────┬────────────┬────────────┬────────────┬────────────┬────────────┬────────────┬────────────┐
 A      B  1 (1000000)│ 2 (2000000)│ 3 (3000000)│ 4 (4000000)│ 5 (5000000)│ 6 (6000000)│ 7 (7000000)│ 8 (8000000)│ 9 (9000000)│10(10000000)│
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 1 (1000000)│ >0(50) 100  >0(25) 50  >0(17) 33  >0(13) 25  >0(10) 20   >0(8) 17   >0(7) 14   >0(6) 13   >0(6) 11   >0(5) 10
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 2 (2000000)│>50(75) 100 >25(50) 75 >17(33) 50 >12(25) 38 >10(20) 30  >8(17) 25  >7(14) 21  >6(13) 19  >6(11) 17  >5(10) 15
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 3 (3000000)│>67(83) 100 >50(67) 83 >33(50) 67 >25(37) 50 >20(30) 40 >17(25) 33 >14(21) 29 >12(19) 25 >11(17) 22 >10(15) 20
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 4 (4000000)│>75(87) 100 >62(75) 88 >50(62) 75 >37(50) 63 >30(40) 50 >25(33) 42 >21(29) 36 >19(25) 31 >17(22) 28 >15(20) 25
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 5 (5000000)│>80(90) 100 >70(80) 90 >60(70) 80 >50(60) 70 >40(50) 60 >33(42) 50 >29(36) 43 >25(31) 38 >22(28) 33 >20(25) 30
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 6 (6000000)│>83(92) 100 >75(83) 92 >67(75) 83 >58(67) 75 >50(58) 67 >42(50) 58 >36(43) 50 >31(38) 44 >28(33) 39 >25(30) 35
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 7 (7000000)│>86(93) 100 >79(86) 93 >71(79) 86 >64(71) 79 >57(64) 71 >50(57) 64 >43(50) 57 >38(44) 50 >33(39) 44 >30(35) 40
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 8 (8000000)│>88(94) 100 >81(87) 94 >75(81) 87 >69(75) 81 >63(69) 75 >56(62) 69 >50(56) 62 >44(50) 56 >39(44) 50 >35(40) 45
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
 9 (9000000)│>89(94) 100 >83(89) 94 >78(83) 89 >72(78) 83 >67(72) 78 >61(67) 72 >55(61) 67 >50(56) 61 >44(50) 56 >40(45) 50
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
10(10000000)│>90(95) 100 >85(90) 95 >80(85) 90 >75(80) 85 >70(75) 80 >65(70) 75 >60(65) 70 >55(60) 65 >50(55) 60 >45(50) 55
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘

Se observar A = 2 e B = 3 (e 1 milhão de testes):

  • rand (2) é maior que rand (3) em 17% dos casos
  • rand (2000000) é maior que rand (3000000) em 33% dos casos (redimensionamento de aviso ./ .. arredondamento inteiro)
  • rand (2) é maior ou igual a rand (3) em 50% dos casos
  • (rand (2000000) também é maior ou igual a rand (3000000) em 50% dos casos)

Surpresas podem ser as seguintes:

  • rand (2)> rand (3) em apenas 17% dos casos
  • rand (10)> rand (10) em 45% dos casos
  • rand (6)> rand (5) outras vezes

Na verdade, eu poderia resolver esse Q de maneira diferente, simplesmente digitando à mão uma tabela de 10x10 com boas porcentagens desejadas (talvez alguém queira irregularidade também?). Então, se necessário, interpole entre dois valores, para obter uma porcentagem exata, digamos que seja por algum motivo 53. Então é fácil gerar uma ocorrência de 53% de probabilidade, 0 ou 1, simplesmente executando um rand (100) e testando se for menor ou igual a 53 :-).

Isso é ao longo da linha que Jack Aidley menciona.

Ventobravo
fonte
11
Você está usando um gerador de números aleatórios que gera números inteiros? Minha resposta usa um RNG que gera números de ponto flutuante de precisão dupla entre 0.0e 1.0. Nesse caso, a diferença entre >e >=é insignificante. Você pode apontar isso.
Philipp
Sim, isso faz parte da mensagem pretendida, apenas para apontar o comportamento variável dos espaços numéricos, por exemplo. números inteiros de pequeno valor (granularidade aproximada) vs. número inteiro de grande valor (e de fato também flutuam) com granularidade fina. Vou inserir "número inteiro" em algum lugar, thx para identificar. Na verdade, eu indico a negligência: "(neste caso, é irrelevante se é> ou ≥, pois elas são tão próximas"). Muitas vezes, os números encontram valores surpreendentes (para a mente humana) se o sistema não é incentivado a buscar equilíbrio. Genericamente falando, ofc, não necessariamente neste caso.
Stormwind
0

A abordagem tradicional que várias respostas referenciaram implicitamente, mas que ninguém definiu de fato, é que a tarefa requer um rolamento de dados fixo e adiciona um modificador de habilidade derivado de suas estatísticas.

Por exemplo, se dois jogadores seguirem o procedimento:

  • Role um dado de 14 lados
  • Adicione seu modificador ao rolo de molde

e repita até que um lado supere o outro e obtenha números no seu intervalo: eis as chances de vitória com uma vantagem numérica dada ao seu modificador:

0   50%
1   57%
2   64%
3   70%
4   76%
5   81%
6   85%
7   89%
8   92%
9   95%
10  97%

fonte
0

Os personagens não se desafiam pela supremacia. Eles desafiam um requisito. E se ambos forem aprovados no requisito. Quem ganha? Estou surpreso que você não tenha desafiado a lógica o suficiente para fazer cálculos com ela.

De qualquer maneira, aqui estão duas coisas que podem lhe fazer bem.

Caso de chance de vitória com vantagem:

Se a barra de passe / verificação de habilidade for um lançamento de 10. A Rola 40. B Rola 42. SE apenas um tiver que vencer. Começando com um A 50% Win / B 50% Win. Você pode adicionar% para ganhar chance com base na quantidade de vantagem. O rolo B tem (42-40) / 40 = 5% de vantagem em termos de rolo. Adicionando-o diretamente, a chance de vitória de B é de 55%. Ou você pode determinar uma chance de vitória personalizada por porcentagem de vantagem. Digamos que, para cada vantagem de 100%, você adicione 10% de chance de ganhar. Então, se A rola 10 e B rola 20. Então A vence 40% e B vence 60% dos casos.

Conceito de aleatoriedade justo:

Ao fazer uma chance padrão de 30% de ganhar, você pode acabar vencendo 38 cheques em 100.

Algumas pessoas querem uma etapa extra na justiça e garantem que uma chance de 30% sempre ganhe exatamente 30 dentre 100 encontros e seja suficiente com a aleatoriedade de não saber quais encontros na sequência são uma vitória e quais são uma perda.

Isso é particularmente útil para economias de jogo bem calculadas. Porque uma estatística aleatória de 70% de chance de ganhar. Diga 70% de chance de uma multidão perder 5 de ouro. As multidões podem acabar perdendo o ouro 81 vezes em 100. O que tira os fluxos de receita / despesa do saldo. E, dependendo de quantas entidades / instâncias usam esses rolos, a inflação e / ou a escassez são inevitavelmente criadas. É claro que muitas pessoas nem sequer têm uma estimativa aproximada de todos os detalhes de sua economia. Muitas pessoas são suficientes para fazer "a maioria" dos pontos de economia. E deixe algumas variáveis ​​de geração que não são calculadas e acumule discrepâncias de horas extras, mesmo com boa aleatoriedade.

Inflação e escassez não são um problema por si só. Você pode gerenciar aleatoriedade injusta e até variáveis ​​imprevistas se sua economia estiver configurada para responder adequadamente à inflação e à escassez.

Por que se preocupar com isso, pois a lei dos grandes números equilibra as coisas a longo prazo?

Nem todo ambiente pode manter seu comportamento de design, contando com coisas para equilibrar mais tarde ...

helena4
fonte
Eu gosto especialmente da última frase. Agarrando de outro lugar: acredito que, por exemplo, a proporção de entrada / saída da Viking Lotto é de cerca de 4: 1 a longo prazo (onde se poderia substituir "longo" por "grande"); possui um comportamento de design quase controverso (mas bem definido) e funciona. Não se pode executar a matemática abaixo, a menos que o comportamento do design seja definido com precisão primeiro. Números tendem a ser descontrolada sem controle ...
Stormwind
@ Stormwind, é claro. Se o projeto / teoria não tem - a matemática é inútil. É apenas uma ferramenta. Vi designers com nível de matemática da 5ª série puxando boas economias. Eles simplesmente mapearam o que queriam fazer logicamente e foram para o pessoal de matemática (geralmente os codificadores) para obter as ferramentas / conselhos sobre como fazer os bits de matemática. De alguma forma, ainda consegue não ser óbvio para todos - quanto mais problemas você tiver com a planta - mais dor de cabeça verá na construção. Apenas pegar algum sistema e aprimorá-lo está totalmente errado. Se você se contentar com o que começar a funcionar primeiro, não será realmente criativo.
helena4