Чи варто реалізовувати ігрову механіку / правила окремо від основного коду?

Не впевнений, чи підходить він до сфери цієї спільноти, чи слід замість цього перейти до Stackoverflow.

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

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

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

FYI: моєю мовою вибору коду утиліти буде Python 3.x

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

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

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

Про що я думав - чи можливо / доцільно якось реалізувати ігрову механіку окремо від основного утилітного коду?

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

Із пов'язаної статті:

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

У багатьох іграх використовується Lua. (Я б посилався, але репутація нового користувача обмежує кількість моїх посилань.)

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

Я бачив, як сценарії Lua визначають властивості ігрових одиниць. Ось випадковий приклад з TA Spring.

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

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

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

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

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

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

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

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

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

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

Це, безумовно, можливо. Якщо це варто, це залежить від ваших цілей.

Вам не потрібно вигадувати власну мову або писати компілятор, щоб зробити цю роботу.

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

Вам, мабуть, більше роботи, принаймні за короткий термін, створити зрозумілі системи та зробити їх легко модифікувати.

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

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

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

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

Можливо, ви захочете заглянути в об'єктно-орієнтований дизайн . Python має гарну підтримку для цього.

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

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

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

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

Підкласифікація: і зброя, і зброя - це обладнання. Обладнання є предметами. Напевно, є й інші типи предметів. Напевно, вам буде корисно визначити клас Комбатант, для якого і гравці, і монстри є підкласами.

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

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

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

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

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

Наприклад:

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

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

Тепер, який об’єкт відповідає за що?

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

Якщо ви ніколи не називаєте об'єкт (наприклад, Map), цей об'єкт не може змінити атаку жодним чином.

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

Удачі!

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

Наприклад, ви згадали настільні ігри; якби у вас була гра на базі науково-дослідної роботи, у вас може бути weapon_damageфайл, що містить такі рядки Battleaxe: 1d12. Ваш код утиліти читатиме цей файл і кожного разу, коли Battleaxeваш код буде заподіяний кодом, generate a number from 1-12, 1 time(s)додав би їх. Налаштування рядка для читання Battleaxe: 4d6замість цього generate a number from 1-6, 4 time(s)додасть їх. Так само ви можете мати папку, Creaturesі всередині вас є файл для кожної істоти, включаючи рядки типу AC: 12; то додавання нових файлів у цю папку створюватиме нові істоти. Це навіть можна зробити для класів персонажів, типів місцевості, тонни речей.

Цей стиль налаштування без коду все ще може бути дуже потужним і охоплювати багато частин вашої гри. Однак це насправді не дозволяє користувачеві вносити зміни, які ви чітко не вказали. Наприклад, ви Sneak Attack: [damage]можете дати можливість будь-якій істоті чи класу додати [damage]до будь-якої атаки, яка відповідає умовам атаки Sneak. Ви навіть можете запропонувати способи змінити такі умови, як, наприклад, "всякий раз, коли ви атакуєте з прихованості" або "коли ви перебуваєте у фланзі" або "коли ви маєте перевагу". Однак, якщо користувач вирішив, що вони хочуть, щоб атаки підкрадача були "Коли ви робите атаку, ви можете також відмовитись від сприйняття цілі. Якщо обидва рулони досягли успіху, тоді додайте збиток атаки Sneak".

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

[Я десятиліття розробника програмного забезпечення, але не маю досвіду розробки ігор, тому, можливо, ігрова індустрія використовує різні підходи, можливо, з поважних причин ...]

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

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

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

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