Кодування різних станів у пригодницьких іграх

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

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

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

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

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

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

PS: У мене ще немає редактора рівнів - я думаю про те, щоб використовувати щось на зразок JME SDK або зробити свій власний.

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

Один приклад того, як виглядатиме інтерфейс стану (повністю складений - просто для ілюстрації рівня контролю, який дає вам ця схема):

interface NPCState {
    Scene whereAmI(NPC o);
    String saySomething(NPC o);
}

І два заняття:

class Busy implements NPCState {
    Scene whereAmI(NPC o) {
        return o.getWorkScene();
    }
    String saySomething(NPC o) {
        return "Can't talk now, I'm busy!";
    }
}

class Available implements NPCState {
    Scene whereAmI(NPC o) {
        return TAVERN;
    }
    String saySomething(NPC o) {
        String[] choices = o.getRandomChat();
        return choices[RANDOM.getInt(choices.length)];
    }
}

І перемикання станів:

// The time of day passed from "afternoon" to "evening"
NPCState available = new Available();
for ( NPC o : list ) {
    Scene oldScene = o.state.whereAmI(o);
    o.state = available;
    Scene newScene = o.state.whereAmI(o);
    moveGameObject(o, oldScene, newScene);
    ...

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

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

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

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

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

if (state in behaviors) {
  behaviors[state]();
}

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

Замість згаданої структури дизайну стану я використовував би стратегію.

Якщо npc має n способів взаємодії з персонажем та m позиціями, де він міг би бути, вам потрібно розробити максимум (m * n) +1 класів. Використовуючи шаблон стратегії, ви отримаєте n + m + 1 класи, але ці стратегії також можуть бути використані іншими npcs.

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

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

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

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

Однак, копії об'єкта, який ви створюєте вручну, не повинні викликати проблем. Скільки об’єктів ви можете створити? Якщо ви можете створити більше об'єктів, ніж ваша гра може зациклитися, подивіться на їх "приховане" властивість і пропустіть, ваш двигун занадто повільний. Тому я б не переживав про це занадто. Багато онлайн-ігри насправді роблять це. Певні символи або предмети завжди є, але не відображаються символам, які не мають відповідної місії.

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