Державні зміни в об'єктах або компонентах


9

У мене виникають певні проблеми з розумінням того, як боротися з управлінням державою в моїх структурах.

У мене немає проблем із управлінням ігровим станом, як-от пауза та меню, оскільки вони не обробляються як система компонентної сутності; просто зі станом в сутностях / компонентах.

Малюючи з Orcs Must Die, як приклад, у мене є об'єкти MainCharacter і Trap, у яких є лише такі компоненти, як PositionComponent, RenderComponent, PhysicsComponent.

При кожному оновленні Entity буде викликати оновлення своїх компонентів. У мене також є загальний EventManager зі слухачами для різних типів подій.

Тепер мені потрібно вміти розміщувати пастки: спочатку виберіть положення пастки та пастки, а потім поставте пастку.

При розміщенні пастки вона повинна з’являтися перед MainCharacter, викладеною по-іншому і слідуючи за нею. При розміщенні він повинен просто реагувати на зіткнення та бути винесеним у звичайний спосіб.

Як це зазвичай обробляється в компонентних системах?

(Цей приклад є специфічним, але може допомогти з’ясувати загальний спосіб поводження з державами держав.)


1
Чи можете ви додавати та видаляти компоненти об'єктів на основі подій введення? Можливо, ви можете змінити компоненти пастки, коли зміниться стан. Наприклад, під час розміщення пастки він матиме FollowComponent та RenderEffectComponnent. Коли він розміщується, ви виймаєте обидва компоненти і додаєте CollisionComponent. (Редагувати:
Ясніше

Так, я можу, кожен вклад переводиться з "HumanView" в ігрові події, які, в основному, вперше обробляються моїм GameLogic класом, який перевірятиме, наприклад, чи є у MainCharacter достатньо грошей, щоб розмістити пастку, як це відбувається після цього, що я намагаюся зрозуміти.
GriffinHeart

Відповіді:


6

Одним із цікавих застосувань компонентної системи є те, що ви можете змінювати компоненти об'єкта під час виконання, якщо ви створили його для того, щоб обробляти такі. Стан суб'єкта господарювання, таким чином, стає сумою обох компонентів, які йому призначені, і яких значень вони мають.

Для вашого прикладу, ви можете спершу створити пастку за допомогою BuildControllerComponent(керування реакцією на елементи управління гравцем у фазі збірки), a PositionComponentта a RenderComponent. В останньому є одне поле даних, яке керує використовуваними піксельними шейдерами, і одне з них надає пастці для будування "примарний" вигляд. Ви помітите, що ще не призначені фізичні компоненти.

Після розміщення пастки компоненти обмінюються. Він BuildControllerComponentбільше не потрібен, тому його видаляють. У RenderComponentшейдери добуде замінена на нормальному стандартному вигляді пастки. Нарешті, PhysicsComponentяк і все інше, необхідне для роботи пастки, додаються до сутності.

У підході до спадкування це еквівалентно конструктору для ActiveTrapEntityкласу, який приймає BuildTimeTrapEntityклас як аргументи, другий використовується для надання пастки під час його складання, перший використовується для пастки після його встановлення .


Це розумно.
Cypher

1
Це гарна стратегія застосування стану суб'єкта господарювання. Тут не вирішено питання про те, як відстежувати стан кожного суб'єкта господарювання. Звідки ви знаєте, в якій державі знаходиться даний суб’єкт господарювання?
MichaelHouse

@MartinSojka Це підходить майже до того, про що я думав, задавши питання. Я розглядав можливість додавання BuildTrapProcess (те, що оновлюється в GameLogic), який буде керувати аспектом виконання змінних компонентів для досягнення змін стану, необхідних для створення пастки. Коли кнопка побудови пастки натисне, логіка гри створить Процес і запустить його. якісь думки щодо цього підходу?
GriffinHeart

@ Byte56: Загалом, ви можете запитувати пов'язані компоненти та його значення. На практиці вам часто потрібно лише знати відповідний підмножина цілої держави, наприклад, "Чи існує ця сутність BuildControllerComponent?" або "Яка позиція цього суб'єкта господарювання зафіксована в її PositionComponent, якщо вона є?" - ті, що ви робите, перевіряючи список компонентів на ті, що вас цікавлять, і необов'язково запитувати (деякі) їх значення.
Мартін Сойка

1
@GriffinHeart: Я просто реалізую все, що потрібно для "побудови" пастки в системі, пов'язаної з управлінням BuildControllerComponents. Тут уже потрібно обробляти зміни точки зору персонажа (або камери) гравця, а також події натискання клавіш та миші.
Мартін Сойка

5

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

Ви можете додати додатковий компонент під назвою "Держава". До нього звертатимуться ваші системи візуалізації та зіткнення. Компонент стану - це лише прапор, у якому доступно кілька станів. Для ситуації, яку ви описуєте, були б Playі Build. Коли система візуалізації побачить, що стан є, Buildвона намалює об'єкт напівпрозорим. Коли система зіткнення бачить Buildстан, вона не обробляє зіткнення з програвачем.

Але насправді, якщо у вас немає систем і ви покладаєтесь на компоненти, щоб виконати всю роботу, яку ви збираєтеся зіткнутися з багатьма проблемами. Компоненти не повинні знати один про одного, і вони не повинні робити обробку.


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

Я кажу і те, і інше. Я кажу, що вони повинні не знати, і намагаюся адаптувати мою відповідь на те, як я думаю, що ви обробляєте компоненти. Коли ви говорите: "Entity зателефонує до оновлення своїх компонентів", це змушує мене повірити, що у вас немає системних обробників. Я видалив заплутану мову і просто змусив її сказати системи. Я казав компоненти, тому що розумів, що саме так ви оновлювали.
MichaelHouse

Мені подобається ідея про StateComponentте, що може споживатися декількома системами.
Cypher

1
Ввічливо висловлювати міркування для молодих людей. Дякую.
MichaelHouse

2
З іншого боку, ваше заперечення проти підходу до запитувача базується на припущенні, що весь дизайн, що базується на компонентах, повинен оновлювати компоненти з окремих систем (як, наприклад, дизайн системи). Це один із способів зробити це, але, безумовно, не єдиний, і немає ніяких причин відмовляти від такого підходу до гри, яка не потребує оптимізації кешу оптимізації компонентів.
Шон Міддлічч
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.