Суб’єктна / компонентна система та інтерфейс користувача "Суб'єкти"

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

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

Як (і де) проблеми інтерфейсу / графічного інтерфейсу вписуються в систему об'єктів / компонентів?

(Примітка. Це питання є агностичним для платформи, оскільки стосується кількох платформ / мов)

2d component-based gui

— попіл999
джерело

Я думаю, що вам здається логічним лише тому, що ви робите 2d гру. Уявіть, що ви зробили б 3D-ігри (з 2d gui) майже жодну логіку візуалізації не можна було б повторно використовувати, а компоненти 2d gui у 3d-світі не мали б сенсу. Слід створити графічний інтерфейс на верхній частині компоненти системи. Можливо, ваш GameplayScreen створить світ суті з компонентами, а однією з компонентів буде камера з «полотном», до якого буде малювати ваш рендер. І це полотно стане фоном цього екрану.

— Kikaimaru

@Kikaimaru у вас є точка про 2D. Можливо, я занадто багато в MVC, але це здається поєднанням "моделі" (ігрових об'єктів) та перегляду / контролера (компоненти інтерфейсу). Це працює, звичайно, але чи так це має працювати? Чи є кращі способи? Як це роблять інші?

— ashes999

@ ashes999 ваш коментар та початкове запитання з глибокого мого серця :)

— Нарек,

@Armen Я ніколи не отримав задовільної відповіді на це.

— ashes999

@ ashes999 мене до. Скрізь люди кажуть, що не слід змішувати MVC з ECS, але чому? Хіба це не було б приємно? Різна зброя для різних завдань, ви не згодні?

— Нарек

Відповіді:

Після використання декількох систем-компонентів, особливо CraftyJS, я більш-менш отримав відповідь на моє запитання: так, ви можете повторно використовувати компоненти (особливо спрайти або зображення та оброблювачі клацання мишею в 2D іграх) для GUI.

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

Якщо у вас є доступ до базової системи (наприклад, Ruby roguelike з прямим доступом до Curses), ви можете виявити, що малювання / візуалізація безпосередньо в цій системі є більш ефективною (менше коду, менш тендітною, природнішою), ніж використання групи сутності та компоненти.

— попіл999
джерело

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

— Емір Ліма

@EmirLima для чогось подібного, я поставив би більшість логіки інтерфейсу користувача у панелі здоров'я (змінивши розмір барної стійкості) і змусив гравця генерувати подію, коли він потрапив, вказуючи, яке нове / змінене значення для здоров'я. (Служба охорони здоров'я може зафіксувати цю подію та реагувати належним чином.)

— ashes999

Але який об’єкт охорони здоров'я в цій архітектурі? Це суб'єкт господарювання зі складовою "бар здоров'я"? Клас, який успадковує від Сутності? Звичайний об'єкт з жорстким кодуванням?

— Емір Ліма

@EmirLima Я б моделював панель здоров'я як сутність, а гравця - як сутність. Ви можете робити все, що для вас має сенс.

— ashes999

У 2D або 3D система компонентів сутності (ECS) повинна мати принаймні доступ до системи GUI, якщо вона не є частиною того ж ECS.

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

Наприклад, я думаю, що компоненти для GUI-об'єктів будуть чимось на зразок position, renderі gui. Там, де компонент GUI визначав би тип дії, який здійснює сутність GUI. Однак ця дія буде досить унікальною і конкретна. Це призводить до того, що система, яка обробляє компоненти GUI, дуже велика і по суті призначена для обробки кожної з функцій GUI (завантаження гри, збереження гри, пошук сервера тощо). Звучить безладно.

Я вважаю за краще зробити стандартний файл класу для кожного "екрана" графічного інтерфейсу. Майте всю функціональність цього екрана в одному місці (із посиланнями на загальний клас функціональності). Це набагато акуратніше і простіше в управлінні.

Однак, як я вже сказав, ECS повинен мати доступ до системи GUI. Потрібно мати можливість подавати інформацію до графічного інтерфейсу на основі сутностей у його системах. Наприклад, наведення курсора на суміжну одиницю відобразить вікно графічного інтерфейсу з усією інформацією про цей блок. Якщо наведення курсору над ворожою єдністю з’явиться вікно GUI з обмеженою інформацією. Ви, ймовірно, не хочете запрограмувати графічний інтерфейс, щоб знати різницю між ними, ви хочете попросити організацію відобразити її інформацію.

Таким чином, суб'єкти все ще матимуть якийсь компонент GUI, але вони будуть "в грі", а не GUI. Цей компонент буде використовувати зовнішню систему GUI для створення їх інтерфейсу GUI.

— MichaelHouse
джерело

Звучить, як у мене система, зовсім відрізняється від описаної вами. У мене є класи TouchButtonсущностей, які складаються з спрайта та слухача, що працює на дотик. Для спливаючого одиниці я, мабуть, реалізував би це як комбінація компонента спрайт + компонент слухача миші. Хм.

— ashes999