Практичний баланс механіки відеоігор «випадкових»


12

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

Поширена тема, з якою я стикаюся, - це дисбаланс, коли мова йде про "випадковість" механіки RPG. Шанс критичного удару. Шанс удару / ухилення / міс / пари / блокування тощо. Найбільшою проблемою в сучасних іграх RPG є факторинг у Haste (Attack Speed), оскільки він так агресивно з'єднується з іншими базовими механізмами. Очевидно, що чим більше разів гравець атакує, побічно збільшує їх "швидкість" критичних ударів, або ударів. Це створює величезний дисбаланс, і більшість рішень надходять у формі обмеження поспіху або використання зменшувальних прибутків або вбивства великої статистики збільшується.

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

Ось практичний приклад:

  • 50% шансу критично завдати удару, з 1 атакою в секунду = в середньому 0,5 критичного удару в секунду.
  • 50% шансу критично завдати удару, з 2 атаками в секунду = в середньому 1 критичний удар за секунду

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

Чи корисно замість цього використовувати коефіцієнт, щоб визначити погоду, чи не відбувається щось проти ваг статики, обмеження та затримки?
Мій спрощений приклад:
CATE Critical Strike = Шанс критики / атаки за секунду

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

Це далекоглядне рішення? Наразі на ринку існують робочі приклади ігор, які не обмежують чи не карають "швидких" побудов персонажів?


4
Умноження шансів не працює так. 50% шансів удвічі менше, ніж шансів 75%.
API-Beast

Це не міра випадкових випадків за один удар. Це міра швидкості критичних ударів на одиницю шкоди в секунду. У другому прикладі ви майже гарантуєте собі 1 критичний за секунду збиток.
robphill

3
@ Mr.Beast: Вони теж не працюють так. ;-)
Ерік

@robphill Це 75%. Подумайте про це так: ви перегортаєте дві монети. Які шанси на те, що одна з них - голова (критична)? У вас є 4 можливі результати HH - HT - TH -TT, тобто у 3/4 випадків, у вас є голови (ви критикуєте), і лише в 1/4 випадків у вас є дві голови (два критики)
Андреас,

Відповіді:


3

Описана вами проблема не обов'язково полягає в поспіху. Йдеться про мультиплікативні ефекти збільшення різних статистичних даних. Поспіх збільшує удари в секунду, що збільшує збитки і будь-що з шансом трапитися на удар. Іншим прикладом може бути збільшення + dmg від критеріїв, яке потім збільшує значення будь-якого + шансу% критичного шансу.

Ви можете отримати вигоду з вилучення бонусних програм із критичних подій.

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

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

Якщо це все ще неприємно для вас, можливо, те, що ви шукаєте, - це не поспішний механік, а щось більш схоже на вітрянку в WoW. Чистий відсоток поспіху завжди потребуватиме високих цифр, перш ніж він стане помітним, і саме такі високі цифри викликають проблеми з іншими системами.

Якщо ви просто шукаєте, щоб побачити додаткові нормальні атаки, додайте статистику, яка дає шанс удару, щоб отримати безкоштовний додатковий звичайний розмах, який не може випустити крит або будь-яку іншу спеціальну атаку. У WoW цю здатність називають windfury, і це завжди цікавіше бачити, ніж рівний відсоток поспіху. Числове значення не відрізняється від критичного удару, але воно все одно може ухилятися, запускати шипи тощо, як поспішаюча атака. Якщо ви хочете, щоб ці додаткові звернення були через регулярний інтервал, вкажіть систему ppm.


1

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

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

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

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


0

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

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

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

Ось практичний приклад. Подумайте про збитки в частині одиниць DPS або активного часу бою. 50% шансу до критики, при 1 атаці в секунду = (приблизно) 50% критичного удару за ударну одиницю DPS. 50% шансу до критики, з 2 атаками в секунду = (приблизно) 100% критичного удару за ударну одиницю DPS.

Ні, другий приклад дає 75% шансів принаймні на 1 критичний удар за секунду. Однак це дає в середньому 1 критичний удар за секунду. Це різні речі!


Правильно. Мені відомо про середній шанс у другому прикладі, моє значення - швидкість, як ви розумієте, що це 1 критерій в секунду. Вони різні речі, і це сенс аналізу між випадковістю та швидкістю. Коли ви дивитесь одиниці шкоди за секунду, 100% -ова норма є точним припущенням, це в основному таке саме, як ви сказали: в середньому 1 критичний удар в секунду.
robphill

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

Частково. Я блукав, чи були приклади зменшення випадкових випадкових випадків із точно такою ж частотою. Зокрема, я ніколи цього не бачив на практиці, і не впевнений, чи є це більш "веселою" системою для гравця, на відміну від системи обмеження. Однак я думаю, що розбиття критичної специфіки в категорії ігор у всіх власних є цікавим геймплеєм. Як і в, архетип "вбивці" має властивість критично важливий, тоді як архетип мага чи воїна - ні. Я шукаю щось в прямому ефірі, а не конкретно для прототипу / доказу концепції чи проектної документації.
robphill

Я не розумію, що ви маєте на увазі під "зменшенням випадкового шансу з точно такою ж частотою". Якщо ви припускаєте, що шанс «критичної» події може бути зроблений за секунду, а не за потрапляння, тому прискорення ударів також не вплине на критичні, тоді, звичайно, це може бути легко. Щодо того, чи було б веселіше, ніхто ще не придумав "Фунометра".
Килотан

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

0

Замість того, щоб дарувати лише бонус за рівний + критичний шанс, ви можете прийняти статистику, яка визначає ваш критичний шанс. Зазвичай це входить в точність / спритність / спритність, залежно від гри. Для точності потрібні більше та більше статистичних очок, щоб отримати більше шансів на критику, коли ви зробите вище, тож у певний момент рентабельність інвестицій настільки низька, було б краще інвестувати в іншу статистику (як правило, силу), щоб збільшити ваша шкода.

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

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

намагайтеся зберегти здібності підвищення шкоди в різних лініях атрибутів: критичний шанс, збиток від атаки, критичний збиток та IAS ніколи не повинні знаходитися в одній лінії. (ІМХО, я б не ставив IAS в статичну лінію, оскільки він, як ви вказували, має потенціал зробити інші речі надмірними).


0

Більш високе значення поспіху не обов'язково повинно відображати більшу кількість критичних звернень. Багато ігор використовують дві різні статистичні дані для обчислень - базову статистику та модифікатори. (D&D - прекрасний приклад). Чому б не обчислити критичні удари на основі статистики поспіху, але все ж відобразити критичний шанс? Наприклад, символ першого рівня має немодифіковану базову поспішність 1. Він б'є один раз в секунду. Раз на секунду у нього є розрахунок, який дає йому шанс критично вдарити. Тоді персонаж рівняється до 2. Тепер він має рівень поспіху 2, що дозволяє йому атакувати двічі на секунду. Критичний шанс все ще розраховується на базі поспіху, який дорівнює 1, що дозволяє йому лише отримувати максимум 1 критичний удар за секунду. Це маршрут, яким проходять деякі ігри, і часто це не так просто, як я описав, але це " s над чим подумати. Це залежить від гри, ситуацій та основної механіки.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.