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

Ми займаємося пошуком, а не ітераціями

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

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

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

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

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

Через існування цієї темної кімнати ми і виконуємо «ітерації» — нам невідомо, якими будуть наслідки рішень, поки ми їх не перевіримо. Іншими словами, ми знаходимося в пошуку (Уїлл Райт у своїй доповіді на GDC 2004 назвав це «пошуком в просторі рішень»).

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

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

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

Ця серія статей

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

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

Незважаючи на всі свої потенційні переваги, моделювання та оптимізація рішень, схоже, досить незвідана тема для дизайнерів в ігровій індустрії. Опитування професійних дизайнерів на популярному форумі розробників показав, що лише 25% респондентів хоча б чули про моделюванні рішень (decision modeling), і лише 8% використовували його на практиці. Схоже опитування, проведене серед дизайнерів через Facebook, показав приблизно такі ж результати при схожому кількості респондентів.


При правильному використанні моделювання рішень може значно поліпшити безліч аспектів процесу дизайну:

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

У цій серії статей я розповім про приклади з усіх трьох категорій використання.

Визначення

Що ж таке «моделювання рішень»?

Якщо говорити просто, то:

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

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

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

Навіщо будувати моделі?

Якщо ви грали у Sid meier’s Civilization, то напевно коли-небудь задавалися питанням: «Стривай-но, як правильніше починати розвиток міста? Треба спочатку побудувати монумент, а потім склад? Або склад потрібен першим? А може спочатку храм, а потім вже склад? Яке рішення краще прийняти? Чи можна взагалі відповісти на це питання?»

Також можна згадати механіку бою в стратегії реального часу. Балансування параметрів безлічі юнітів в RTS — завдання, сумно відома своєю складністю. Що, якщо б у нас була система, що дозволяє прискорити рішення завдання балансування, відповідаючи на питання про балансування бою гри без плейтестинга кожного рішення? Що, якщо б ми могли задавати системі питання? Наприклад: «скільки мечников потрібно, щоб перемогти двох пикейщиков і трьох лучників?» Або: «яка найбільш дешева комбінація лучників і катапульт може перемогти ворожу сторожову вежу?»

Насправді, таку систему можна створити!

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

Ось приклад схожої завдання — приклад, який ми вирішимо майбутньої статті серії.

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


У нас є 100 кредитів, які можна витратити на спорядження. Супертанк гравця може нести на собі 50 тонн зброї, а також має 3 «критичних» слота під спеціальне високопотужне озброєння.

У грі є п’ять таких типів зброї, і гравець може використовувати будь-яку кількість кожного типу, або повністю відмовитися від нього:


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

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

Спробуйте вирішити задачу вручну або за допомогою калькулятора.

Чи можна це зробити?

Якщо спробуєте, то швидко переконаєтеся, що це напрочуд складне завдання.

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

Подумайте, як зміниться відповідь при інших параметрах. Чи зміниться відповідь, якщо замість 50 тонн супертанк зможе вмістити 60? Або якщо замість 100 кредитів у нас буде 110 або 90? Як зміниться оптимальний спорядження? А якщо у нас буде 2 або 4 критичних слоти?

А тепер уявіть, що у нас є система, яка миттєво обчислює схему розміщення зброї з найбільшою втратою для будь-якого безлічі параметрів (Вага, Ціна, Критичні слоти). Досить ввести параметри зброї з таблиці, потім ввести параметри супертанка (50 тонн, 100 кредитів, 3 критичних слоти) — і БУМ! — ми отримали найкраще спорядження.

Хіба не було б чудово?

Ми могли б використовувати цю систему для миттєвого отримання відповіді на всілякі корисні питання:

  • Як буде змінюватися оптимальна схема при зміні параметрів супертанка?
  • Як зміниться оптимальний спорядження при зміні параметрів зброї?
  • Який максимальний шкоди може завдавати супертанк при будь-яких заданих параметрах (Вага, Ціна, Критичні слоти)?
  • Є всі чотири параметри зброї (Шкоди, Вага, Ціна, Критичні слоти) відповідним і збалансованим для кожного виду зброї?
  • Чи є у нас занадто потужні гармати, які використовуються дуже часто? Якщо якийсь із видів зброї настільки корисний, що завжди правильно використовувати його, то вона завжди буде оптимальним рішенням, тому значущого вибору тут не буде. В такому разі нам варто або прибрати зброю з гри, або змінити його баланс так, щоб у певних умовах воно не було корисним.
  • Чи є у нас рідко або ніколи не використовувані види зброї? Аналогічно до попереднього пункту — якщо якийсь вид зброї так марний, що правильним рішенням є ніколи його не використовувати, то тут теж немає значущого вибору. У такому випадку варто або видалити зброю з гри, або змінити його баланс, щоб у певних умовах було розумно його використовувати.
Читайте також  Фахівці з кібербезпеки створили детектор скімерів — SkimReaper

Все це дуже важливі питання дизайну, відповіді на які повинен хотіти знати будь-який дизайнер. Знання цих відповідей буде неймовірно корисно при балансуванні гри SuperTank.

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

У майбутньої статті ми побудуємо справжню модель рішень для прикладу, яка відповість на всі перелічені питання.

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

Дорожня карта

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

  • Простий приклад бою для стратегічної гри
  • Модель для оптимізації координат декількох телепорт-«червоточини» щодо один одного і населених секторів в космічній масової багатокористувацької грі (MMO)
  • Модель, що визначає рівень податків для спрощеної моделі міста, щоб врівноважити достаток жителів і надходження податків в 4X-стратегії зразок Sid meier’s Civilization
  • Модель вибору заклинання і навичок для класів персонажів в масивній багатокористувацької грі
  • Модель оптимізації для визначення оптимального порядку будівництва планетарної колонії в 4X-стратегії зразок класичної Master of Orion
  • Приклад команди, яка намагається підібрати правильну комбінацію «фіч» для гри, і модель рішень, допомагає їм вибрати відповідні компроміси

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

У кожному з цих випадків ми опишемо завдання, покажемо як змоделювати її в Excel і вирішити її за допомогою вбудованого інструменту Solver (у російській версії — «Пошук рішень») з Excel. У кожному разі ви побачите, що ми можемо зробити це простіше, швидше і надійніше, ніж без застосування Solver або аналогічного інструменту. Також для кожного прикладу я додам електронні таблиці, щоб ви могли завантажити їх і перевірити самостійно, відтворити результати і поекспериментувати з власними моделями.

Крім того, не забувайте, що внутрішнє подання — будь то електронна таблиця, програма на мові високого рівня, або щось ще — неважливо. Важливо не те, чим ми працюємо — в Excel Solver, Java/C++/C#, або в чомусь ще, а те, що ми моделюємо завдання і намагаємося її вирішити.

Навіщо використовувати моделі рішень?

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

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

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

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

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

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

Але у дизайнерів таких інструментів немає. Можна сказати, що наша робота так само складна, але у нас немає компілятора, який би сказав нам, що ми «зробили синтаксичну помилку». У нас немає ні профайлера, ні інструментів налагодження, ні інструментів статичного аналізу. Ми не може проводити рев’ю коду, тому що у нас немає ніякого «коду». Ми пишемо специфікації та дизайн-документи, і на цьому все; ми можемо обмінюватися діз-доками і специфікаціями функцій всередині команди і сподіватися, що колеги дадуть нам хороший зворотний зв’язок, але найчастіше нам потрібно помістити систему в гру, щоб зрозуміти, працює вона чи ні.

Це робить дизайн неймовірно ризикованим, довгим і дорогим заняттям.

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

Ми ще дуже далеко від володіння повноцінними дизайнерськими інструментами, що допомагають дизайнерам в дослідженні простору дизайну. Нам ще потрібно пройти шлях, який зробили компілятори, відладчики, профайлери та інструменти статичного аналізу в програмуванні. Але ми вже бачимо світанок декількох специфічних солверов та інструментів дизайну ігор, у тому числі тестувальника іграбельності версії Cut the Rope під назвою Cut the Rope: Play Forever (посилання); абстрактної системи дизайну ігор Ludi, яка згенерувала настільну гру Yavalath (посилання); і мого власного автоматизованого помічника Evolver для балансування мобільної гри City Conquest (посилання).

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

Головне — не електронні таблиці, головне — це моделі

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

  • Ніякого коду. У статтях не буде абсолютно ніякого коду і ми будемо ілюструвати всі приклади в Microsoft Excel за допомогою вбудованого інструменту Solver (Пошук рішення»). Однак важливо помітити, що ця серія не про електронних таблицях чи Excel, а про моделювання та оптимізацію рішень. Кожен крок, який ми зробимо в цій серії, можна так само просто (а іноді і ще простіше) виконати на будь-якій мові високого рівня.

 

  • Ніякої математики (або, принаймні, нічого складного). Ми прагнемо зробити цю серію вільної від математики і не будемо використовувати нічого, крім найпростіших арифметичних операцій: додавання, віднімання, множення, ділення і іноді обчислення квадратного кореня. Грецькі букви будуть під суворою забороною.

 

  • Жодних чотиривимірних електронних таблиць; ми будемо користуватися тільки двомірними.

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

Ці статті повинні стати лише відправною точкою, щоб ви могли взяти представлені тут концепції і обрати самостійно: реалізувати їх в Excel, вибрати інший інструмент оптимізації, або спробувати побудувати власний солвер на мові високого рівня. Електронні таблиці — це надійний фундамент для початку, але такі моделі рішень найімовірніше стануть вашим трампліном до більш багатим і складним моделям, интегрируемым в архітектуру вашої гри.

Пояснення

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

Ось деякі з обмежень, про які вам потрібно знати:

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

 

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

 

  • Змоделювати можна не все. Моделі рішень не можуть повідомити вам, чи що захоплюючим, естетично приємним, «правильним» або дає користувачеві зручний і доступний інтерфейс. Немає загального способу подання таких суб’єктивних і естетичних аспектів у вигляді дискретної моделі. Це означає, що є чіткі межі використання моделювання рішень, і що вони набагато корисніше для дизайну систем і оптимізації механік/динаміки, ніж для естетики.
Читайте також  Деякі завдання шкільної математики

 

  • Вони мають обмеження. Всі оптимізатори мають свої обмеження, в тому числі і вживаний нами Excel Solver, і цілком можливо створити моделі рішень, що мають правильні рішення, але при цьому настільки складні, що ніякої інструмент оптимізації не зможе їх знайти. У разі досить великих необмежених вхідних значень завдання може перерости здібності Solver в пошуку кожної можливої комбінації вхідних значень, і замість цього йому доведеться покластися на різні способи оптимізації. Як ми побачимо в цій серії статей, можна спрощувати вирази моделей, щоб «Пошуку рішень» було простіше їх обробляти. Розробник Solver (Frontline) пропонує більш потужний солвер для більш об’ємних завдань, але абсолютно точно можна створити моделі, які Solver вирішити нездатний.

 

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

Останнє і найважливіше:

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

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

У випадках, коли існують суб’єктивні аспекти, які неможливо вмонтувати в цю модель, наприклад, естетичні аспекти або аспекти usability/іграбельності, нам потрібно або чітко відокремити їх від моделі рішень, або використовувати моделювання рішень як перший прохід, або просто повністю відмовитися від моделювання рішень.

Щоб ми могли моделювати рішення в електронній таблиці, треба також обмежити складність моделі. Якщо наша гра виконує щось дуже складне, нам, можливо, і не вдасться відтворити цю складність в Excel. Однак необхідно враховувати, що це обмеження тільки потужності моделей, які можна побудувати в Excel, а не самих моделей рішень. У власному ігровому движку ми можемо будувати набагато більш потужні солверы, і я сподіваюся, що дана серія статей надихне вас саме на це.

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

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

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

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

Висновок

Зрештою, ми хочемо створювати дизайн правильно.

Багато питань дизайну суб’єктивні, у них немає «правильних» або «неправильних» відповідей. Але в деяких випадках вони безсумнівно є. І в таких випадках ми повинні знати, як знайти правильну відповідь, або принаймні зрозуміти, як взятися за визначення «правильного» відповіді і шукати, чи є його рішення.

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

Частина 2. Основи оптимізації і розгортання симуляції

Електронну таблицю для цієї статті можна завантажити тут.

Підготовка моделі рішень

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

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

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

  • Рішення — ці клітинки містять змінні, які ми намагаємося оптимізувати — іншими словами, ми змусимо оптимізатор спробувати знайти найкращі значення для цих комірок. У цих осередках ми можемо почати з 0 або якогось іншого прийнятного значення за промовчанням, а потім змусити оптимізатор вставити правильні значення. У більшості випадків ми також обмежимо їх певним інтервалом, наприклад мінімальним і максимальним значеннями, а в деяких випадках цілими або двійковими значеннями. Заради узгодженості та зручності читання осередку рішень завжди будуть жовтими і мати чорну рамку.
  • «Задане значення» — значення цих осередків вказуються безпосередньо в умовах завдання. Наприклад, якщо завдання каже нам, що льодяник Tootsie Pop важить 17 грам і кожен раз ми слизываем з нього 0,25 грам, то ці дві комірки будуть «заданими значеннями». Такі осередки ми позначимо синім.
  • «Обчислення» — значення цих осередків обчислюються з інших клітинок електронної таблиці, які не підпадають під жодні інші категорії. Ми зробимо їх сірими.
  • «Мета» (або «вихід») — це комірка, значення якої ми прагнемо мінімізувати (або максимізувати) при виконанні оптимізатора. У наших прикладах завжди буде тільки одна комірка мети, вона завжди має помаранчевий колір і чорний контур. (Примітка: існують більш потужні солверы, що підтримують роботу з декількома цілями, але для наших статей це буде занадто складно.)

Коли ми запустимо оптимізатор (інструмент Solver («Пошук рішень»), вбудований в Microsoft Excel), він просто подивиться на вказану нами клітинку цілі, а потім спробує змінювати змінні рішень, однак він може (в межах заданих нами обмежень) або мінімізувати або максимізувати значення цієї клітинки мети (будь, яку ми вкажемо).

Solver майже нічого не знає про обчисленнях, що відбуваються всередині, або про зв’язки між осередками рішень і осередками цілей; він просто виконує один з декількох доступних йому алгоритмів, намагаючись мінімізувати або максимізувати значення клітинки мети за допомогою пошуку можливих значень комірок рішень. Такі алгоритми («Simplex LP», «GRG Nonlinear», «Evolutionary») спроектовані так, що вони набагато розумніші дослідження всіх можливих варіантів змінних рішень грубим перебором, і дуже часто знаходять відповіді на серйозні завдання з дивовижною ефективністю.

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


Ми можемо попросити Excel Solver вирішити цю задачу, наказавши йому мінімізувати клітинку мети «Mass remaining on Tootsie Pop» («маса залишилася Tootsie Pop»), і він би швидко з допомогою експериментів визначив би, що значення жовтої осередку рішення, дає такий результат («Скільки раз лизнути, щоб дістатися до середини Tootsie Pop») дорівнює 68.

Зрозуміло, що так робити трохи нерозумно, тому що з постановки задачі зрозуміло, що відповідь буде 17/0,25=68. Немає сенсу запускати оптимізатор для вирішення завдання, яке можна вирішити простою арифметикою.

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

Ми зосередимося на описі завдань, а всю складну роботу залишимо Solver.

Приклад 1: податки

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

Уявіть, що ми створюємо 4X-стратегію, схожу на Sid meier’s Civilization. Ми знаходимося в процесі створення міст, які мають певний рівень невдоволення, що залежить від їх розміру. «Незадоволені» жителі по суті не налаштовані на співпрацю, і ми не отримуємо від них доходів. Також ми можемо спробувати отримати гроші з міст, змінюючи податкову ставку кожного міста, але при збільшенні податкової ставки рівень незадоволеності буде рости експоненціально, тому дуже високі податки стають контрпродуктивними.

Припустимо також, що ми можемо вказувати податкову ставку з інкрементом 10% в інтервалі значень від 0% до 50%. Ось скріншот, на якому показана схожа система з класичної 4X-стратегії Master of Orion 2:


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

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

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

Давайте почнемо з того, що опишемо завдання наступним чином:

  • У нас є місто розміром 12 (що позначає 12 мільйонів людей). Ці люди представлені як 12 окремих громадян».
  • Кожен громадянин в будь-який момент часу може бути задоволений або незадоволений.
  • Задоволені громадяни сплачують у вигляді податків (податкову ставку x 10) (тобто, наприклад, податкова ставка 20% дає нам 2 одиниці валюти у податкових доходах на кожного задоволеного громадянина).
  • Незадоволені громадяни не платять податків.
  • У місті є 3 незадоволених громадян, які залишаються незадоволеними незалежно від податкової ставки.
  • Додаткове кількість громадян стає незадоволеним на підставі наступної формули: (Населення) x ((Податкова ставка) x (Податкова ставка)) x 3.5, значення округлюється до найближчого цілого числа. Для нашого міста розміром 12, це дасть нам 0 додаткових незадоволених громадян при ставки 0% і 10%, 1 незадоволеного додаткового громадянина за ставкою 20%, 3 додаткових незадоволених громадян за ставкою 30%, 6 — за ставкою 40%, і 10 — за ставкою 50%.
Читайте також  Записки IoT-провайдера. Трохи про частоти

Все просто, правда?

Ми опишемо це в прикріпленою до статті електронної таблиці наступним чином:


Ви можете помітити, що ми задаємо жовту клітинку рішення (Tax Level (0-5)) як непрямий спосіб визначення податкової ставки. Замість вказівки податкової ставки безпосередньо в комірці рішення, осередок обчислень Tax Rate бере число Tax Level осередку рішення і множить його на 10%. Є логічна причина робити це опосередковано, і ми це побачимо.

Тепер ми можемо експериментувати і підставити всі можливі значення рівня податків. Можна просто ввести в комірку Tax Level кожну з цифр від 0 до 5, і отримати наступне:


Як бачите, існує оптимальне значення податкової ставки: 30%, яке максимізує дохід від податків, даючи 18 одиниць валюти.

Давайте автоматизуємо систему!

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

Як ми побачимо, саме для цього і використовується Solver.

Для початку ми скинемо значення клітинки Tax Level до нуля. Потім перейдемо на вкладку Data («Дані») Excel і побачимо в правій частині стрічки, в розділі Analysis («Аналіз»), кнопку Solver (Пошук рішення»).


Якщо ви її не бачите, то зайдіть в Options (Параметри») Excel, виберіть категорію Add-Ins («Надбудови»), переконайтеся, що в списку Manage («Управління») обрано Excel Add-Ins («Надбудови Excel»), натисніть Go («Перейти…») і переконайтеся, що поставлено прапорець Solver Add-in («Пошук рішення»).

Після натискання на кнопку Solver (Пошук рішення») ви повинні побачити схоже діалогове вікно.


Давайте тепер розглянемо всі етапи налаштування діалогового вікна Solver.

У полі «Set Objective» («Оптимізувати цільову функцію») ми вкажемо те, що потрібно оптимізувати. В даному випадку ми намагаємося отримати якомога більший дохід від податків, тому виберемо помаранчеву клітинку мети, яка означає дохід від податків, а потім натиснемо на «To: Max» («До: Максимум») в списку радіокнопок.

В розділі «By Changing Variable Cells» («Изменяя ячейки змінних») виберемо клітинки, які «Пошук рішень» повинен обчислити. Нам потрібно визначити оптимальну податкову ставку, тому вибираємо жовту клітинку рішення (Tax Level (0-5)). Якщо все вийде правильно, то в результаті цієї комірці буде присвоєно значення 3, відповідна податковій ставці 30%, оптимальність якої ми вже визначили при обчисленнях вручну.

Нарешті, нам потрібно додати кілька обмежень. По суті, обмеження є умовами для будь-яких осередків нашої моделі рішень, і Excel Solver зосередиться тільки на тих рішеннях, які задовольняють зазначеним обмеженням. Такі обмеження можуть обмежувати певні осередки (зазвичай осередку рішень і осередки обчислень) заданими мінімальним і/або максимальним значеннями, та/або змушувати Solver обробляти їх як цілі або двійкові змінні (0 або 1). Обмеження неймовірно корисні для створення коректної моделі, якою буде обмежений.

Solver вимагає хоча б кілька обмежень, що дозволяють йому визначити межі клітинок рішень — іншими словами, мінімальне і максимальне значення для кожної комірки. Щоб додати обмеження, потрібно натиснути на кнопку Add («Додати») праворуч, після чого відкриється наступне діалогове вікно:


Ми додамо два обмеження, одне для того, щоб осередок рішення Tax Level задовольняла умові >=0, і ще одне, щоб осередок рішення була <= 5. Потім виберемо в списку Solving Method («Виберіть метод рішення») значення Evolutionary («Еволюційний пошук рішення») і натиснемо на Solve («Пошук рішення»).

Попрацювавши приблизно 30 секунд, Solver видасть нам подібний відповідь:


Ой-їй, виникала проблема. Solver отримав вірну суму доходу, але рівень податків неправильний. Гравець може задавати податки тільки з інкрементом в 10%, але Solver очевидно задає дробові податкові ставки, чого гравець зробити не зможе.

Вирішити проблему можна, обмеживши значення комірки податкової ставки тільки цілими числами. Воно може бути одно тільки 0, 1, 2, 3, 4 або 5, але без проміжних значень.

На щастя, в Solver цього можна досить легко домогтися. Відкрийте Solver, натисніть кнопку Add («Додати»), виберіть клітинку рішення Tax Level, а потім виберіть у розкривному списку посередині обмеження int («ціле»):


Тепер знову запустимо Solver і отримаємо наступне:


Ідеально! Приклавши незначні зусилля, ми отримали в Solver правильну відповідь. Як ми скоро побачимо, при збільшенні масштабу завдань обсяг виконуваної за нас інструментом роботи значно перевищує час, витрачений на його налаштування.

Зростаючий місто

Давайте тепер розширимо завдання, злегка ускладнивши модель міста.

У будь-4X-стратегії міста (або планети, або колонії, або інші населену одиниці) з часом зростають. Ми припустимо, що місто має постійний приріст на 8% за хід, починаючи з 1500 тисяч (1,5 мільйона) городян, і збільшуючись до розміру 12 мільйонів жителів. Тепер наша таблиця буде виглядати так:


Кожна нова наступний рядок таблиці описує один хід гри.

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

Як і раніше, ми можемо експериментувати з рівнями податків вручну, змінюючи значення Tax Level. Ми отримаємо 0, 102, 190, 222, 144 і 65 одиниць валюти в доходах від податків, при кожному з рівнів податків від 0% до 50%.

І ми знову можемо змусити Solver вирішувати цю задачу; він швидко визначить, що оптимальна податкова ставка як і раніше дорівнює 30%, що дає нам дохід у 222 одиниць валюти. Ось, як виглядає діалогове вікно Solver:

Змінні податкові ставки

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

Хіба не здорово буде, якщо ми зможемо не просто визначати єдину оптимальну податкову ставку, але й обчислювати оптимальне значення в кожному ході?

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

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

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


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


Solver і справді доводить, що зміна податкової ставки змінює результати — кумулятивний дохід тепер склав 232 одиниць валюти. Порівняно з однаковою податковою ставкою зростання становить всього 5% відсотків (222 проти 232 одиниць), але він все одно значущий, тому що ми знаємо, що деякі гравці зможуть його досягти.

Придивившись до отриманого Solver рішенням, можна побачити, що воно починається з податкової ставки 50%, тому що місто розміром 1 не містить достатньої кількості населення для генерації невдоволення. У процесі росту міста інструмент змінює в кожному ходу податкову ставку в інтервалі від 20% до 30%, залежно від того, яка з них принесе більший дохід.

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

Висновок

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

Така ситуація призводить до цікавого питання: чи цього ми хочемо? Примушує механіка гравців вважати, що для гри їм потрібно в кожному ходу займатися микроменеджментом рівнів податків? І хочемо ми допустити, щоб націлені на перемогу гравці (power gamers) могли обігравати систему таким чином; відповідає такий хитрощі одержуваний ними виграш у 5%?

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

Зрозуміло, ця модель — лише голий каркас. У реальному 4X-стратегії гравці можуть приймати різноманітні рішення про те, як розвивати місто, будувати будівлі і вносити інші зміни, що впливають на зростання міста, достаток, доходи від податків і продуктивність.

В одній з майбутніх статей циклу ми побудуємо схожу, але набагато більш складну модель цілої планетарної колонії в грі, нагадує Master of Orion 2. Цей приклад буде набагато витонченішим, тому що ми зможемо приймати в кожному ходу рішення, які будуть у подальшому впливати на всі ці параметри, такі як ріст і продуктивність, тобто кожне рішення буде мати наслідки, що впливають на наступні рішення. Проте ми все ж переконаємося, що еволюційний оптимізатор інструменту Solver здатний впоратися з цим завданням.

Степан Лютий

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

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *