Рубрика развивается при поддержке
Gamedev
Andrey Apanasik
3420

Вышла 3 версия NoesisGUI

NoesisGUI - UI фреймворк на C++, который, к примеру, используется Larian Studios при работе над Baldur's Gate 3.

О чём сообщили разработчики в своём твиттере. Также их подержал Свен Винке, CEO Larian Studios.

Я хотел бы поддержать NoesisGUI. У нас есть много пользовательского интерфейса, который мы обычно переделываем от 3 до 5 раз в течение разработки, а этот фреймворк упростил нам итерирование. Их поддержка тоже фантастическая.

Свен Винке
Няша

И показал 3 версию UI. К выходу в EA мы увидим уже 4.

Пишу про /gamedev (в частности, про /unity) и около него. Веду свой бложик, пишу что-то в дзене. - Твиттер.- Хабр.Всем добра (ノ◕ヮ◕)ノ*:・゚✧
{ "author_name": "Andrey Apanasik", "author_type": "self", "tags": ["ui","larian","gui","baldursgate"], "comments": 50, "likes": 37, "favorites": 65, "is_advertisement": false, "subsite_label": "gamedev", "id": 138193, "is_wide": false, "is_ugc": true, "date": "Fri, 22 May 2020 10:24:35 +0300", "is_special": false }
Разработка игр для PC, консолей
и мобильных платформ
Я готов!
0
50 комментариев
Популярные
По порядку
Написать комментарий...

Простой Филипп

14

Немного офтоп, но как же от персонажей отдает Инквизицией)

Ответить
7

И это скорее даже хорошо) Надеюсь, кстати, что в этом посте не будет нытья про "интерфейс как в Дивинити", Свен уже раза три в интервью говорил, что интерфейс 300 раз поменяется, это просто заглушка для показа и удобства разработки. 

Ответить

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

Комментарий удален

0

Справедливости ради он уже 298 раз поменялся, так-что можно поныть об интерфейсе не сравнивая с Дивинити. 

Ответить
0

Поныть можно всегда, без этого никуда) 

Ответить

Классический космос

Радослав
0

Ничего нет более постоянного, чем временное

Ответить
2

Ничего не знаю про Инквизицию. Может речь идёт про Драгонагию, но я в этот шлак так толком и не играл.
Но отдаёт такой лакированностью, прилежностью, выглаженностью. Слишком эти модели опрятные. Как будто только вышли из дома моды. Нет вот той естественной потрёпанности, растёгнутых пугович и прочей неряшливости.
И ещё тела совершенно одинаковой комплекции и роста.
А этот вампир вообще нелепо смотрится с луком. Как-то, млять, всё неестественно.

Что касается 4 против 6 (как это было в настоящей БГ1\2)... То такое впечатление, что они спецально урезали отряд ради возможности всех 4 разместить на одном экране.

Ответить
4

 И ещё тела совершенно одинаковой комплекции и роста.

Ничего себе претензии, конечно.

Ответить
1

А почему нет. Что им мешает предать индивидуальности каждому персонажу. А так у них меняются причёски и чуть лица.
И было бы совсем замечательно, если бы от физических характеристик менялась комплекция. Т.е. Сила 10 = мускулистый мужик. А то мы видим очередную клеше-девочку-война, но с телом принцески. 

Ответить
4

Сила 10 = мускулистый мужик

16 минимум

Ответить
1

Окей. Я по привычке по классической Фоллаутовской системе...

Ответить
2

Ага, прокачал персонажа на силу и получил качка кубической формы.
И надо добавить параметр голода, который снижает силу, а значит визуальную мышечную массу, и телосложение.
А если мы такое добавляем, то и остальным параметрам тоже надо такое!
На ловкость надо периодически делать растяжки, проходить полосу препятствий и вскрывать замки на время.
На силу - качаться.
На телосложение - хорошо кушать.
На интеллект - читать научную литературу.
На мудрость - читать словари и википедию.
Ну и на харизму - периодически мыться, и общаться с другими персонажами и НПС как можно чаще.

УХ!

Ответить
0

У тебя извращённое представление, но некоторые аспекты ты подчеркнул правильно. Для особо-одарённых подчеркну, что существуют разных математические формулы для подчёркивания внешности персонажа. Это могут быть диапозоны, а так же общее влияние на внешность различных параметров. Т.е. из этих комбинаций будет складываться телосложение.

Например. Если Сила 20 и Ловкость 8, то персонаж будет типичным штангистом, но если у него Сила 20 и Ловкость 15, то у него среднее телосложение. Это я так для примера.
Что касается Харизмы, то её обычно используют для красоты\очарования других НПС. Тут следующий подход. Харизма 20 = ГГ очарователен и всё такое, но если он получает ранения и злоупотребляет алкоголем, то штраф на Харизму отображается и на его внешности. Т.е. появляются шрамы, мешки под глазами, ну и т.д.
С Интеллектом и так всё понятно, тут обычно\правильно отображать по диалогам. Можно и анимации соответствующие добавить, если ГГ даун.

Вот некоторые усераются по инструментарию создания внешности. А мне это нафиг не надо. Зато я бы хотел видеть отражение своих выборов на модели персонажа.

Кстати, в некоторые ПК ДНД играх такая визуализация присутствует, если игрок выпил зелье великана и прочее, игрок увеличивается в размерах. 

\\Я то в РПГ играю лет 20, т.ч. у меня нет проблем с восприятием и реализацией подобной механики. 

Ответить
0

Надо письмо в лариан составить, с просьбой, шоб було вот это всё.

Ответить
0

А корованы грабить можно?

Ответить
0

Если встречи на глобальной карте будут, то скорее всего можно будет грабить "корованы". Этой механики уже 100 лет.

Ответить
0

Значит и домики набигать будут?

Ответить
0

 Что им мешает предать индивидуальности каждому персонажу.

То, что это лишняя работа (ещё и довольно сложная работа), ради непонятно чего. У лариан на это деняк точно нет.

Ответить
1

Из этого "непонятно чего" и состоят детали. Обычно вы эти мелкие штучки очень любите обсуждать, а когда они исчезают, то тут же потоки критики извергаются.

Ответить
1

Детали это хорошо, кто спорит. Но насколько оправдана эта деталь в игре, где основной вид - сверху, и рост/сложение персонажей не особенно-то заметны?

А ведь заморочиться с ней явно придётся - например, в плане подгонки снаряжения под модель.

Ответить
1

Там изометрический вид. Т.е. ты смотришь под углом. 
Плюс акцент на кат-сцена. Постоянные приближения. И кукла персонажей в инвентаре. Вы слишком много упускаете.

Ответить
0

Я ничего не упускаю. Камеру вообще можно от персонажа не отдалять, кто запретит (правда, играть будет неудобно). Вопрос об оправданности распыления сил и соотношении между затратами и результатом это не снимает.

Ответить
0

Можно. Но ты не будешь придерживаться этого "можно". Т.к. для приближения и сделано приближение. А в других ситуация будет работать вне твоего хочу или не хочу.

А тебя этот вопрос вообще не должен беспокоить. Игру делаешь не ты. Любую хорошую игру делают возможности. И если эти возможности вписываются, то их наличие обычно не обсуждается.

Ответить
0

Время сотрудников студии - ценный и очень ограниченный ресурс. "Вписаться" в игру может что угодно, хоть мама с папой, но реализацией всё равно придётся заниматься конкретным людям, которые могли бы заниматься чем-то другим. Именно поэтому наличие дополнительных механик/контента/etc обсуждается ВСЕГДА. Сомневаюсь, что программистам Larian настолько нечем заняться, что они примутся добавлять в игру незначительные приколюхи.

Ответить
0

Вот когда ты будешь работать в Лариан, то сможешь себе позволить подобные заявления.

Я всего лишь предлогаю идею. И такие идеи реализовываются в играх десятками.

Просто людям вроде тебя ничего не надо. Если бы игры делали люди вроде тебя, то игровая индустрия находилась на уровне игровых автоматов из 80х годов, т.к. и этого было достаточно, а всё остальное время... трудозатраты.. и всякое-всякое.

А я не сомневюсь, ведь у программистов Лариан (и прочих) всегда находится время на реализацию различной ерунды. Но обычно это не осуждается, т.к. является естесственной частью игровых механик. Как, например, физика волос, разводы на воде, учёт веса, перемещение объектов, настройка интерфейса и прочее-прочее. Без всего этого можно прожить, но из этого создаётся будущее. И когда эти примочки у игрока отнимают, то возникают вопросы, визки и сопли на форумах.

Так и или иначе, но мои прогнозы всегда реализуются. Так было лет 20 назад (например. когда я на форумах писал, что будущее фоллаута за морровиндом. а народ пердел и пенился от злости), так и сейчас. все эти нюансы неизбежны. тогда и сейчас выигрывал проект с исключительным подходом, пусть эти изменения не будут столь масштабны, но зато привлекательны для игрока. иначе можно каждый год выпускать ремейки, а ничего нового делать не надо, т.к. программистам очень сложно...

Ответить
0

Проблема в том, что я как раз "делаю игры" - потому и смотрел на ситуацию с точки зрения реальной разработки. Но фантазировать насчёт корованов и охраны дворца запрещать не собираюсь, ради бога.

Ответить
0

Может, мой персонаж аномально сильный, потому что в нём течёт кровь драконов. Это же не значит, что он должен выглядеть как персонаж жожи.

Ответить
1

 как персонаж жожи

может в нем течет кровь голубых драконов

Ответить
0

Продолжай развивать свою мысль, так вполне придумаешь чего интересное.

Ответить

Классический космос

Простой
3

Скорее какой-нибудь азиатской ММО

Ответить
4

Вышлая, эх, вышлая...
Такая вот нелёгкая судьба моя

Ответить
2

Закрытый, платный, xaml - не нужно.

Ответить
0

Закрытый

PRO PER PROJECT дает тебе доступ к исходникам, расширения все вообще на гитхабе.

платный

INDIE бесплатная. Жалко правда там есть ограничения по платформам. Причем я без идей как оно работает (что вообще значит малина запрещена, а линукс разрешен?)

xaml

Это же и есть основная фишка...

Ответить
1

Ну такое, учитывая что аналогов до кучи, включая полностью открытые и бесплатные, так и коммерческие и известные.
Это же и есть основная фишка...

Весь мир отказывается от xml подобного синтаксиса, но только не мелкософт

Ответить
0

И переходит на "}}}}}}}}}}}} надеюсь ни одну не пропустил"?
Читаемость у xml для UI высокая, а скорость написания не важна если есть хороший тулинг.

Ответить
1

И переходит на "}}}}}}}}}}}} надеюсь ни одну не пропустил"

Не знаю формата с такими проблемами. Но если допустить что она есть, то она была бы и в xml и уж глазами даже без форматирования лучше парсить json и yaml.

У xml плохо все: размер, парсинг, читаемость, сложность формата, плохое стандартизирование. Падение программы при парсинге большого xml или уязвимости в парсере(одни из самых распространненых) это обычное дело.

Ответить
0

 Не знаю формата с такими проблемами

Очевидно, речь про json

 У xml плохо все

Давай отдельно разберем каждый пункт

размер

Больше повторов = выше эффективность зипования = похер на размер

 парсинг

В чем проблема найти повторяющиеся пары? Даже тупо регулярками легко

читаемость

Выше же. Поэтому html, который почти основной язык разметки вообще стал таковым

сложность формата, плохое стандартизирование

По сравнению с чем? Есть более удачные бинарные форматы, кто спорит.
Но по сравнению с трешом в json - это просто идеал, а о cdata там только мечатать могут. Кто хочет, тот то и делает по сути. Сам стандарт там по сути опеределил только то как записать словарь строка - строка. Если у вас другие данные - ваша проблема и ваш выбор

 Падение программы при парсинге большого xml или уязвимости в парсере

В .net всё довольно очевидно: xdocument если всё можно вместить в озу и xmldocument если нет. Я спокойно парсил террабайтные xml на не выдающемся железе через xmldocument и это не было каким-то ультра-мазахизмом, хоть и не так удобно как обычно.

Ответить
1

Очевидно, речь про json

Постоянно с ним работаю, этой проблемы не знаю, также как и неформатированным xml, в yaml в принципе не может быть.
Больше повторов = выше эффективность зипования = похер на размер

1) xml препятствует повторению и позволяет одну вещь сделать несколькими разными путями, что даже при архивировании увеличивает размер. cdata это один из примеров, спасибо
2) сжатие/расжатие это лишние ресурсы. Странно получать лишний оверхэд только от выбора формата, который ничем не лучше остальных
3) если хранить в бинарном сжатом виде, то эффективнее выбирать бинарные форматы, чем xml не является
Т.е. как несжатый он проигрывает, как сжатый проигрывает. Даже разница в несколько байт это: лишний пакет, промах кэша, лишняя страница памяти, еще одно вращение головки диска, вырубленный лес во владивостоке.
В чем проблема найти повторяющиеся пары?

Это немного тяжелее чем найти повторяющиеся пары, и вообще никаких проблем не представляет, если есть бесконечные ресурсы, бесконечное время, не требуется покрывать все разновидности стандарта и писать простой код. Если несколько из этих пунктов не подходят(а я сильно удивлюсь если это не так хоть где то на этой планете), то возникают нетривиальные проблемы: какой тип парсера выбрать, какую реализацию, какие параметры указать, что поддерживать, а что нет + безопасность для каждого типа схемы. Не то чтобы эти проблемы совсем не встречались в других форматах, но выражены они в горааааааздо меньшей степени: 3 разных типа парсеров и 2 генератора в них обычно не выделяют, я еще не встречал исследования "какой парсер json выбрать чтобы не падать на гигабайтном файле" или гайдлайна по безопасности в котором запрещалось использовать json.
Даже тупо регулярками легко

Ну да, ну да, расскажи это тысячам разработчикам xml парсеров. У людей сложности возникают даже формальную грамматику на подмножество xml описать.
Выше же. Поэтому html, который почти основной язык разметки вообще стал таковым

1) Шел 198x какой-то год, форматов в принципе особо нет(в том числе xml. который говорят придумали существенно позже!), а их известность определялась публикациями и личными знакомствами.
2) Разметка данных и структура данных это довольно разные вещи. Тот же html не особо используется как структура хранения данных. xml тоже не для этого создавался (в отличии от json и yaml), но используют его (в основном?) в таком ракурсе (зачем забивать гвоздь утюгом?).
3) html как раз критикуют за читаемость и даже за человекочитаемость. На это не только стандарт влияет, но в том числе и он. Даже в начале 2000х все было далеко от совершенства.
4) А для хранения данных во фронтенде и бэкэнде сейчас как раз властвует json (если не дремучее легаси).
По сравнению с чем? Есть более удачные бинарные форматы, кто спорит.

По сравнению с другими текстовыми человекочитаемыми форматами для структур данных - json, yaml. С ini сравнивать наверное не корректно, но он тоже распространен и тоже проще. В принципе придумать что-то тяжелее xml это надо постараться.
Но по сравнению с трешом в json - это просто идеал, а о cdata там только мечатать могут. Кто хочет, тот то и делает по сути. Сам стандарт там по сути опеределил только то как записать словарь строка - строка. Если у вас другие данные - ваша проблема и ваш выбор

Но даже с тем трешем с 6 разными документами описывающие стандарт json (как это напоминает первый html!) и не соответсвующими друг другу в некоторых деталях, проблем меньше, а вопросы если и возникают то в основном технические, примерно такие же которые решают и разработчики парсеров xml(разрешить или не разрешить закрывающую запятую). Самый большой трэш в json с комментариями, которые вообще крайне спорны и по-моему мнению в структурах данных не должны быть в принципе (комментарии в структурах данных либо не важны, либо уже сами по себе являются данными, а как известно парсеры обычно комментарии игнорируют) и хотя их json вообще говоря поддерживает, но не факт что поддерживает парсер. Но по сравнению с проблемами в xml это прям капля в море ("всем бы такие проблемы").
cdata

И это очень здорово. cdata это синтаксический сахар, вся суть для которого не экранировать определенный текст. Для написания парсера это боль (но ты же это знаешь, ведь делал парсер xml на регэкспах ), для производительности это боль, для стандарта это боль, причем вся эта боль постоянная, для пользователя чуть-чуть более удобно, что не надо поставить слэши перед некоторыми символами в довольно малопопулярных случаях(причем в json этих символов меньше, да и само экранирование проще).

Ответить
0

Предлагаю всё что про производительность и парсинг, кстати, вычеркнуть. Мы же тут про xaml всё же, а он обычно компилируемый (не знаю как в noesis, но в wpf, uwp и xamarin forms - да). То есть он парсится один раз момент сборки приложения и всё.

Ответить
0

Но ведь во время "компиляции" он все равно парсится.

Ответить
0

И какая разница? Сэкономить полторы мсек на компе разработчика разово?

Ответить
0

Да + человекочасы на написание собственного формата, либы, документации + время разработчиков на изучение всего этого + остальные достоинства которые я описал

Ответить
0

Сам стандарт там по сути опеределил только то как записать словарь строка - строка. Если у вас другие данные - ваша проблема и ваш выбор

Сюрприз! Именно это и требуется от формата структуры данных - предоставить одну форму для описания разных данных, а не по форме на каждый тип данных(иначе и сам формат не нужен, ты же сам писал про повторяемость и сжатие). Xml по сути делает то же самое в другом виде (теги и значения == ключи славаря и его значения) и гораздо более сложно.
В .net всё довольно очевидно: xdocument если всё можно вместить в озу и xmldocument если нет. Я спокойно парсил террабайтные xml на не выдающемся железе через xmldocument и это не было каким-то ультра-мазахизмом, хоть и не так удобно как обычно.

Было бы странно если бы .net плохо поддерживал свой главный формат для конфигов (хотя конфиги iis это одна из худших вещей в принципе). Либы для xml, json и даже для yaml есть во многих стандартных библиотеках для разных языков и обычно с ними со всеми в целом нет проблем, они пишутся профессионалами для большинства случаев, как можно проще для пользователя. Проблемы начинаются когда не обычно (справедливости ради комментарии в json как раз этот случай). Эти случаи тоже решаются гуглением, сравнением, выбором нужной библиотеки, написанием гайдлайнов, написанием своего парсера или даже конвертацией данных. Но зачем выбирать формат который не предназначен для хранения данных, не эффективен, сложен, плохочитаем, еще и требует дополнительной конвертации для взаимодействия с другим современным софтом, когда можно просто выбрать другой формат, одним решением? .net как я понимаю как и java используют его по причине легаси - в конце 90х xml сильно форсился под брендом серебренной пули, особенно в корпоративной среде, и у мелкософта до сих пор многое конфигурится именно в таком ключе, от docx файлов до конфигов драйверов(?).

Ответить
1

платная закрытая хрень? зачем новость по этому?
опенсурс ГУИ более чем достаточно, помимо очевидного imgui

Ответить
1

платная закрытая хрень? зачем новость по этому?

Вы Unity тоже не пользуетесь?

Ответить
2

очевидно, зачем пользоваться этим ужасом от вражеской корпорации из США, когда столько открытых движков, и в любом случае лучше написать свой движок

Ответить
0

Толсто.

Ответить

Комментарий удален

0

Инквизиция какая-то.

Ответить
0

А никто случаем фолыч не пилит на этом движке, ну так, в порядке предположения?

Я, если что, про движок от Larian в целом, а не про UI framework.

Ответить
0

Всё никак руки не доходят попробовать, по идее порог входа для разработчиков знакомых с WPF/UWP и другими майкрософтовскими UI/XAML штуками должен быть минимален.

Ответить
–1

Визард без книги. 

0/10, would not recommend

Ответить

Прямой эфир

{ "jsPath": "/static/build/dtf.ru/specials/DeliveryCheats/js/all.min.js?v=05.02.2020", "cssPath": "/static/build/dtf.ru/specials/DeliveryCheats/styles/all.min.css?v=05.02.2020", "fontsPath": "https://fonts.googleapis.com/css?family=Roboto+Mono:400,700,700i&subset=cyrillic" }