Це продовження цього питання, на яке я відповів, але це стосується набагато конкретнішої теми.
Ця відповідь допомогла мені зрозуміти Entity Systems навіть краще, ніж стаття.
Я прочитав (так,) статтю про Entity Systems, і вона мені сказала наступне:
Суб'єкти - це лише ідентифікатор та масив компонентів (у статті йдеться про те, що зберігання об'єктів у компонентах не є гарним способом виконання дій, але не пропонує альтернативи).
Компоненти - це фрагменти даних, які вказують, що можна зробити з певною сутністю.
Системи - це "методи", вони виконують маніпулювання даними про сутності.
Це здається дійсно практичним у багатьох ситуаціях, але частина про компоненти, які є лише класами даних, мене турбує. Наприклад, як я міг реалізувати свій клас Vector2D (Позиція) в системі Entity?
Клас Vector2D містить дані: координати x і y, але він також має методи , які мають вирішальне значення для його корисності та відрізняють клас лише від масиву з двох елементів. Приклад методу: add()
, rotate(point, r, angle)
, substract()
,normalize()
, і всі інші стандартний, корисні, і абсолютно необхідні методи , що позиції (які є екземплярами класу Vector2D) повинні мати.
Якби компонент був лише власником даних, він не міг би використовувати ці методи!
Одне рішення, яке, можливо, може спливати, - це впровадити їх всередині систем, але це здається дуже протиінтуїтивним. Ці методи - це те, що я хочу виконувати зараз , щоб вони були повноцінними та готовими до використання. Я не хочу чекати, коли MovementSystem
прочитати якийсь дорогий набір повідомлень, який доручає йому здійснити обчислення позиції суб'єкта господарювання!
І ця стаття дуже чітко зазначає, що лише системи повинні мати будь-яку функціональність, і єдиним поясненням цього, яке я міг знайти, було "уникнути ООП". Перш за все, я не розумію, чому слід утримуватися від використання методів у сутностях та компонентах. Накладні витрати на пам'ять практично однакові, і в поєднанні з системами їх слід дуже легко реалізувати та поєднувати цікавими способами. Наприклад, системи могли надати основну логіку суб'єктам / компонентам, які самі знають реалізацію. Якщо ви запитаєте мене - це в основному беручи смаколики як від ES, так і від OOP, те, що неможливо зробити за словами автора статті, але мені здається, що це хороша практика.
Подумайте про це таким чином; в грі є багато різних видів зображуваних предметів. Звичайні старі зображення, анімації ( update()
, getCurrentFrame()
і т. Д.), Комбінації цих примітивних типів, і всі вони могли просто надати draw()
метод системі візуалізації, який потім не повинен дбати про те, як реалізується спрайт сутності про інтерфейс (малюнок) та положення. І тоді мені знадобиться лише система анімації, яка викликала б конкретні анімаційні методи, що не мають нічого спільного з візуалізацією.
І лише одне інше ... Чи дійсно є альтернатива масивам, коли мова йде про зберігання компонентів? Я не бачу іншого місця для зберігання компонентів, крім масивів всередині класу Entity ...
Можливо, це кращий підхід: зберігайте компоненти як прості властивості сутностей. Наприклад, позиційний компонент буде наклеєний на entity.position
.
Тільки інший спосіб буде мати якесь - то дивну довідкову таблицю всередині системи, що посилання на різні об'єкти. Але це здається дуже неефективним і складнішим для розробки, ніж просто зберігання компонентів у суті.