Який належний рівень деталізації для архітектури на основі компонентів?

Я працюю над грою з компонентною архітектурою. У Entityвласності набір Componentпримірників, кожен з яких має набір Slotпримірників, з якими зберігати, надсилати та отримувати значення. Заводські функції, такі як Playerвиробляти об'єкти з необхідними компонентами та з'єднаннями слотів.

Я намагаюся визначити найкращий рівень деталізації деталей. Наприклад, зараз Position, Velocityі Accelerationвсі окремі компоненти з'єднані послідовно. Velocityі їх Accelerationможна легко переписати на рівномірний Deltaкомпонент, або Position, Velocityі їх Accelerationможна поєднувати поряд з такими компонентами, як Frictionі Gravityв монолітний Physicsкомпонент.

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

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

Очевидно, що речі можуть бути такими Position, але вони не обов'язково динамічні (так навіщо так Velocityі Acceleration?). Однак щось із a Velocityбуде рухомим об’єктом, тому має сенс також Accelerationзгрупуватися.

У вас буде випадок, коли v і a будуть потрібні, але ви не хочете, щоб фізичне моделювання для них? Аналогічно, чи буде сенс, Gravityякщо вони не є об'єктами фізики?

tl; dr. Група, що має сенс.

Щоб уникнути мікроменеджменту кожної змінної, я б запропонував, починаючи важко, вибирайте розділення на відповідальність та рефактор, коли ситуація представляється логічно. Перші конструкції можна починати на папері. В якийсь момент ці грубі розподіли відповідальності стануть складовими елементами ваших організацій.

Отже, для прискореного прикладу у вас є Game. Гра розбивається на навколишнє середовище + стан. Навколишнє середовище розбивається на StaticWorld + MovingStuff. Держава розбивається на AIContROL + PlayerContROL. Загальна ідея пошкодження розбивається на TakesDamage + GivesDamage.

І так далі.

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

Думаю, було б поєднувати компоненти, які матимуть багато взаємодії. У вашому випадку я б утримував позицію в одному компоненті, а швидкість і прискорення зберігалися разом у складі фізики.

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

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

Я вважаю, що Systemsце допоможе вам краще зрозуміти, як конструювати компоненти. Системи існують в архітектурах, де компоненти не містять власної логіки, окрім простих функцій getter / setters та helper. Системи працюють на об'єктах, які відповідають вимогам Компонента. Ось чому найкраще відокремлювати компоненти компонентів настільки, наскільки має сенс обробляти ці дані без інших даних.

Наприклад, у вас може з’явитися MovementSystemоновлення, яке оновлює його Суб’єкти Positionна основі їх Velocity. Це може бути для простих осіб у грі. Але для гравця та ворогів ви можете захотіти рух, Accelerationякий обробляється AcceleratedMovementSystem. Але для Перешкод ви можете захотіти Friction. Terrain також може мати тертя, але це не буде мати складову швидкості. А як же Gravity? Просто додайте до нього програвач Player, Enemy та перешкода та створіть його GravitySystemдля обробки.

Суть полягає в тому, що чим більше розв'язані ваш Components, тим більше розширюванийEntities буде при використанні Systems.

Редагувати: остання заява стала яснішою.

Редагувати: Гаразд, я працював над власною Системою і прийшов до цього. Прикладом поділу позиції та швидкості є те, що маніпулювання швидкістю призводить до зміни позиції за допомогою MovementSystem. Як результат, "InputMovementSystem" не потрібна позиція, щоб змусити програвач перейти від вводу користувача, оскільки MovementSystem підбере зміни швидкості, які застосовуються до позиції. Зрозуміло, все одно буде чудово скласти їх, але це приклад того, чому цього не потрібно.

Нещодавно я прочитав допис у блозі, де сказано щось подібне:

"Якщо у вас є дані, які можна згрупувати з двома різними компонентами, найкраще створити третій компонент з цими даними."