Навіщо розміщувати конфігурацію сутності за межами скриптів?


11

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

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


@ Крістофер Ларсен відповідь: Занадто довго, щоб залишити коментар

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

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

Базовий предметний клас:

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

Підхід до сценарію:

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

Підхід JSON:

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

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

Відповіді:


13

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


Цього можна досягти, просто маючи два файли (рівнозначні .h, а потім .cpp). Мені цікаво, хто б був людиною, яка хотіла б створити об'єкт (окрім того, що сказати, що це робити - нічого не схоже на вазу, і що робити - нічого не схоже на метелика), який також не хотів би додати до нього певну логіку (наприклад, якщо людина, покрита пилком з квітів у вазі, залучайте метелика). Читання людини - це чудово, і одна з моїх думок про те, чому це так, але я знову переконую, що таблиці JSON, Lua та XML мають подібний рівень читабельності людини непрограмістами.
Джеймс

2
Glest - гра, модифікована xml. Багато непрограмістів роблять моди для цього. Безумовно, доступніше мати xml / json, ніж сценарій.
Буде чи

6

Одна з причин, для якої я зазвичай використовую конфігураційний файл, а не скрипт, це:

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

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


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

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

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

2

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


1

Описаний вами шаблон - це реалізація системи, керованої даними.

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

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

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

Візьмемо для прикладу стеротипну сутність "орк" ...

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

  • maxhealth = 10
  • збиток = 3 пошкодження в секунду
  • втікач = правда
  • втікач = здоров'я <10
  • агресивний = правда

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

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

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

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


2
Сценарії також дані по більшості визначень
Will

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

@Christopher Я додав довгу відповідь у своєму ОП. Будь ласка, перевірте це.
Пол Манта

0

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

Торкатися того, чому люди вирішують це робити зазвичай у XML, а потім у логічному сценарії, - це має сенс, коли ви це говорите. Ось моє визначення об’єкта в даних, що таке хороший формат зберігання даних? Це майже завжди XML (хоча я також йду з JSON;). І тоді, коли вони хочуть додати логіку, добре, що це або закодовано, або поміщено у файл сценарію.

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

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