Я пишу фреймворк ECS, а также игру с ним на Python. В структуре ECS компоненты должны содержать только данные. Однако иногда для создания данных требуется код настройки. Например, в аудиокомпоненте данные будут представлять собой громкость звука для воспроизведения и путь к аудиофайлу. Но в библиотеке воспроизведения звука есть объекты для представления звуков, например, у которых есть метод sound.play(). Мой вопрос в том, должен ли этот объект создаваться в компоненте, который как бы нарушает правило, согласно которому сущности должны быть чистыми данными, или в системе. Если это лучше всего сделать в системе, это нужно будет сделать только один раз (и это нанесет ущерб производительности, если аудиофайл нужно будет создавать один раз для каждого кадра). Как лучше всего это сделать?
Как следует обрабатывать установочный код в entity-component-system?
Ответы (1)
Мой вопрос в том, должен ли этот объект создаваться в компоненте, который как бы нарушает правило, согласно которому сущности должны быть чистыми данными, или в системе. Если это лучше всего сделать в системе, это нужно будет сделать только один раз (и это нанесет ущерб производительности, если аудиофайл нужно будет создавать один раз для каждого кадра). Как лучше всего это сделать?
Когда вы используете модель outboard для системы сущностей, я думаю, что одной из наиболее важных задач, которую необходимо решить, является управление жизненным циклом как сущностей, так и компонентов. Без этого становится действительно сложно написать системный код, который не начинал бы напоминать спагетти.
Существуют реализации, в которых они ожидают, что вы создадите объект, создадите его список компонентов, а затем активируете объект. После активации объекта вы не можете добавлять или удалять компоненты, а только изменять значения атрибутов компонента. Чтобы добавить / удалить компоненты, вы деактивируете объект, вносите изменения, а затем повторно активируете его.
Предположим, мы используем этот процесс жизненного цикла сущности.
Когда объект с аудиокомпонентом активируется, аудиосистема получает уведомление, считывает атрибуты из аудиокомпонента и, наконец, создает звуковой объект аудиосистемы. В этом случае ответственность за ведение бухгалтерской карты между компонентом и звуковым объектом будет лежать в основе системы. Эта внутренняя карта - это то, что система будет использовать для каждого кадра для обновления.
Когда объект с аудиокомпонентом деактивирован, аудиосистема получает уведомление, уничтожает звуковой объект аудиосистемы, связанный с компонентом на внутренней карте бухгалтерского учета, а затем удаляет запись из внутренней карты.
