Движок игры: достойный способ, с точки зрения архитектуры, реализовать поддержку сценариев?

Я разрабатываю простой игровой движок (в C #, если это имеет значение), и я не могу придумать достаточно приличный способ реализации сценариев с точки зрения архитектуры.

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

И дело в том, что мне бы очень хотелось, чтобы скрипты влияли как на вещи, связанные с игровой логикой (изменение параметров юнитов и т. Д.), Так и на вещи, связанные с видом на игру, такие как специальные анимации / диалоги для сражений, которые могут зависеть от определенный сценарий триггера.

(Честно говоря, в идеале я хочу, чтобы скрипт контролировал ход игры, оставляя только основную механику / графику для логики / представления, но я новичок в этом, поэтому я не уверен, что смогу сделать это прямо сейчас)

Я думал о трех вариантах:

• Просто дайте сценариям жить в логике, но дайте знать о графической стороне игры. Но это сделало бы разделение логики / представления очень расплывчатым, не так ли ...

• Сделайте сценарий отдельным модулем, который будет обмениваться событиями с другими, используя тот же менеджер событий. Но это потребовало бы быть очень осторожным с синхронизацией событий, я думаю ... и также добавить колоссальное количество типов событий к менеджеру. (Все же личный фаворит)

• Прежде всего, сделайте сценарий модулем, чтобы он мог напрямую влиять / вызывать функции логики / представления. Это позволяет существенно расширить функциональные возможности за счет того, что они напортачат на всю схему обмена событиями и боятся, что сценарий может что-то сломать, даже если это действительно не нужно.

Итак, я не могу ни выбрать один из них, ни придумать лучший способ вставить модуль сценариев ... Есть предложения или полезные ссылки?

Спасибо!

Ps спасибо за перенос вопроса, не знал, что есть специальный раздел для gamedev

Я полагаю, что вам нужен третий вариант, но вы поймете, что вы правы, считая, что логические события, происходящие в двух местах, - это плохо. Вы обнаружите, что хотите, чтобы логический модуль движка стал тиком обновления, который задает два вопроса «Что мне теперь делать?» и "Как мне это сделать?" с которыми вы можете затем связать сценарии для обработки ответов на эти вопросы.

Сопоставьте это с предоставлением объектам, которые содержат данные и API, доступа к необходимым компонентам логики (я имею в виду, что вы можете написать сценарий поиска пути AI, но поскольку это общий фрагмент кода, который, вероятно, будет использоваться и использоваться повторно, почему бы и нет встроить его в модуль, а затем добавить его в API, представленный на языке сценариев?). Это должно дать вам доступ, а также четко определенные места, где что-то происходит.

Опять же, я предупреждаю об этом тем же утверждением, что и всегда. Готовый рабочий продукт всегда ценнее хорошей теории в программировании :)

Надеюсь это поможет!

Многие склонны недооценивать силу динамических языков, думая, что такая гибкость достигается ценой скорости; Это правда, но часто стоимость просто ничтожна.

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

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

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

Вы можете инкапсулировать интерфейс, с которым вы можете работать, используя шаблон Façade. В методы фасада вы можете поместить логику, которая определяет, как , когда , если сценарий может использовать функциональность и абстрагирование взаимодействия сценария от базовой реализации.

Ваш интерфейс скрипта должен предоставлять соответствующие фабричные методы, чтобы скрипт мог генерировать элементы, не создавая их экземпляры напрямую; эти экземпляры могут быть обертками над реальными объектами, так что может быть реализована дополнительная логика управления доступом.

Объект сценария должен иметь доступ к другим объектам, для которых он будет предоставлять данные. Будьте осторожны, чтобы не передавать эти другие объекты непосредственно в объект сценария. Это создает хрупкий интерфейс. Возможно, вы захотите иметь что-то вроде класса-посредника, который управляет этими объектными ссылками и обеспечивает доступ к данным объекта сценариев.

Lua - популярный выбор для скриптового языка общего назначения. Вы можете создать свой собственный язык сценариев, используя Lex и Yacc (см. Статью в Gem 3 по программированию игр), но я бы сказал, что большинство ваших потребностей можно решить с помощью Lua, независимо от его размера.