Наскільки сильно повинен одноігровий движок відхиляти недійсні дані?

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

• Чи повинен двигун пропустити цей компонент і дозволити суб'єкту жити в ігровому світі лише з добре написаними компонентами?
• Або він взагалі не повинен додавати сутність у світ, якщо одна із складових непрацює?

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

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

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

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

Тож ваша демонстрація не готова до 2:00, і ваші інвестори задаються питанням, чому ви навіть не можете отримати єдиного ворога в грі, і ваш проект закривається.

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

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

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

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

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

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

void setValue(int value) {
    if (value < MIN_VALUE) {
       log(value + " is too low, using " + MIN_VALUE);
       value = MIN_VALUE;
    }
    if (value > MAX_VALUE) {
       log(value + " is too high, using " + MAX_VALUE);
       value = MAX_VALUE;
    }
}

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

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