Лучший способ управлять такими вещами, как пули в игре?

Question

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

Каждый объект должен управлять своими маркерами, должен ли у меня быть глобальный диспетчер маркеров или я должен создавать каждый маркер как новый полноценный отдельный объект (хотя это кажется довольно неэффективным)?

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

Простите, это, вероятно, просто, но я хочу убедиться, что я думаю в правильном направлении.

Большое спасибо!

Answer 1

Оригинальный Quake использует пул фиксированного размера для сущностей (которые также иногда называют эдиктами). Все, чье существование сохраняется между кадрами, является сущностью. Это включает в себя «физически сформированные» вещи, такие как мир и двери, прямоугольные физические вещи, такие как монстры, игроки и гвозди, прозрачные движущиеся объекты, такие как оружие, невидимые, но осязаемые прямоугольные вещи, такие как триггерные поля, и совершенно нефизические вещи, такие как события задержки. 1001 *

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

Answer 2

Создание каждой пули как «полностью унесенного объекта» не должно быть слишком неэффективным - взгляните на шаблон пула объектов , в котором описан способ ускорения создания этих объектов.1004 * Что касается вашего вопроса о компонентах и ​​общих свойствах, это зависит от того, насколько строго вы хотите следовать архитектуре компонентов.Если вы хотите быть очень строгими с архитектурой компонента, каждое свойство должно быть в компоненте, а разные компоненты должны общаться друг с другом.В противном случае, из соображений эффективности, разделите некоторые свойства основного объекта.Для получения дополнительной информации посмотрите эту страницу на поведенческом паттерне компонента.