Comments 19
З.Ы. Не переключайтесь, будет еще вторая часть про то как этот самый UI мучали от игры к игре...
А рецепт таблетки от всего этого бардака будет?
— Вас мучают эротические сны?
— Ну почему же мучают? (С)
А рецепт таблетки от всего этого бардака будет?
Нет, особенность разработки архитектуры как раз и заключается в том, что сделать один вариант для всех нельзя.
Рецепт один - берешь и пишешь костыли под конкретный проект. Серебряной пули нет, кто бы что ни продавал на ассет-сторах
Даже в играх GUI уже на HTML :(
Сколько истории автор перекопал!
Автор явно в теме, и уже давно.
Мне понравилось.
Я сталкивался с нестандартным UI написанным на Unity для 1С.
Сейчас нестандартные интерфейсы для 1С пишутся на HTML. Там результаты не сильно отличаются от бадака, описанного в статье.
Coherent Gameface, Scaleform, Awesomium-наследники (CEF) позволяют верстать игровой UI как сайт.
Scaleform не позволяет. Это чистый Flash, без вёрстки и даже без layout'а. Если вы хотите в нём верстать - вам придётся написать какое-то своё решение.
На мой взгляд, стоило упомянуть ещё одну огромную проблему всех готовых UI решений вроде Gameface, Scaleform и CEF - датабиндинг. Если в "чистом" Unity и UE у вас UI существует в той же области видимости, что и игровая логика и код контроллера какого-то элемента в HUD может просто подписаться на изменение хп персонажа, чтобы потом по нему делать
healthBar.value = health.value / health.max; то в случае фреймворков у вас UI живёт в отдельном мире (зачастую ещё и в своём потоке) и ничего про остальную игру не знает. Когда данных у вас немного, то это не проблема, но когда вы отображаете в интерфейсе сотни параметров, которые ещё и постоянно меняются, уже сама передача данных - это тот ещё квест. Потому что вы не можете просто обновлять все данные каждый кадр - это слишком дорого и по производительности, и по памяти. Вам нужно отслеживать какие данные поменялись и отправлять только их. И ни в коем случае не отправлять лишнее.
Но ваш дизайн ещё и захочет одни и те же данные отображать в разных местах. Например, хп противника - и на маркере в мире, и на миникарте. А вы не захотите все такие данные слать по два раза. Вот так внутри UI фреймворка появляется своя модель данных, которая через какой-то ваш механизм синхронизируется с игровой логикой. И вроде всё хорошо, пока кто-то не начнёт оптимизацию по памяти и не выяснит что у вас теперь одни и те же данные лежат в двух местиах - в игровой логике и в UI (а может и в трёх - плюс ваш механизм синхронизации).
Да есть такая проблема, но это не беда именно ui а вообще любого middleware, которое нужно обновлять чаще одного раза в секунду.
у scaleform был механизм loadVariables который позволял прокидывать данные внутрь анимации, чем многие и пользовались размещая на простых лейаутах такие псевдовиджеты и работая с ними как со статической страницей, пересоздавая её а конце фрейма. Сами анимации уже загружены, и заново сделать разметку выходило дёшево.
Но яаще основной механизм взаимодействия был через ExternalInterface и GFx::Movie::Invoke или SetVariable со стороны C++, как вы описали, потому что возиться со своим парсером shtml было лень.
Кстати да, сами Autodesk рекомендовали подход, где каждый элемент UI - отдельный маленький GFx::Movie с относительно коротким временим жизни. А когда весь интерфейс в одном мувике, да ещё с кучей кода на AS - начинаются проблемы с производительностью и утечками. По этой причине Scaleform сложно поставить в ряд с Gameface и CEF, сейчас он уже устарел.
Вот Gameface - наоборот, начинает себя чувствовать хуже если отображать сразу несколько инстансов.
Что-то я так и не нашёл, где на https://coherent-labs.com/ скачать SDK и поиграться с демками. Плюс, раздел https://coherent-labs.com/pricing/ с двумя коммерческими планами внушает лёгкие подозрения, что у них нет никакого try-b4-u-buy :)
Помимо них, слава богу, есть и другие очень быстрые UI-движки с DOM и стилизацией, специально заточенные под интеграцию в игры. В том, с которым я сейчас работаю, фришный и коммерческие планы разделяются как раз по FPS Limit. Т.е., сами понимаете, быстрые. Схема примерно одинаковая: каждый кадр надо давать движку возможность посчитать свои анимации, перенаправлять ему нужный ввод от виртуального окна, а они, в случае изменений, обновляют RGBA frame buffer. Дальше хоть в текстуру, хоть куда.
Я его встраиваю в одну игру, дюже поганую… которая называется Windows 11. У которой сишные API DWM запрятаны так глубоко, и имплементированы так криво, что это та ещё головоломка.
Scaleform не использовал Adobe Flash Player как зависимость, они просто написали собственный SWF-рантайм который читал тот же формат файлов что и Flash, а рендерил через абстрактный бэкенд.
Gameface основан на собственных библиотеках Cohtml и Renoir, написанных с нуля специально для игр, и не основан на WebKit, Chromium или Gecko, т.е. они написали свой с нуля совместимый с HTML5 движок рендера страниц и вот этот UI фактически является сайтом, со страницами.
Если в Gameface я был плюс-минус уверен, то в природе Scaleform у меня были жуткие сомнения. Штош, the more you know.
Биндинги через строки - мина замедленного действия. Чуть переименовал поле при рефакторинге и потом полдня ищешь, почему прогресс-бар перестал обновляться
Современное состояние дел в области проектирования и реализации интерфейсов пользователя чем-то напоминает ситукцию с созданием баз данных во времена CODASYL.
Куча всяческих эвристик, куча guidelines, использование избыточно мощных парадигм (OOP).Даже работы Раскина - это не более чем набор эвристик, применимых в довольно частном случае.
Как результат - интерфейсы получаются громоздки, неудобные, тормозные, ресурсоемкие.
Все мы помним что случилось в области базостроения потом - пришли Кодд и Дейт и создали реляционную алгебру.
Сразу стало значительно понятнее, несмотря на то, что распространение полноценных, разработанных на основе этой теории языков QBE и SQL заняло десятилетия.
[...]
На мой взгляд, IT в наше время остро нуждается в создании математической теории интерфейса пользователя.
Понятно, что раз тут есть такое плохо формализуемое существо, как человек, задача создания этой теории крайне непроста. Но программа-то, которая с человеком взаимодействует через этот интерфейс - объект до конца формальный.
Сейчас разработка интерфейсов напоминает скорее художественный дизайн, чем проектирование технической системы.
Но ведь на самом деле интерфейс - штука до предела функциональная. Главное в нем не рюшечки, а наглядное представление необходимой для принятия решения информации, и получение от человека возможно более однозначного (и с наименьшей вероятностью ошибки) результата принятия этого решения.
Опять же следует учесть, что рассматривать надо не принятие единичного решения, а типичный путь по "развилкам", проходимый пользователем в процессе решения задачи.
Очевидно, что существуют какие-то классы эквивалентности интерфейсов. Например обычное диалоговое окно с кучей контролов, tabbed dialog и wizard могут предоставлять ровно ту же самую информацию и позволять те же самые варианты принятия решений.
А вот в каких случаях удобнее то представление, а в каких - другое - никаких правил пока нет. Можно сравнить эту ситуацию, скажем с с нормальными формами в РСУБД. Там во всех учебниках написано, когда надо делать нормализацию, а когда - денормальизацию. Хотя в любой конкретной ситуации решение все равно остается за проектировщиком, но он хотя бы знает к чему приведет то или другое решение.
Оригинал: https://vitus-wagner.dreamwidth.org/314382.html
Почему игровой GUI пишут заново (Ч.1)