Привет, Хабр! Это снова Larian Studios. Уф, у нас прошёл релиз, и теперь наконец-то появилось время продолжить делиться с вами нашим опытом и наработками. Сегодня я расскажу о самом главном инструменте, с помощью которого родилось уже 4 проекта — о
В статье я проведу обзор основной функциональности, коснусь некоторых архитектурных решений и расскажу немного о процессе его разработки и поддержки. Если понравится — в следующих статьях расскажу подробно о каждом элементе редактора в отдельности.
Ну и еще расскажу, чем занимаются Tools Programmer в нашей студии.
«Человек есть животное, владеющее инструментами. Нигде вы не найдете человека без его инструментов. Без них он ничто, с ними всё.»
Томас Карлейль
«The Divinity Engine Toolset» (или как мы его называем, «Glasses») — это внутренний инструмент, игровой редактор, используемый Larian для создания своих игр. Его история началась с «Dragon Commander» и продолжается на протяжении уже 6 лет. Состоящий из большого количества компонентов, он объединяет в себе инструменты как для геймдизайнеров, левелдизайнеров, скриптеров, так и для аниматоров и художников. Наш редактор — это постоянно меняющийся и растущий организм, который постоянно адаптируется под новый стек технологий и список требований каждого отдела студии, поэтому основное его свойство — это модульность и легкость в подключении новых plugin'ов.
А что лежит в основе?
Все наши игры написаны с использованием C++, и Glasses является дополнительной надстройкой над игрой, что позволяет нам повторно использовать функционал движка для реализации необходимых задач. Таким образом, например, пользователи редактора могут играть в игру, не выходя из него и не запуская еще один процесс, что сильно облегчает тестирование квестов, атмосфер и боевых сцен.
Изначально игровой редактор был написан с использованием
WinForms? Ой-ой..
И правда, но это было раньше. Сейчас редактор удачно мигрировал на WPF, и, благодаря модульной архитектуре, производить переход можно было «на лету», т.е. вводить новые фичи и плагины уже на WPF с возможностью обращения к старым окнам и опциям на WinForms. Надо отметить, что WPF довольно сильно сократил время разработки новых контроллов и окон, а так же позволил повысить общее качество интерфейса редактора.
Одно кольцо, чтоб править всеми
В любом большом проекте рано или поздно участники начинают использовать систему контроля версий. Кто-то копирует на флешки, кто-то использует git, мы в Larian используем perforce (p4). И если использование p4 программистами сложностей не вызывает — все довольно легко интегрируется в среды разработки, то с остальными отделами все может быть сложнее. Отсутствие информации о статусе файлов в системе контроля версий вынуждает дизайнеров, художников ставить дополнительные инструменты и усложнять процесс создания контента («перед началом работы надо обязательно сделать check out, иначе файл может быть read-only» и т.д.). Поэтому интеграция системы контроля версии в игровой редактор — это задача, решающая очень много проблем разом. Основная идея: «чем меньше художник, дизайнер думает о сторонних факторах, aka порядок выгрузки файлов или добавление новых файлов в систему контроля версий», тем больше у него времени на свои настоящие задачи. Вроде бы просто, но в то же время очень сильно повышает эффективность.
Следуя выше описанной идее, мы стараемся сократить количество сторонних инструментов, используемых нашими сотрудниками, вынося всю функциональность в виде плагинов к редактору. Вот еще один пример: изначально вся «математика» и данные игры (как часто будет выпадать это оружие, сколько урона наносит этот fireball, сколько жизней у этого стражника) находились в уютных таблицах excel, которые с помощью VB скриптов экспортировали данные в виде текстовых файлов в необходимом для игры формате. Это довольно быстрое и простое решение работало до момента, пока количество людей, работающих над игровыми данным, не выросло до такой степени, что нескольким людям потребовалось постоянно работать в одном файле, мерджить (merge) excel таблицы — задача не очень тривиальная, а вариант наложить ограничение «один человек — один файл» создает эффект бутылочного горлышка, и разработка сильно замедляется. Что же делать? Так появился Stats Editor — недавно сделанный плагин, который позволяет не только работать непосредственно с необходимым текстовым файлом напрямую с помощью нашего UI, но и так же совершать проверку вводимых данных, позволяя избежать многих часов дебага из-за одного неправильно поставленного значения.
Кстати, уменьшение зависимости от сторонних приложений повышает качество пользовательского контента, сделанного моддерами. Ведь чем меньше им надо устанавливать и настраивать, тем опять же больше они могут сфокусироваться на реализации свои идей.
All Spark
Также помимо небольших плагинов мы смогли полностью интегрировать довольно большие программы и сторонние редакторы. Например, VFX-редактор. Изначально VFX-художники пользовались отдельным инструментом, но команда программистов смогла полностью перенести его функциональность в редактор, позволив художникам редактировать и создавать эффекты прямо в игре. Позволяя объединять различные анимированные эффекты, регулируя и модернизируя их, пользователь может создавать огромное количество визуальной «магии», начиная от заклинаний, навыков и заканчивая эффектами окружающей среды и даже работой с камерой. Я бы с удовольствием рассказал об этом подробнее, но это скорее тема для отдельной статьи.
Моддинг
Glasses — это редактор позволяющий создавать модификации к вышедшей игре. Что происходит, когда ты даешь игровой редактор игрокам? Реальным становиться всё, что казалось сложным или невозможным. Энтузиазм моддеров и игроков в желании создавать крутые вещи очень силен, и поэтому одной из наших задач было сделать редактор максимально доступным самой широкой аудитории. Потому что чем проще инструмент, тем больше появится дополнительного контента, а это очень сильно увеличивает цикл жизни игры. Все это приводит команду разработчиков к принятию важных архитектурных решений, которые позволяют добавлять, удалять и перезаписывать контент без ущерба для игры и текущего прогресса. В нашем случае это решение заключалось в разбитии игровых сущностей на «аддоны» и «проекты/приключения».
Если конкретнее, то обе сущности представляют собой набор данных (предметы, модели и скрипты), которые игрок может подключить к своей игре.
Аддоны представляют собой «data packs» (паки контента), т.е. независимый набор моделей уровней, который любой игрок может подключить куда угодно. Наш опыт показывает, что если огромные пользовательские приключения добавляют очень много в игре, то небольшие модификации позволяют людям быстрее и проще экспериментировать с игровой логикой, подключая и отключая необходимые в нашем случае аддоны. Например, если игрок хочет добавить в игру больше различного оружия (и это не привязано к истории основной игры), или добавить цепочку новых квестов, для этого ему совершенно не нужно создавать большой проект, а достаточно все упаковать в небольшой независимый файл, который игроки по своему усмотрению смогут включать и передавать, не боясь, что их сохранения сломаются. Одним из примеров аддонов так же может быть набор уровней для режима «Гейм Мастера», где аддон — это фактически добавление нового контента, на основе которого игрок с ролью «гейм мастера» сможет создавать свои собственные истории.
Приключения. Если пользователь хочет сделать что-то огромное, с историей, с пересекающимися квестами и независимое от основной игры, — то этот тип модификаций как раз для него. Тут надо будет и работать со скриптами, и заниматься левел-дизайном и прочими крутыми штукам, которыми занимаются сотрудники Larian Studios для создания своей игры.
А что еще есть?
Очень много всего. Как я уже упоминал, это основной инструмент для разработки наших игр. Редактор включает в себя:
- Инструмент «Genome» для созданий анимаций, эффектов animation blending и т.д.
- Редактор для игровых скриптов.
- Конечно же инструментарий для создания уровней, и их редактирования. Работа с terrain, атмосферами, декорированием уровней и т.д.
- Возможности редактирования mesh'ей персонажей и создания целых наборов визуальных элементов для каждого вида существ; например, если хочется, чтобы один и тот же предмет по разному смотрелся на существах различного строения (нам не хотелось, чтобы один и тот же элемент снаряжения выглядел одинаково на эльфах, людях и гномах).
- Инструмент для работы с локализацией.
- Редактор диалогов.
- Дополнительная визуализация. Разные триггеры, коллайдеры разной формы и типов должны быть визуально понятны и видны работающему с ними пользователю, поэтому запуск игры в редакторе позволяет увидеть их точное расположение и форму — так гораздо легче, например, контролировать игровую атмосферу в зависимости от передвижения игрока по уровню.
- Редактор освещения. Мы используем PBR (physically based rendering) для создание реалистичного света. Для этого мы используем light probes и рассказ о их логике и генерации —
это точно отдельная статья. - Функциональность, позволяющая создавать и редактировать AI шаблоны, и AI сетку, помогающая combat designers создавать интересные сражения.
- Мощный редактор материалов.
А что-то говорили про Tools Programmer?
Вокруг этой позиции витает очень много неясных ассоциаций и одна из них утверждает, что «Tool Programmer не делает игру, а делает инструментарий для сотрудников компании и не имеет большого отношения к разрабатываемой игре». Этакий «программист на реализацию хотелок художников и дизайнеров».
Это совсем не так. Кто и делает игру — так это Tools Programmer. Постоянно маневрируя между двумя архитектурно разными проектами (игра и редактор), разработчик редактора является практически единственным в компании человеком, который всегда держит руку на пульсе каждой новой фичи в игре, будь то gameplay фича или новое дизайнерское решение. Интеграция новых технологий, инструментов и сторонних решений выполняется исключительно только Tools Programmer, потому что только он знает, как добавить ту или иную функциональность в доступном для людей не технического склада ума виде. Зачастую когда Gameplay и Engine разработчики замкнуты в своих собственных текущих задачах, именно Tools Programmer'у надо решать архитектурные вопросы, которые установят и наладят процесс разработки во всех частях студии на несколько лет вперёд.
Сейчас у нас в команде 5 программистов, занимающихся непосредственно разработкой The Divinity Engine Toolset. И нам мало! Так что если вдруг у вас есть желание помочь нам и поучаствовать в разработке очень крутого движка — пишите и приходите к нам =)
