Драконье Стекло или рассказ о игровом редакторе Larian Studios

    larian_dublin_logo Привет, Хабр! Это снова Larian Studios. Уф, у нас прошёл релиз, и теперь наконец-то появилось время продолжить делиться с вами нашим опытом и наработками.

    Сегодня я расскажу о самом главном инструменте, с помощью которого родилось уже 4 проекта — о кофемашине внутреннем редакторе игры. Редактор доступен в ограниченном (для моддеров и игроков) виде в Steam/GoG, поэтому каждый, кто приобрел игру, может скачать его и попробовать бесплатно.

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

    Ну и еще расскажу, чем занимаются Tools Programmer в нашей студии.

    «Человек есть животное, владеющее инструментами. Нигде вы не найдете человека без его инструментов. Без них он ничто, с ними всё.»
    Томас Карлейль

    «The Divinity Engine Toolset» (или как мы его называем, «Glasses») — это внутренний инструмент, игровой редактор, используемый Larian для создания своих игр. Его история началась с «Dragon Commander» и продолжается на протяжении уже 6 лет. Состоящий из большого количества компонентов, он объединяет в себе инструменты как для геймдизайнеров, левелдизайнеров, скриптеров, так и для аниматоров и художников. Наш редактор — это постоянно меняющийся и растущий организм, который постоянно адаптируется под новый стек технологий и список требований каждого отдела студии, поэтому основное его свойство — это модульность и легкость в подключении новых plugin'ов.

    А что лежит в основе?


    Все наши игры написаны с использованием C++, и Glasses является дополнительной надстройкой над игрой, что позволяет нам повторно использовать функционал движка для реализации необходимых задач. Таким образом, например, пользователи редактора могут играть в игру, не выходя из него и не запуская еще один процесс, что сильно облегчает тестирование квестов, атмосфер и боевых сцен.

    Изначально игровой редактор был написан с использованием WinForms, поэтому связующим звеном между инструментарием и игрой является C++/CLI прослойка, которая позволяет транслировать структуры данных из игры в редактор и vice versa. Разумеется, одним WinForms сыт не будешь, поэтому так же используются сторонние фреймворки, как например ScintillaNet для редактора скриптов.

    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. И нам мало! Так что если вдруг у вас есть желание помочь нам и поучаствовать в разработке очень крутого движка — пишите и приходите к нам =)
    Larian Studios 71,18
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 22
    • 0
      Занятно. Было бы интересно почитать про то, как их команда смогла, цитирую:
      полностью перенести его функциональность в редактор

      Чтоб такие вещи реализовать, нужно ещё и в самой предметной области разбираться.
      Сейчас у нас в команде 5 программистов
      А какие у них компетенции? То есть, кто-то инструментами для работы с системами частиц занимается, кто-то тулзы для анимаций пишет?
      • +1
        А какие у них компетенции? То есть, кто-то инструментами для работы с системами частиц занимается, кто-то тулзы для анимаций пишет?


        Самые разные, ведь у нас не выделено четких ролей, и задачи люди получают грубо говорят в порядке очереди =) Если проект большой им занимается несколько человек одновременно. Со временем появляется какая-то область ответственности за выполненные задачи, но это обусловлено бОльшим опытом при работе с данной задачей. Так что по сути все занимаются всем.
      • –6

        После Divine Divinity остальное не оч.

        • +5

          Смелое заявление после двух сверхуспешных Original Sin...

          • 0
            В некоторое остальное соло (одним персонажем) не предполагается играть. Поэтому в это остальное не все и играют. Для меня лично эти две последние игры… может и успешные, но играть я в них не будут, потому что не мой стиль игры.
            • 0
              Талант «одинокий волк» специально для соло игры в обеих играх. Все там нормально с этим
              • 0
                Да только играют им в дуо, а не соло. Под соло прохождение игра в принципе не рассчитана насколько я помню со слов разработчиков.
                • 0

                  Bioware, возможно, тоже не рассчитывали что Baldur's Gate-ы вдоль и поперёк соло пройдут, однако ж задротят только в путь.


                  Divinity Original Sin 2 не далеко ушла. На макс сложности люди изи-пизи лица крушат всем:
                  Tactician Solo Alexander (спойлеры!)

                  • 0
                    Baldurs Gate я и сам соло проходил, там механика игры это позволяет изначально, и совсем не на легкой сложности. В орижинале я ожидал подобного, но не увидел. То, что некоторые это делают через поедание кактуса, да пожалуйста, я не отношусь к этим энтузиастам настолько. Есть другие игры на которые можно потратить свое время и деньги и получить удовольствие.
                    • +1

                      Пока что я понял следующее — когда небо было голубее, Вы с радостью ели кактус и проходили BG соло, а сейчас Вы повзрослее и времени на поедание того же кактуса, но в D:OS уже нет.


                      Но это же не проблема игры, а Ваша.

                      • 0
                        Не правильно поняли. В БГ играя соло вы получаете кратный опыт, т.е. в 6 раз больше. Это позволяло развиваться чуть быстрей и тянуть игру без кактуса и совсем не одним классом на выбор.
                        При этом игрок получал кап развития ближе к концу и мог даже на нем поиграть в удовольствие.

                        Ну и про зеленее, я уже давно вырос, и различаю те эмоции испытываемые первый раз от новых игр, с теми что я сейчас ожидаю от игры. Если игра мне нравиться, я найду на нее и 500-700 часов в год. Правда таких игр сейчас не много.
                  • 0

                    Во второй части никакого дуо нет, если что (проверено).

                    • –1

                      Я почти прошёл вторую часть, играя вдвоём на геймпадах 2-мя одинокими волками (сплитскрин).
                      Что значит "дуо нет"?

                      • 0
                        Имелось ввиду «обязаловки» т.е. что можно играть соло без спутников и это не будет выглядеть как пожирание кактуса.

                        Но даже если и так, играть в сиквел подобной игры, не играя в первую часть, как минимум будет странным. А играть в первую через ни хочу я не буду. Но это мое мнение) есть минимум 1.5кк игроков которым понравилась первая часть и минимум 850к кому понравилась вторая часть. А таких как я и сотни может не наберется.
                        • +3
                          Вторая часть сделана сюжетно независимой от первой и разворачивается через 1000 лет после окончания предыдущей части. Вы можете спокойно начинать её, не боясь потерять в истории или атмосфере.
                        • 0

                          А, ну да. Еще там есть трио и квартет.

            • 0
              Original Sin EE портирована под Линукс. Как ваш инструмент дружит с этой системой? Есть какие-то интересные особенности? Очень жду поддержки Original Sin 2.
              • +1
                Игровой движок вполне дружит с линукс, но так как наш инструмент привязан к .NET — его портирование не планируется. Что же касается переноса игры на разные платформы — об этом мы пока не говорим, работая над поддержкой Windows версии
                • 0
                  Очень жду порта линукс!
              • 0
                Я понимаю, что у вас так исторически сложилось, но интересно вот что: есть ли вообще смысл в 2017 году разрабатывать собственный движок, когда есть, как минимум, Unity, UE, CryEngine и Source?
                • 0

                  Только если движок должен обеспечивать что-то такое мудреное, чего нет в существующих решениях.

                  • 0
                    Хороший вопрос!
                    Первое и очевидно преимущество — это полная свобода в развитии движка и легкости изменений архитектуры под наши нужды (читай — вчера наследование, сегодня компонентная система — в нашем случае переход был сделан менее чем за месяц). Последний пункт достигается за счет хорошего знания нашего движка всей командой. Т.е. мы его писали и мы очень хорошо представляем как работает каждая его деталь, никаких скрытых или не документированных фичей. Также мы не зависим от «поставщика услуг». Переход на его новые версии не ломает всю текущую код базу, например как это бывает со сторонними движками. Ну и разумеется никаких роялти =)

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

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

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

                  Самое читаемое