Как следует обрабатывать код установки в системе компонентов-сущностей?
Я пишу фреймворк ECS, а также игру с ним на Python. В среде ECS компоненты должны содержать только данные. Однако иногда для создания данных требуется код установки. Например, в аудиокомпоненте данными будут громкость воспроизводимого звука и путь к аудиофайлу. Но в библиотеке воспроизведения аудио есть объекты для представления звуков, например, у которых есть метод sound.play(). Мой вопрос заключается в том, должен ли этот объект быть создан в компоненте, что нарушает правило, согласно которому сущности должны быть чистыми данными, или в системе. Если это лучше всего сделать в системе, это нужно будет сделать только один раз (и это ухудшит производительность, если аудиофайл нужно будет создавать один раз для каждого кадра). Как лучше всего это сделать?
Ответы 1
My question is whether this object should be created in the component, which sort of violates the rule that entities should be pure data, or in the system. If it should best be done in a system, it would only need to be done once (and it would harm performance if the audio file needed to be created once per frame). What is the best way to do this?
Когда вы используете модель подвесной для системы сущностей, я думаю, что одной из самых важных задач, которую необходимо решить, является управление жизненным циклом как сущностей, так и компонентов. Без него становится очень сложно писать системный код, который не начинает напоминать спагетти.
Существуют реализации, в которых ожидается, что вы создадите объект, создадите список его компонентов, а затем активируете объект. После того, как сущность активирована, вы не можете добавлять или удалять компоненты, а можете только изменять значения атрибутов компонента. Чтобы добавить/удалить компоненты, вы деактивируете объект, вносите изменения, а затем повторно активируете его.
Предположим, мы используем этот процесс жизненного цикла объекта.
Когда объект с аудиокомпонентом активируется, аудиосистема уведомляется, считывает атрибуты из аудиокомпонента и, наконец, создает звуковой объект аудиосистемы. В этом случае ответственностью системы будет поддерживать учетную карту между компонентом и звуковым объектом. Эта внутренняя карта — это то, что система будет использовать для каждого кадра для обновления.
Когда объект с аудиокомпонентом деактивируется, аудиосистема уведомляется, уничтожает звуковой объект аудиосистемы, связанный с компонентом во внутренней карте учета, а затем удаляет запись из внутренней карты.
Безусловно, но для сущностей, которые не очень часто меняются от фрейма к фрейму, есть вариант использования для создания сущности, добавления всех ее компонентов, а затем выполнения одной активации в системах для указанной сущности. Это намного быстрее, чем вызов каждой системы для этого объекта N раз.
Нельзя ли также реализовать это таким образом, чтобы можно было добавлять и удалять компоненты из сущностей, автоматически «активируя» и «деактивируя» сущность при изменении списка ее компонентов и, таким образом, автоматически уведомляя систему об изменениях?