Як кодувати UI / HUD в Entity System?


18

Думаю, я вже отримав ідею Entity System, натхненну Адамом Мартіном (t-machine). Я хочу почати використовувати це для свого наступного проекту.

Я вже знаю основи сутності, компонентів та систем. Моя проблема полягає в тому, як поводитися з UI / HUD. Наприклад, вікно квесту, вікно навичок, вікно інформації про символи тощо. Як ви обробляєте події інтерфейсу (наприклад, натискання кнопки)? Це речі, які не потрібно обробляти кожен кадр. В даний час я використовую MVC для кодування інтерфейсу, але я не думаю, що це буде сумісним для Entity System.

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

Відповіді:


17

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

Можливо, якщо ви зробите свій інтерфейс розділеним, це буде набагато краще і простіше. Вам не потрібно робити ВСЕ, що знаходиться в межах об'єктів.


Про це також говорить Адам Мартін в одному зі своїх дописів чи коментарів до t-machine. ES - це рішення конкретної проблеми. Його можна і потрібно використовувати разом з більш «традиційними» рішеннями для інших аспектів гри (двигуна).
user8363

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

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

@Armen MVC не має жодних проблем, але розміщення його всередині об'єктів має. Просто його переваги не переможуть його недоліки. Не потрібно бути космонавтом архітектури
Густаво Масель

3

Хоча я думаю, що інтерфейс Entity / Component може працювати, важко зробити це так. Крім того, це досить віддалено від компонентів та систем, які ви мали б для обробки ваших ігрових об'єктів, це було б по суті просто іншою системою об'єктів / компонентів у вашій грі. Не можу уявити, що між ними буде багато перекриттів.

Системи сутності є приголомшливими, і використовувати їх можна всюди спокусливо. Зрештою, коли ви отримуєте по-справжньому солодкий молоток, ви спокушаєтесь ставитися до всіх своїх проблем, як до нігтів. Однак система EC - це ще один інструмент у вашій сумці програмування. Для проблем, які використовуються для її вирішення, працює дуже добре, але у вас є кращі інструменти для таких проблем, як UI.

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


1

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.