Як піти про елементи GUI?


12

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

Я думав, як це зробити. Я маю на увазі елементи:

  • Кнопки радіо
  • Введіть тут текстові поля
  • Кнопки
  • Повзунки
  • Прапорці

Я ще не дивлюсь, як їх зробити. Але більше про те, як вони йтимуть.

Ідея

Я мав би кожен штат, який потребував речі, тому майже всі мали контейнер Елементів. Кожен Елемент - це твір GUI.

Вони мають позицію, графіку тощо.

Біт, який я більше застрягаю, - це їх логіка.

Моя ідея для цього, щоб дозволити модульність і простоту, полягала в тому, щоб уникати MainMenuStartButton; a OptionsOneBackButton і т. д. і замість цього мати можливість виконувати повзунок Slider1; або кнопку запуску ;.

Натомість кожен би мав boost :: функцію до функції в просторі імен GUI, наприклад, Gui :: StartButtonClick або GUI :: ColourSliderHover.

Мені просто було цікаво, чи буде це виключно повільно чи ні.

І з цього приводу, чи існує якийсь простий і простий спосіб зробити графічний інтерфейс для ігор? Немає Qt, wxWidgets чи нічого.

Відповіді:


15

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

Одне "легке", що ви можете зробити, це спробувати використовувати проміжне програмне забезпечення. Там це питання про те, що тут .

Якщо ви збираєтеся прокрутити його самостійно, я б запропонував кілька речей.

  • Елементи GUI зазвичай мають "батьківський", або інший елемент GUI, або "вікно", або щось подібне. Або наведення вгору, або батьківська точка вниз означає, що ви можете встановити стан / положення / тощо на все, що є дитиною.

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

  • Дуже багато так званих спеціалізованих віджетів - це просто кнопки в маскуванні. Поле прапорців - це лише кнопки зі станами та спеціальними зображеннями. Радіо кнопки - це лише прапорці, які мають мета-стан (один і єдиний активний у будь-який момент часу) з іншими перемикачами. Використовуйте це на свою користь. В одній грі, над якою я працював, "прапорці" робилися звичайними кнопками повністю за допомогою сценарію та мистецтва.

  • Для першого проекту розгляньте прямий шлях. Так, зробіть своїх делеґатів подій, що діють, і призначте те, що вам потрібно для створення елементів (наприклад, onMouseButtonDown, onMouseButtonUp, onHover і т. Д.), Але врахуйте просто жорстке кодування того, що ви хочете статися в іншому випадку (наприклад, наведіть зміни кольору, натисніть звуки), поки не отримаєте щось функціональний. Після того, як ви в цей момент, подумайте про те, щоб зробити ці дані про поведінку (тобто мати змінну на кнопці для "натискання звуку", або, можливо, подумайте про наявність компонентів, які ваші елементи інтерфейсу використовують для визначення поведінки, яку ви просто додаєте до них під час їх створення.

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


2
Для більш складних інтерфейсів GUI вам знадобиться якесь управління компонуванням досить скоро. Базові макети, такі як HBox і VBox, набагато простіше у використанні, ніж позиціонування всіх елементів з абсолютними координатами. Приклад: web.archive.org/web/20100410150433/http://doc.qt.nokia.com/4.6/… Це робить ваш графічний інтерфейс простішим у використанні, але не таким простим у застосуванні;)
bummzack

8

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

Моя особиста улюблена система користувальницького інтерфейсу - Фонд презентацій Windows (WPF). Це дійсно переносить потенціал для диференціації інтерфейсу користувача на наступний рівень. Ось деякі його цікавіші особливості:

  1. Елементи керування за замовчуванням не мають вигляду. Логіка та візуальний вигляд управління, як правило, відокремлюються. Кожен елемент управління надає стиль та шаблон за замовчуванням, який описує його візуальний зовнішній вигляд за замовчуванням. Наприклад, кнопка може бути представлена ​​у вигляді закругленого прямокутника із зовнішнім штрихом, суцільним кольором або фоном градієнта та презентатором вмісту (для подання підпису). Розробники (або дизайнери) можуть створювати шаблони користувальницьких стилів, які змінюють зовнішній вигляд та (певною мірою) поведінку контролю. Стилі можна використовувати для зміни простих властивостей елемента керування, наприклад, колір переднього плану / фону, шаблон тощо; шаблони змінюють фактичну візуальну структуру.

  2. Стилі та шаблони можуть включати "Тригери". Тригери можуть прослуховувати певні події чи значення властивостей (або комбінації значень) та умовно змінювати аспекти стилю чи шаблону. Наприклад, шаблон кнопки, як правило, має тригер на властивості "IsMouseOver" для зміни кольору фону, коли миша наводить на кнопку.

  3. Існує кілька різних "рівнів" елементів інтерфейсу, починаючи від легших елементів ваги з мінімальною функціональністю до повномасштабних засобів важкої ваги. Це дає певну гнучкість у структурі інтерфейсу користувача. Найпростіший з елементів елементів інтерфейсу користувача UIElement, не має стилю чи шаблону і підтримує лише найпростіші події введення. Для простих елементів, таких як індикатори стану, ця функціональність може бути всім, що вам потрібно. Якщо вам потрібна більш широка підтримка введення, ви можете отримати FrameworkElement(що розширюється UIElement). Традиційні віджети, як правило, випливають із цього Control, що розширює FrameworkElementта додає користувальницький стиль та підтримку шаблонів (серед іншого).

  4. WPF використовує збережену, масштабовану, незалежну від дозволу векторну графічну модель. У Windows програми WPF відображаються та складаються за допомогою Direct3D.

  5. Введення WPF включало нову декларативну мову програмування під назвою Xaml. Xaml, заснований на Xml, є кращою мовою для оголошення "сцени" інтерфейсу користувача. Насправді це дуже гладко, і хоча на перший погляд може здатися схожим, він принципово відрізняється від існуючих мов, таких як XUL (і набагато потужніший).

  6. WPF має дуже розвинену текстову підсистему. Він підтримує більшість, якщо не всі функції шрифту OpenType, двонаправлене антиаліагенне ClearType, позиціонування субпікселів тощо.

"Добре, чудово, тепер як це стосується розвитку ігор?"

Ще тоді, коли WPF ще розроблявся (і був відомий як "Avalon"), я проходив курс дизайну відеоігор на Georgia Tech. Мій остаточний проект був покроковою стратегічною грою, і я хотів дуже спроможного інтерфейсу. WPF / Avalon здавався гарним маршрутом, оскільки він мав повний набір повнофункціональних елементів керування, і це грає мені здатністю повністю змінити зовнішній вигляд цих елементів управління. Результатом стала гра з гарним і чітким інтерфейсом користувача з рівнем функціональності, який ви зазвичай бачите лише у повноцінних додатках.

Тепер проблема використання WPF для ігор полягає в тому, що він досить важкий і робить його у власній "пісочниці". Я маю на увазі, що не існує підтримуваного способу розміщення WPF в ігровому середовищі Direct3D або OpenGL. Вміст Direct3D можна розміщувати в програмі WPF, але ви будете обмежені рамкою програми WPF, яка, як правило, нижче, ніж ви хотіли б. Для деяких типів ігор, таких як 2D стратегічні ігри (скріншот мого поточного ігрового проекту WPF), він все ще може чудово працювати. За що-небудь інше, не дуже. Але ви все ще можете застосувати деякі найбільш переконливі архітектурні концепції WPF для розробки власного інтерфейсу.

Існує також відкрита, некерована C ++ / Direct3D реалізація WPF під назвою "WPF / G (WPF для ігор)"] ( http://wpfg.codeplex.com/ ), яка спеціально розроблена для використання в іграх на обох Win32 та Windows Mobile. Здається, активний розвиток припинився, але востаннє, коли я це перевірив, це було досить повною реалізацією. Текстова підсистема була єдиною областю, якої насправді бракувало порівняно з впровадженням WPF від Microsoft, але для ігор це менше проблеми. Я думаю, що інтеграція WPF / G з ігровим движком на основі Direct3D буде досить простою. Пройшовши цей маршрут, ви можете забезпечити надзвичайно здатну систему незалежного інтерфейсу, незалежну від роздільної здатності, широку підтримку налаштування інтерфейсу користувача.

Просто для того, щоб дати вам уявлення про те, як може виглядати інтерфейс гри на основі WPF, ось скріншот із проекту мого домашнього улюбленця:

Знімок екрана з мого поточного ігрового проекту на основі WPF


NoesisGUI використовує WPF. Це досить добре, але я не знаю WPF, і мені здається, що це болі вчити. Я б віддав перевагу особистому підходу до стека.
користувач441521

2

Я б звернувся за негайним графічним інтерфейсом, наприклад таким: http://code.google.com/p/nvidia-widgets/

Віджети nVidia засновані на IMGUI (негайному графічному інтерфейсі) від MollyRocket.

Я думаю, що це так просто, як GUI може отримати коли-небудь.

Все залежить від ваших потреб.


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

2

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

В основному всі кнопки, прапорці тощо є підкласами класу Element; і елементи мають події. Тоді у нас є CompoundElements (які самі є підкласом Element), які містять інші елементи. У кожному циклі називаються три методи: processEvent (подія), галочка (час) та draw (поверхня). Кожен CompoundElement тоді викликає ці методи на своїх дочірніх елементах. У цих викликах (особливо метод processEvent) ми припиняємо будь-які відповідні події.

Все це є в Python (набагато повільнішою мовою, ніж C ++), і це працює чудово.


2

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

Існує кілька бібліотек для вбудовування Webkit в ігри: Беркелій - це той, кого я рекомендую, і я чую, що Awesomium досить непоганий (використовується EVE Online) і так це CEF (використовується Steam). Ви також можете спробувати вставити Gecko - це зробити набагато складніше, але має і деякі цікаві переваги. Наразі я використовую Berkelium для всього свого інтерфейсу гри (він замінив комбінацію користувацьких елементів інтерфейсу та власного інтерфейсу, і значно зменшив кількість коду, який мені довелося написати, щоб розпочати роботу).


^ Це 100%. Мене сумує відсутність хорошого веб-стека для реалізації ігор там. Веб-стек є чудовим для інтерфейсу користувача, і він повинен почати бути більш поширеним у всіх іграх для їх інтерфейсу. Поки що бібліотеки, з якими я намагався працювати, боліли в дупі, щоб реалізувати або не на 100% правда html / css / javascript. Я зараз дивлюся на Coherent Labs, і це виглядає багатообіцяюче, але це коштує неабияку суму, але має інді-версії для пари двигунів.
користувач441521

2

Переконайтеся, що вам справді потрібна складна система GUI для вашої гри. Якщо ви робите комп'ютерний RPG, тоді, очевидно, це буде вимогою; але для чогось, як гоночна гра, не слід занадто ускладнювати речі. Іноді просто рендерінг текстур (зображення власних кнопок) та наявність деяких "якщо" висловлювань із жорстко закодованими координатами у вашій функції введення можуть виконати роботу. Такий простий підхід допомагає ігровий автомат (FSM). Або десь посередині, забудьте про складний підхід до ієрархії та графіку сцени і просто мати клас "Кнопка", який пакує вищезазначені текстури та вхідні перевірки у прості функціональні дзвінки, але не робить нічого складного.

Збивання ваших вимог важливо. Якщо ви не впевнені, просто нагадайте собі YAGNI .


1

Ось один приклад (вихідний код та всі) графічного інтерфейсу, побудованого для OpenGL, спеціально для Slick2D під назвою Thingle, який є портом Thinlet .

Іншим графічним інтерфейсом для Slick2D був SUI, який ви можете перевірити.

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


1

Я думаю, що одним з найкращих способів "розібратися в цьому" було б ознайомитися з тим, як працюють високорозвинені рамки графічного інтерфейсу, такі як Windows Forms в .NET.

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

Всі вони містять різні події , такі як Click, MouseOverі Resizing.

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

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


1

Заради інтересів я думав, що викину Scaleform . В основному художники можуть використовувати ілюстратор, фотошоп тощо, тоді дизайнер інтерфейсу використовує Flash для компонування всієї інтерактивності. Потім Scaleform перетворює його в код для вашого двигуна (добре, це я розумію, як я не використовував його). Crysis Warhead використовував цю систему для свого лобі.

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