Як я можу запобігти невеликим числовим перевагам домінувати над балансом зустрічі?

Я деякий час займався грою, і я маю досить багато проблем з чимось:

У мене два символи, кожен з яких має атрибути (близько десяти) у діапазоні (від 1 до 20). Я хочу використовувати ці атрибути, щоб створити "рол" таким чином, що вищий рулон виграє саме цю зустріч. Варто зауважити, що два персонажі не завдають шкоди / захищають один одного. Вони обоє котиться, щоб побачити, чи пройдуть те, що я думаю, ми могли б викликати перевірку вміння Вони обоє котиться, щоб пройти / провалитися проти загальної цінності. Вони не взаємодіють між собою.

Однак, коли один із персонажів має навіть невелику чисельну перевагу, будь-яка формула я придумала результати в тому, що коли-небудь трохи перевершує той, який виграє величезну більшість часу. Це небажано.

Я спробував зважити "найрелевантніший" атрибут для тесту в 80%, а сума інших атрибутів - 20%. Я також спробував порівняти середні показники, щоб створити відносну різницю і використовувати це для посилення слабшого характеру. Обидва підходи призвели до значних переваг, які я намагаюся усунути (наприклад, якщо я проводжу зустріч 5000 разів, це досить регулярно дає одну сторону, вигравши всі 5000).

Додавання компонента "удачі" має значення лише, мабуть, якщо воно зважене якось на користь меншого характеру, і я не досяг хорошого балансу там.

Які підходи я можу застосувати, щоб притупити вплив невеликої чисельної переваги, але все-таки зберегти та збільшити цю перевагу в міру збільшення відносного розриву в атрибутах?

За запитом, ось які моменти я маю досі. Деякі речі, які я ще не з'ясував, вони залишаються загальними:

На даний момент ролик формується як

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

В даний час це створює числа в районі 4,0. Атрибути генеруються випадковим чином між заданими діапазонами. Поточний тест використовує один символ з атрибутами від 2 до 4, а опонент - між 3 і 5. За прогнозами, це дає середні показники, близькі до 3 і 4 відповідно.

З цією перевагою в один бал, я хотів би бачити сильнішу з двох виграшів у районі від 55% до 60% часу, при цьому масштабування виграє приблизно 80% часу із середньою перевагою атрибута 5 або 6, 90% при перевазі 7 або 8, що залишає місце для малоймовірної виграші, коли розрив зростатиме. Я вважаю за краще ніколи не мати гарантованих виграшів, але, можливо, речі стають дуже малоймовірними - на мету виграти 99,5% або 99,6% часу, коли розрив стає дуже великим.

Поточна формула виробляє невипадкове число. Випадковість походить від вибору атрибутів, які є релевантними. Не всі атрибути використовуються для кожного рулону. Можливо, щоб той, хто має загальні слабкіші атрибути, був сильнішим у відповідних для цього областях і вкрав виграш. Але, передбачувано, це трапляється рідко.

Наступною моєю спробою було зважити їх відносні сили, взявши в середньому всю статистику кожної людини, розділивши їх один на одного та використовуючи це значення, щоб дати невеликий прирік меншому характеру. Це трохи згладило речі, але все ще мало яскраво виражену тенденцію виробляти такі речі, як 5000 перемог для одного хлопця з 5000 спроб.

Проблема вашого підходу полягає в тому, що ви вирішуєте результат бою в той момент, коли ви приймаєте рішення про головну статистику. Якщо у вас є 4 основні статистичні дані, а боєць краще лише в одній з них, їх шанси на виграш завжди 1 на 4, незалежно від того, наскільки великі різниці є насправді. Коли ви хочете отримати більш дрібнозернисті результати, вам потрібно більше дрібнозернистих випадковостей.

Перш за все, я думаю, що ви можете зберегти свій випадковий вибір для головного атрибута, а також можете зберегти свою формулу, якщо хочете. Саме число відображає, скільки переваг має цей бойовий діяч у цій конкретній зустрічі. У решті цієї публікації я буду називати це як справедливе power.

Метод, який я використовував у досить багатьох іграх і який досить добре служив мені, коли мова йде про поєдинок між двома речами з певним power, - це перекинути випадкове число з плаваючою комою між 0і powerдля обох, і подивитися, хто скотився вище. Ось список очікуваних результатів цього методу. Проценти не обчислюються, а створюються експериментально, проводячи 100000 боїв за комбінацію та підрахунок ітерації та підрахунок того, хто часто виграв:

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%

Приємне в цьому алгоритмі полягає в тому, що він масштабує незалежно від того, наскільки великі цифри ви маєте справу. Шанс 0,3 проти 0,7 такий самий, як у 3 проти 7, 300 проти 700 або 3 000 000 000 проти 7 000 000 000.

Коли це все ще занадто непередбачувано на ваш смак, ви можете зробити бій більш передбачуваним, прокручуючи кілька випадкових чисел для кожного учасника бойових дій і додаючи їх. Внаслідок закону великої кількості багато випадкових подій вирівняються і приведуть до більш передбачуваних результатів. Ось таблиця з різною кількістю ітерацій.

| 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% | 

Результати 100% і 0% у наведеній таблиці є ілюзією через різницю округлення. Якщо powerтільки учасник бойових дій не дорівнює 0, завжди є можливість виграти. У вищенаведеному тесті цього просто не сталося, тому ви можете очікувати, що він буде нижче 1: 100000.

Ви також можете помітити деякі незначні порушення, які можуть бути віднесені до перепадів настрою java.lang.Random і можуть не з’являтися, коли ви знову запускаєте код з іншим набором даних.

Програма, яку я використовував для створення цієї таблиці (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;
    }
}

Якщо ви хочете використовувати цей код у своїй грі, він ліцензований згідно з WTF Public License Version 2, опублікованою Сем Хочеваром .

Ваша помилка - використання підходу на основі "кістки". Ви на комп’ютері, можете використовувати будь-яку систему, яка вам подобається. Створіть таблицю, яка перетворює різницю значень у% вікового шансу на перемогу, а потім ви можете встановити ці значення абсолютно будь-що вам подобається, наприклад

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

(Вам потрібно лише зробити половину таблиці, просто завжди вибирайте A як той, що має вищий статистичний показник)

Очевидно, що ці цифри є лише прикладом, і ви можете змусити його слідувати тому, що вам подобається.

Це досить глибоке питання, чесно кажучи, з позицій ігрової механіки. Але є кілька речей, які можуть допомогти.

По-перше, саме тому в більшості ігор є окремий компонент для удару та пошкодження, де є "котиться", щоб побачити, чи потрапили ви за пошкодження, а потім "котиться" до таблиці пошкоджень або дальності для даного персонажа. Це також призводить до деяких стандартних архетипів у різних жанрах, де у вас можуть бути менші, швидші персонажі, які мають менше точок удару, але завдають більше шкоди (скляні магнети з гармати, певні типи шахраїв) та більші броньовані персонажі, які завдають менше шкоди (танки, воїни ).

Це призводить до природного балансу, коли менший персонаж може бути тендітним, але уникає ударів так часто, як здатність типу спритності, а також вирівнює ігрове поле, роблячи більше шкоди (заклинання або отруйний ефект, що завдає шкоди більше) час). Танк може бути повільнішим і частіше отримувати удари, але часто має величезний стан здоров’я або пункти потрапляння, але, як правило, менше шкоди за удар (або пошкодження в секунду).

Передумовою для цього є те, чому багато ігор постійно проходять через балансування зброї, класів та статистики. World or Warcraft, Destiny, Diablo, Battlefield: будь-яка гра в будь-якому жанрі часто проходить через балансування та налаштування з часом.

Це може бути не прямою відповіддю, але ви запитували загальні ідеї. Отже, давайте також дамо оцінку ігровій системі.

Як функціонують ці атрибути? Якщо все інше рівне (немає архетипу, немає броні чи кращої зброї чи чогось іншого), то будь-який незначний приріст абсолютно ймовірно кине речі на користь однієї сторони. Додавання граней для боротьби ускладнює будь-яку систему, вона також забезпечує більшу гнучкість.

Є дві великі речі.

По-перше, пам’ятайте, що ви на комп’ютері. Ви можете зробити будь-яку бажану систему. Не потрібно обмежувати себе в ролику d20, хоча це легко зрозуміти гравцям. Такі речі, як прокатка кісток 6 d6, на комп'ютері легко, і вони дають набагато менш випадкові результати.

По-друге, дивлячись на інші системи, такі як D&D, очевидно, що вони просто значно зменшують ефект атрибутів. Замість того, щоб ваш базовий статистик додав до правила 80% його значення, зменшіть його і зробіть його додавання більш тонким. Наприклад, в галузі науково-дослідних робіт, якщо у вас є спритність 18, ви отримуєте лише 4 бонуси для вашого класу броні.

Отже, коротко кажучи, все, що вам потрібно зробити, це зменшити масштаб вашого домену, щоб краще відповідати вашому діапазону. Але якісно я би подумав, що перегляд інших систем і придумування речей, які здаються менш математичними, зробили б для системи більш задоволеною систему.

Як щодо цього: додайте константу, наприклад 1000, до всіх відповідних атрибутів. Тоді відносна різниця стає дуже малою.

Знайте свої номери

Додавши трохи відповіді Філіпа , а саме те, що rand [x] порівняно з rand [y] не завжди може призвести до того, що очікується. Нижче таблиці, де ми порівнюємо A до B. І A, і B мають значення 1 ... 10. Ми порівнюємо двома способами (зауважте: rand () в цьому випадку генерує цілі числа, тобто рулони):

1. rand [A]> rand [B]
2. rand [A] ≥ rand [B] (тобто більший або рівний)

Додатково ми порівнюємо

3. rand [A * 1000000]> rand [B * 1000000]
   (у цьому випадку не має значення, чи є> або ≥, оскільки вони настільки близькі). Ці великі цифри знаходяться в дужках.

Клітини містять% s. Кожен результат містить 1 мільйон ітерацій (зроблених за допомогою 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│
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘

Якщо дивитися на A = 2 і B = 3 (і 1 мільйон тестів):

• rand (2) більший, ніж rand (3) у 17% випадків
• rand (2000000) більший, ніж rand (3000000) у 33% випадків (помітка масштабування ./ .. ціле число округлення)
• rand (2) більший або рівний rand (3) у 50% випадків
• (rand (2000000) також перевищує або дорівнює rand (3000000) у 50% випадків)

Несподіванками можуть бути:

• rand (2)> rand (3) лише у 17% випадків
• rand (10)> rand (10) у 45% випадків
• rand (6)> rand (5) кожен інший раз

Насправді я міг би вирішити цей Q по-іншому, просто ввівши вручну таблицю 10x10 з приємними, бажаними відсотками (можливо, хочеться також і нерівності?). Тоді, якщо потрібно, інтерполюйте між двома значеннями, щоб отримати точний відсоток, скажіть, це з якоїсь причини 53. Тоді легко генерувати 53-відсотковий хіт, 0 або 1, просто виконавши рейд (100) і тестуючи якщо вона менша або дорівнює 53 :-).

Це по лінії, про яку згадує Джек Едлі .

Традиційний підхід, на який явно посилаються кілька відповідей, але ніхто насправді не прописав, це те, що для цього потрібен фіксований ролик і додайте модифікатор здатності, отриманий з вашої статистики.

Наприклад, якщо два гравці дотримуються процедури:

• Прокатати 14-сторонній штамб
• Додайте їх модифікатор до рулону

і повторюйте, поки одна сторона не б'є іншу, тоді ви отримуєте цифри у своєму діапазоні: ось шанси на перемогу із заданою числовою перевагою для їх модифікатора:

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

Персонажі не кидають виклик один одному на перевагу. Вони оскаржують вимогу. Що робити, якщо обоє пройдуть вимогу. Хто виграє? Я здивований, що ти не оскаржив достатньо логіки, що ти навіть пішов на її обчислення.

Так чи інакше, ось дві речі, які можуть вам принести користь.

Виграйте шанс з перевагою:

ЯКЩО пропуск бару / перевірка майстерності - це рулон з 10. A Rolls 40. B Rolls 42. IF Якщо тільки один повинен виграти Починаючи з рівного A 50% Win / B 50% Win. Ви можете додати%, щоб виграти шанс на основі переваги. Рулон B має (42-40) / 40 = 5% переваги щодо перекоту. Додавання безпосередньо робить шанси на виграш B на 55%. Або ви можете визначити власні шанси на виграш за відсоток переваги. Скажіть, що за кожну 100% перевагу ви додаєте 10% шансів на перемогу. Отже, якщо A набиває 10 і B котиться 20. Тоді A виграє 40%, а B виграє 60% випадків.

Концепція справедливої ​​випадковості:

Зробивши стандартний 30% шанс на перемогу, ви можете виграти 38 чеків із 100.

Деякі люди хочуть додаткового кроку в чесності і переконують, що шанс на 30% завжди виграє рівно 30 із 100 зустрічей і достатньо випадкових випадків, коли вони не знають, які зустрічі в послідовності є виграшними, а які - втратою.

Це особливо корисно для добре розрахованої економіки гри. Тому що випадковий стат на 70% шансів на перемогу. Скажіть 70% шансу, що мафія скине 5 золотих. Моби можуть в кінцевому рахунку скинути золото 81 раз із 100. Це скидає доходи / витрати, витікаючи з балансу. І залежно від того, скільки організацій / інстанцій використовують такі рулони, неминуче створюються інфляція та / або дефіцит. Звичайно, багато людей навіть не мають приблизних оцінок повної віддачі вхідних / витратних витрат у своїй економіці. Дуже багато людей вистачає на те, щоб робити "більшість" очок економії. І залиште кілька змінних поколінь, які не обчислюються, і складіть розбіжність понаднормово, навіть при справедливій випадковості.

Інфляція та дефіцит самі по собі не є проблемою. Ви можете управляти нечесними випадковістю і навіть непередбачуваними змінними, якщо ваша економіка налаштована адекватно реагувати на інфляцію та дефіцит.

Чому це турбується, коли закон великої кількості зрівняє речі з часом?

Не кожне середовище може зберігати свою дизайнерську поведінку, розраховуючи на те, щоб вирівняти їх згодом ...