Приветствуем воинов Кальрадии!

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

Это мы поняли при работе с пользовательским интерфейсом (UI) для Bannerlord. Раньше мы использовали комбинацию Flash и Scaleform для создания нашего пользовательского интерфейса, что на самом деле довольно распространенный метод в игровой индустрии. Мы начинали с создания пользовательского интерфейса во Flash, прежде чем использовать Scaleform, чтобы пользовательский интерфейс работал в игре. Технически оба Scaleform и Flash функционировали отлично и предоставляли нам возможность реализовать интерфейс так, как нам нравилось. Это шло на наш взгляд в пору со временем. Создавая новый интерфейс, мы ссылались на быстроразвивающуюся игровую индустрию, чтобы привлечь игроков. Однако не так давно мы заметили некоторые проблемы с общим процессом создания и внедрения пользовательского интерфейса, который, по нашему мнению, нам нужен. Итак, разложим по полочкам. Раньше программисты и дизайнеры использовали продукты стороннего разработчика и были ограничены в своих действиях и желаниях. Исходя из сложившихся проблем, они начали искать хоть какое-то решение. Было проведено много работы по-старому принципу, но дизайнеры и программисты, не были ей довольны. Так как у них были связаны руки, процесс был довольно медленным. Любые изменения в пользовательском интерфейсе должны были быть сделаны во Flash, прежде чем они будут реализованы в тестируемой игре. По мере усложнения экранов генерация .swf-файлов занимает больше времени. И с каждым изменением, которое мы сделали, игру нужно перезагружать, чтобы увидеть результат. Даже небольшое изменение, такое как перемещение элемента 5 пикселей влево, потребует пройти весь этот процесс.

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

Затем нам пришлось решать, какой будет наша новая библиотека пользовательского интерфейса. Мы составили список требований:
- Новая библиотека должна была быть быстрой и мгновенной. Команда нашего движка работала очень тяжело, чтобы оптимизировать её.
- Она будет использовать текстовый формат файлов спецификации, например, XML, поскольку текстовые файлы упрощают совместную работу нескольких разработчиков.
- Системе надо упростить создание интерактивных пользовательских интерфейсов.
- Макет пользовательского интерфейса должен быть независим от того, как он будет выглядеть визуально. Это позволит дизайнеру пользовательского интерфейса работать независимо от программиста.

Мы решили назвать наш новый интерфейс Gauntlet (без какой-либо иной причины, что мы думаем, это звучит круто!). С Gauntlet мы можем вносить изменения «на лету». Мы можем редактировать экран без закрытия игры не один раз, без создания файла или каких-либо дополнительных шагов. Когда мы вносим изменения в .xml-файл экрана, мы видим результаты, как только мы сохраняем этот файл. И поскольку у нас есть полный контроль над системой, мы можем вносить изменения в систему, как того требуют наши потребности.

Итак, как это работает? Ну, система на самом деле довольно проста. Мы прикрепляем XML-файл к экрану игры, который загружается при открытии экрана. Вся информация о макете для экрана указана в этом файле. Мы также можем ссылаться на другие .xml-файлы в каждом .xml, что означает, что, если мы создадим элемент пользовательского интерфейса, который, как нам нужен, мы будем использовать его более одного раза (то есть на других экранах), мы можем просто ссылаться на этот элемент. Это позволяет нам вносить изменения в файл, и эти изменения произойдут везде, где мы ссылаемся на этот .xml.

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

Мы надеемся, что Gauntlet станет приятным подарком для нашего сообщества моддинга. В Warband редактирование пользовательского интерфейса всегда было головной болью, и были некоторые ограничения, которые невозможно было преодолеть. С Gauntlet мододелы будут иметь полный контроль над каждым экраном, единственным ограничением будет являться их воображение.

 

В блоге на следующей неделе мы поговорим с помощником дизайнера, Cihan Şekercioğlu. Если у вас есть какие-либо вопросы, которые вы хотели бы задать ему, пожалуйста, оставьте вопрос в комментариях, и мы ответим на него.

Перевёл Драгхун для commando.com.ua
MOUNT BLADE 2 BANNERLORD (основное)
Об игре