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

Я стараюсь держаться как можно дальше от любых технических оценок внутренних процессов, чтобы не походить на диванного футбольного болельщика, который точно знает, как его любимой команде нужно играть, но после прочтения октябрьского продюсерского письма даже при сознательно выбранном подходе мне пришлось серьёзно размышлять о том, не разместить ли эту информацию в рубрике «Холодный Кофе». Потому что сколько бы очков личных симпатий ни набрали авторы Pantheon в моих глазах, я не понимаю, как они с прежним подходом серьёзно планировали создать MMO.

В последнее время я считал, что главной угрозой для шансов Pantheon добраться до релиза была внезапная смерть идеолога проекта — Брэда Макквида — осенью прошлого года. Всё же это было огромное потрясение как для команды, так и для сторонников проекта. Но детали рассказанного в новом письме наглядно демонстрируют то, что никакая харизма идеолога неспособна вывезти проект, который просто неправильно сконструирован. Насколько неправильно? Давайте я лучше процитирую часть письма:

В конце 2018 года мы начали работу над тем, что назвали Проект «Faerthale». Он должен был собрать в себе все запланированные механики в играбельном виде. С учётом нашей крохотной команды, это был очень амбициозный вызов, но в то же время — логичный следующий шаг. И мы погрузились в работу. Весь 2019 год и большую часть 2020 мы занимались именно им.

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

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

И мы перестали «хардкодить». Мы взяли паузу, чтобы разработать инфраструктуру, без которой нам не выпустить нашу игру. Механики теперь разделены и могут редактироваться намного более эффективным, гибким способом. Зоны содержат только базовые очертания (graybox format). Даже контент, такой как расположение NPC, сюжетные линии и игровые задачи были переделаны так, чтобы дизайнеры создавали или редактировали их в удобной для себя среде. Отталкиваясь от ошибок первой версии, мы двигались к тому, как всё должно быть устроено. Это нужно было для того, чтобы действительно быстро двигаться вперёд в развитии проекта и поддерживать задуманный масштаб, которому Pantheon должен соответствовать. Прежняя версия нашей игры не могла это обеспечить. Это замедлило нас в реализации Проекта «Faerthale», но оно того стоило.

Это кажется невероятным — хардкодить механики, квесты или конкретное поведение NPC в локации — но подумайте о причинах такого подхода.

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

Pantheon взял за основу Unity, и долгое время использовал множество стандартных ресурсов этого движка. Сейчас, когда на одной из последних демонстраций, игра предстала в форме, лишённой временно заимствованных графических элементов движка, многие игроки возмутились, а кто-то вообще не понял, что происходит с игрой, и почему она стала «низкополигональной».

И это снова нас возвращает к проблеме ожиданий аудитории. В сентябре 2019 года команду разработчиков покинул Daniel Krenn, занимавший в компании пост CTO (Chief Technology Officer). Ему на смену пришёл Kyle Olsen, но мало кто, включая меня, обратил на это внимание. Кажется, что это естественно в шоу-бизнесе — программисты, остающиеся за кулисами, мало кому интересны. Вот только проблема в том, что MMO — это буквально программа, а в шоу-бизнес игра превращается не после выпуска, но иногда — задолго до.

Суровая правда жизни заключается в том, что все описанные выше движения понадобились Visionary Realms для поиска серьёзных инвесторов, которые не будут смотреть стримы. Как мы.

Они будут смотреть в том числе на технологический процесс. Оценивать его. Возможно, год назад Pantheon мог рассчитывать на новый раунд инвестиций, благодаря имени Брэда Макквида. Теперь — увы, нет. Теперь нужно демонстрировать нечто другое. И, наверняка, это пойдёт на пользу проекту. Потому что с прежним подходом Pantheon рисковал повторить трагедию старта Vanguard.

С 21 октября Pantheon перешёл в очень важную для его жизни фазу «Pre-Alpha 5». Хотя я понимаю, как для проекта, который стартовал много лет назад, звучит термин «пре-альфа», по словам разработчиков, именно в этой версии должны быть собраны все запланированные механики и общий прогресс персонажей с 1 по 50 уровни. Понятно, что при этом в игре также будет множество незаконченных частей, особенно в визуальном плане. Главное же, на что надеются авторы — можно будет достаточно хорошо ощутить игровой процесс. А заодно проверить, как работает новая архитектура разработки, насколько действительно быстро получится вносить изменения и двигаться вперёд. И, наконец, удастся ли впечатлить потенциальных инвесторов, чтобы «увеличить команду и существенно ускориться».

Автор:

Автор и основатель проекта «ММОзговед». Наш сайт сделан для того, чтобы все мы могли делиться своими впечатлениями о любимых MMO и мыслями по поводу важных для нас тем. У нас нет открытой или скрытой рекламы, мы принципиально работаем исключительно в интересах игроков. Если вы тоже считаете это важным, поддержите нас через Patreon. Вместе мы сможем больше.

9
  • Спасибо за вашу оценку!
    Узнайте, на что она влияет.

Поддержите ММОзговед через Patreon

Поддержать

$238 из $250 в месяц

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

Поддержать

7 комментариев

avatar
Вообще, всё это звучит очень странно… если не вспомнить, как первого Ведьмака из «глыбы камня вырубали», за пол года до релиза.
Могу вот что сказать в защиту… архитектура программной части игры может быть очень сложной, а желание «взять и сделать прямо сейчас» — безразмерно велико. И люди, которые хотят разрабатывать игры могут впадать в две крайности: много-много что-то думать и придумывать, тратя на это усилия и ничего реально не делая. Либо хардкодить. Оба подхода — провальны. Но когда очень хочется, но что-то не можется, получается вот так вот, как тут.
  • +1
avatar
Но хардкодинг для MMO, которая, по идее, должна развиваться после релиза годами, а ещё и чинить кучу косяков, которые вылезут, это как-то вообще.
  • +1
avatar
Конкретно в ММО тем в два раза больше… нет, даже в 4 раза больше проблем возникает, при попытках хардкодить.
И в целом, как я уже написал, ситуация очень странно выглядит.
Во первых — Unity изначально гибкая вещь для доступа к нутру как программистам, так и дизайнерам. А это значит два варианта: Дизайнеры вообще ничего не хотят знать (а что-то знать все же надо, с технической стороны). Либо там возникла «проблема одного человека», когда изначально всё писалось максимально закрыто и неудобно для стороннего доступа. А когда нужный человек исчез, поверх этого как-то, что-то накидывалось еще и еще, пока не превратилось в закрытую, непонятную и громоздкую систему.
И это приводит к третьей проблеме, о которой можно легко догадаться: в данной студии не нашлось (не осталось) людей, которые могли бы быть «переводчиками», разговаривая интересы обеих сторон. Как технической, так и дизайнерской. И не было хорошего архитектора, который бы знал КАК решать проблемы расширяемости.

ну и четвертое… Как мне кажется, команда слишком полагалась на доступные ассеты, не занимаясь разработкой своих. И когда, по какой-то причине, эти ассеты перестали их устраивать, остался лишь голый, обглоданный скелет. По сути, это тоже «хардкод», который можно и нужно иногда применять на фазе прототипирования, но от которого надо очень быстро начинать избавляться, как только проект пошел в работу и встал на коммерческие рельсы.
  • 0
avatar
И зы. огромное количество ММО страдает в процессе развития именно от хардкода, который сохранился с первых дней и кривого и заброшенного легаси-кода, который пережил кучу обновлений, пока не превратился в непонятно что и как работающую кучу хлама. И это проблема вообще всех крупных проектов.
  • +1
avatar
В любом софте хардкод на начальных этапах внедрения фич оправдан. Он начинает мешать тогда, когда фичу нужно развивать и модернизировать.

Мне только не очень понятно, разве в Unity из коробки или плагинами нельзя сделать расстановку NPC, сюжетные линии и задачи без необходимости лезть в код? Можно ведь. Редактор запускать придётся, да. Но в C# код, лезть же не потребуется.
  • 0
avatar
Вот про Unity это меня тоже удивляет… Там же из коробки достаточно гибкая система, доступная и людям от кода, и людям от — образно говоря — фотошопа.
  • 0
avatar
Лично для меня сама формулировка не совсем понятна. Когда дочитал до Unity запутался окончательно, т.к. слово «хардкод» в контексте заметки стало совершенно непонятным.

Программисты у них есть в любом случае, т.к. сервер писать исключительно ручками.(хотя, если пишите сервер сами, то куда удобнее плясать от его архитектуры, а не от архитектуры движка рендеринга) И каким бы куском… Кхм, байткода не был C#, это именно скриптовая часть движка и без нее вообще никуда. Нет, есть подозрения, что у них есть лицензия PRO и доступ к плюсам, но неужели они решили прямо в ядре писать игровую логику!? Это крайне сомнительно. Или я просто не могу поверить в такое. 0_о
  • +1
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.