- PVSM.RU - https://www.pvsm.ru -
В декабре прошлого года, на конференции Games Gathering 2017, мы сделали доклад [1], в котором рассказали о том, надо ли компаниям, работающим в игровой индустрии, писать собственные движки.
Зачем в современном мире, в котором существуют такие гиганты, как Unity, делать что-то своё, писать собственные игровые движки?
Перед вами слайд с данными компании Unity Technologies по использованию различных игровых движков в 2017 году. В следующем году ситуация, как вы понимаете, поменяется. Нас интересует то, чему тут отведён 41%, то есть — движки собственной разработки. Если взглянуть на 5 самых больших компаний, представленных на конференции, то у каждой из них будет свой движок. Получается, что в большей части компаний, представляющих игровую индустрию, используются какие-то внутренние разработки. Далеко не всегда это — самое разумное в мире решение, но это так.
Из каких базовых технологий могут выбирать компании, задумывающиеся о разработке игрового проекта?
Пирамиду, которую вы видите на слайде, можно продолжить и вверх, и вниз. Она абсолютно чётко вас ограничивает. Снизу — операционная система, ещё ниже — какие-то базовые технологии. Сверху — аддоны над движками, готовый инструментарий, который поставляют с играми, вроде инструментов Neverwinter Nights. Что бы вы ни делали, вы, так или иначе, оказываетесь внутри этой штуки.
Предположим, я хочу оказаться на втором уровне этой пирамиды снизу. Однако все пути, в итоге, ведут в верхнюю часть пирамиды. Мы будем использовать и что-то из существующего, но весьма важно и то, что можно видеть в левом верхнем углу верхнего уровня пирамиды, то есть — движки собственной разработки.
Теперь проанализируем затраты времени, сил и средств, необходимых на разработку игры.
Если вся показанная на слайде круговая диаграмма — это игра, то движок — это её синий сектор. В идеальном мире, разрабатывая игру, вы можете вынуть этот синий сектор и поставить туда красный, или желтый, или зеленый. Можно одно большое «U» поменять на другое большое «U», или взять некое маленькое «x», и то, что вы выбрали, там тут же заработает. В реальности это не так, но мы должны к этому стремиться. Подобная картина, если речь идёт о реальных проектах, наблюдается в игровой индустрии постоянно. Бывает и так, что вся эта диаграмма занята движком, но это справедливо лишь для каких-то демонстрационных продуктов.
При этом деньги, время и всё остальное распределяется именно так. Чтобы вы ни делали, вам придётся заниматься еще всем тем, что попадает в зелёную область диаграммы. Она от движка к движку не меняется. В результате, если у вас есть ресурсы, достаточные для поддержки всего процесса работы над игровым проектом, то разработка движка окажется не такой уж и дорогой. Однако если кто-то в компании начинает говорить о разработке собственного движка, он, вероятнее всего, столкнётся с определённым набором возражений. Рассмотрим их.
Предположим, вы решили создать собственный движок и сообщили об этом человеку, принимающему решения. В ответ вы услышите примерно то же самое, что можно видеть на слайде: «Делать ты это будешь долго, это очень рискованно, это нерационально, это не поможет нам достигнуть наших целей». Что можно на это ответить? Дело тут в том, что все эти возражения, кроме последнего, не выдерживают никакой критики.
Долгая разработка движка? Но если разработка с собственным движком пойдёт быстрее, то это — не аргумент. О том, что такое «рационально», пожалуй, вообще никто не знает. Поэтому все эти возражения очень субъективны.
Последний пункт, касающийся того, способствует ли свой движок достижению целей — это очень важно. Если ваша цель — заработать благодаря получению гранта от Unreal 4, то, наверное, свой движок делать не надо, потому что он не ведёт к этой цели. Если у вас есть цель, в рамках которой вам надо что-то делать на определенных технологиях, то не надо писать свой движок — надо брать то, что есть. Но эффективно использовать готовые движки можно далеко не всегда. Зачем же, всё таки, писать свой движок?
Когда может понадобиться собственный движок? Разберём этот слайд по пунктам:
Вот вам история. В одной компании на сайте было задание для программистов, выглядящее примерно так: «Ребята, если хотите у нас работать, напишите пожалуйста «Астероиды», которые должны запускаться на платформе Android без использования внешних библиотек. Мы считаем, что на это вам достаточно 8 часов. Время пошло». Потом время увеличили до 12 часов. Может быть, выглядит это смешно. Сначала я наблюдал за этим, снаружи, потом заглянул в эту компанию и попросил рассказать мне о том, что прислали в виде отклика на это задание. Как оказалось, отбор прошли больше двухсот программ, то есть — эти программы запускались и работали. Это значит, что если вы вдруг захотите издать «Астероиды» для Android, то найдется как минимум 200 человек, которые могут это сделать за 8 часов. Я не говорю, что это можно продавать. Но рассказал я эту историю к тому, что очень часто, собственно, движок — это и есть Time to Market. Скажем, просто потому, что у вас такие маленькие потребности, что вы дольше будете изучать документацию на тот же Unreal, чем просто взять и сделать своё.
У Warner имеется 120 миллионов пользователей этой услуги. Если вы пишете туда софт, и игры в том числе, то вы имеете доллар с коробки. Это 120 миллионов долларов в год. При этом кроме вас писать для этой штуки не может больше никто. Потому что там нет DirectX, там вообще ничего нет. Если вы умеете писать программы для STB — то вы властелин платформы, вы имеете эти сто двадцать миллионов долларов в год. Чем не повод писать свой движок?
Понятно, что мы сейчас больше говорим про что-то вроде консольных игрушек, но, тем не менее, в некоторых ситуациях это может понадобиться. Вот, например, слот-машины. Конечно, там сейчас, в основном, компьютеры. Но перед нами отдельное железное устройство и огромный рынок, для которого вполне можно писать что-то своё.
Можно говорить, что нас интересуют телефоны, но речь идёт о миллионах долларов. Почему бы не писать для других устройств? В результате, есть абсолютно четкие причины это делать.
Или, например, перед нами новейшие смарт-часы. SDK к ним ещё не вышел, никто не понимает, что с ними делать, а если вы сможете, своими силами, написать для них качественный продукт, то вы, скажем, заработаете по доллару с каждого такого устройства. Если их будет продано два миллиона — то вам достанется два миллиона долларов. Написать это несложно, но для этого надо делать свой движок, потому что чужих нет, а компании-производители таких устройств не будут делать общедоступные движки для разработки под них.
Половина устройств на рынке построена на базе чипсета Mali-400 от ARM, любой бюджетный телефон это Mali-400. И если вам платят за то, что вы занимаетесь телефонными приложениями, то вы должны писать для этих вот маленьких, но гордых устройств, которые пока уходить с рынка не собираются и уйдут с него очень нескоро.
При этом в случае с iPhone можно делать хоть какие-то ставки на прогресс. Например, ожидается, что Unreal будет работать под iPhone 10, хотя пока всё это доведут до ума, будет уже какой-нибудь iPhone 12, 15 или 17. А вот в случае с миром вообще в краткосрочной перспективе на прогресс ставить тяжелее. Потому что апгрейд устройств происходит очень медленно.
Если вы хотите конкурентную картинку, и если это очень важно, вы не идёте на маломощные устройства. Но вы должны учитывать, что все современные движки не очень масштабируются вниз. Если же вы не хотите конкурентной картинки, то, соответственно, учитываете возможности слабых телефонов. Поэтому, если вы находитесь в ситуации, когда вам интересны не самые быстрые устройства, например, вы — единственный дистрибутор где-нибудь в Португалии или в Бразилии, то вам придётся об этом задуматься.
Стандартные движки пытаются охватить всех. На самом деле мы видим, как они пытаются делать естественные доменные преобразования из языка в язык и из пространства в пространство. Но для всех. А у вас есть собственные идеи, и вы можете реализовывать их напрямую, делая собственный набор инструментов. Понятно, что всё это, в виде плагинов, можно делать и поверх существующих движков, но свой движок открывает совсем другие возможности.
То есть, существует большое количество механик, для которых стандартные, большие, универсальные движки не подходят просто потому, что они предназначены для всего. Поэтому если вы завтра придумаете что-то особенное, какие-то сложные воксельные механизмы, то работать со стандартными движками вам будет неудобно. То есть, существуют механики, для которых стандартные движки не подходят, и которые достаточно просто реализовать самостоятельно.
Причины для разработки собственного движка мы рассмотрели. Остановимся теперь на том, какие преимущества даёт компании разработка собственного движка.
Рассмотрим преимуществах разработки своего движка, опираясь на основные идеи, вынесенные на слайд:
Если кто-то работал на мобильных технологиях, то вы всё понимаете. Если на коробке движка написано: «10 процентов роялти», то это категорически неприемлемо, вы не заработаете столько. У вас может быть прибыль сто процентов, но вы работаете из 2-х. То есть, если у вас есть роялти, то это чисто экономическая причина отказа от движка. А надо сказать что три, точнее — два из самых популярных на сей момент движков — это как раз вопрос отчислений. То есть такой вариант сразу отпадает.
У вас есть 2 варианта действий: либо их переучивать так, как положено с точки зрения best practices, либо использовать своё. Есть простые примеры. Предположим, вы говорите: «Мы импортируем 3D-модели». Вы не знаете — что там с той стороны. Поэтому вам нужен промежуточный формат. Промежуточный формат пускай будет FBX. Огрехи FBX все, кто этим занимаются, знают. А вам некуда деваться, потому что вы не знаете, что там будет делаться, вы не будете писать плагины под 450 средств 3D-моделирования.
Когда вы работаете внутри своей компании, то вы можете реализовать тот самый пайплайн, который у вас уже существует и надеть на него сверху то, чем вы занимаетесь. На самом деле, это очень важно. Дело в том, что всё это имеет отношение ко времени разработки и, как следствие, к стоимости. Поэтому, когда вы разрабатываете у себя, вы можете утилизировать тот пайплайн, который уже есть. Иначе у вас документ, который называется «Правило выгрузки 3D-моделей и создания материалов для художников» будет больше, чем дизайн документ, а это неправильно.
Скажем, в соседнем офисе сидят люди, которые делают движок. Каждый, кто пытался исправить баг в универсальном движке, то есть написать в багтрекер Unity или Epic, знает, что лучше даже не начинать. А если разработчики сидят в соседнем офисе, то вы можете к ним обратиться и решить вопрос за 15 минут.
То же касается и предложения нового функционала, если у вас есть на это право. Исследование новых технологий так же упрощается при использовании собственных движков.
Предположим, ваш программист съездил на конференцию, послушал там лекцию о чём-то новом. Он тут же это попробовал, вы получили представление об этом новом и знаете, нужно оно вам или нет. Вы можете прямо-таки реактивно пробовать что-то интересное из мира науки. А это, кстати, значит, что в компании может быть человек, который будет называться «исследователь». При этом исследованиями можно заниматься и на том же Unreal, поскольку он поставляется в исходниках.
Разработка собственного движка — это не только преимущества. Это ещё и риски. Рассмотрим их.
Рассмотрим риски сопровождающие разработку и использование собственных движков:
Программисты, которые знают эту технологию, по сути, ничего больше не умеют. Это можно считать одним из факторов, помогающих удерживать сотрудников. Поэтому ответ на вопрос о том, хорошо это или плохо, является ли использование собственных технологий риском, зависит от конкретной ситуации. Мы, например, стараемся не использовать концепций собственного изобретения. Например, мне известна одна компания, у которой есть Lua, строго типизированный, с паскалевским синтаксисом. Это можно освоить, но это знание мертвое, как греческий язык. Мы так стараемся не поступать.
Рассмотрим очень важный вопрос. Какой ресурс требуется в первую очередь для разработки собственного движка? Ресурс, без которого бессмысленно задумываться о том, надо или не надо делать собственный движок. Ответ на него, конечно, не 42. Вопрос в том — что вообще нужно, чтобы просто хотя бы иметь возможность сказать: «Да, у нас хоть что-то есть, мы можем начать что-то делать». Ответ на этот вопрос заключается в том, что для разработки собственного движка нужны программисты.
Для того чтобы создать собственный движок, нужны программисты. Если не знаете — погуглите разницу между словами «developer» (разработчик) и «programmer» (программист). Это очень важно. Девелоперы — это основная группа. Игровая индустрия так устроена, что большинство людей в ней программистами назвать нельзя. Извините, но они разработчики. Разработчики не способны грамотно сделать движок. Опять же, если взглянуть на разницу между первыми и вторыми, то разработчики делают игры, а программисты делают инструменты. Разработчики делают продукт, компания зарабатывает за счёт продукта, но инструменты должны быть сделаны программистами, иначе они просто не будут работать.
С одной стороны, сейчас очень открытый мир. Я, например, знаю код Unreal 4 и CryEngine, он открыт. Все, кто хотят знать, могут узнать код Unity, есть огромное количество соответствующих материалов. Это значит, что этим способен заниматься тот, кто является программистом и читает по-английски. Там нет какого-то rocket science. Но с другой стороны, как выяснилось, программистов, которые читают по-английски, найти очень непросто. Поэтому вы должны знать, где они водятся, должны уметь их набирать, использовать, поощрять. Если вы это умеете, то можно уже и о своём движке задуматься. Если у вас таких людей нет, то у вас всё равно ничего не получится. Примеров тому — тьма. Дело не в том, что есть плохие и хорошие решения. Просто есть такие вещи, которые не могут работать изначально.
Программистов надо уметь нанимать. Умеете нанимать — можете делать движок. Не умеете нанимать — тогда надо брать что-то готовое. Причём, самое смешное, что когда вы берете что-то готовое, то вам, если вы — большая компания, всё равно понадобится два человека вот из этих программистов, читающих по-английски.
Если для разработки движка нужны программисты, то у нас сразу же возникают несколько вопросов. Где искать программистов? Как организовывать их работу? На что стоит обращать внимание, размышляя о путях развития игровых компаний?
Сейчас уместно вспомнить ещё об одном аспекте поиска сотрудников, который касается, преимущественно, больших компаний. У таких компаний есть несколько подходов к подбору персонала.
Во-первых, можно набирать людей, джунов, устраивая интернатуры, и, обучая их внутри компании, каким-то образом растить до нужного уровня. Это — нормальный подход. При этом решается и множество технологических проблем, потому что с человеком, который изначально воспринимает корпоративную культуру и изучает определённые технологии, легче найти общий язык.
Во-вторых, есть подход, который мы, в принципе, и исповедуем. Как работает кефир? Он всё вокруг превращает в себя. Берёте молоко, кидаете туда кефир — и нет молока, всё превратилось в кефир. У нас это выглядит так: «Ребята, давайте возьмём 5 сильных программистов, это будет внутренний технологический центр». И я всем говорю, что если вы можете себе позволить сделать RnD-отдел, если вы — большая компания — то сделайте. Пускай они даже ничего, с точки зрения денег, полезного не делают. Если компания укрепилась на рынке и перед ней возникает вопрос о том, куда расширяться, то ответом на этот вопрос может стать создание RnD-отдела. Когда компания уже богата, для неё это не потеря денег, потому что она столько денег теряет уже на том КПД, на котором сейчас работает наша игровая индустрия, что расходов на исследования просто не заметит.
Теперь рассмотрим подход, который заключается в том, что в компании организуют команду, которая делает движок или какие-то другие интересные вещи. Это — работа на будущее. Вы можете проводить собеседования, говорить о том, что вы даёте деньги, у вас интересная задача, вы делаете движок. Вы можете выбирать из соискателей, люди к вам идут, и внутри компании у вас всегда есть такая атмосфера, когда вы человека можете мотивировать, поощрять и в результате достигать поставленных целей.
У меня, скажем, какие-то модули разрабатываются продуктовыми компаниями, потому что им это надо. То есть, заказана физика, и вместо того, чтобы пилить какие-то свои штуки, мы говорим: «Давайте так. Мы просто придумываем общие интерфейсы, несколько генерализированных, и вы будете это делать». А в рамках типовых задач это очень хорошо. То есть, в принципе, хорошо распространять технологии внутри компании.
Если компания уже настолько большая, что может себе позволить делать что-то интересное внутри себя, то это окупается даже с точки зрения денег. Поэтому если можете — то пробуйте. Выглядеть это может как угодно — скажем, делается своя ветка Unreal и там перерабатываем всё так, как хочется вам. Я, например, в одной из компаний делал браузер, который помещается в 2.5 мегабайт памяти. И он работал. Зачем — я не знаю, но это было бесконечно интересно.
Выше мы упоминали о проблеме игровых компаний, которая заключается в организации эффективного взаимодействия программистов и дизайнеров. Остановимся на этой проблеме подробнее.
Наступил момент продемонстрировать вам рабочее место нашего геймдизайнера. Это — реальная картинка. Тут показана какая-то демка, реализация поведения, чуть позже мы остановимся на этом подробнее.
В игровой индустрии соседствуют два мира. Люди либо ориентированы на решение технологических задач, либо на нарратив. А посередине — кустарщина какая-то. То есть, инструментария практически нет. Слова, слова, слова — бах — код. Опять слова — и опять код. Мы считаем, что требуются инструменты, которые позволяют подключать к тому, что получится в результате работы над игрой, геймдизайнера, менеджера, других сотрудников, не являющихся программистами.
На слайде можно видеть behavior tree, дерево поведения. В принципе, это штука, просто взятая из википедии, но перед нами её оттуда взял Unreal. Ничего страшного в этом нет. Итак, документация к этому лежит на сайте Unreal, нам было несложно сделать подходящий интерфейс, совместимый с тем, что делается в Unreal. То есть, можно взять любой пример с анриловского сайта экшнов, пример самого поведения, так как формат вполне совпадает, вот так вот переписать, и оно заработает. Это значит, что я облегчил себе жизнь, я не пишу документацию. И таких штук здесь много.
В примере со слайда что-то происходит, бегает краб, кого-то ловит, в общем-то, это неважно. Внутри программист решает задачи, которые выглядят как «пойди в…», «стрельни в…», «посчитай расстояние» — и всё. Всё остальное поведение написано в этом редакторе человеком, который не имеет абсолютно никакого отношения к программированию. И это работает, в отличие от перевода текста в код. При этом если говорить, скажем, о балансе. Что такое баланс? Это — 15 коэффициентов, которые можно менять. А здесь описано поведение, а не коэффициенты.
То есть, например, поведение «патрулирование» описано геймдизайнером, а не программистом. Это значит, что мы сделали тот шаг, которого большая часть людей не делает. Они просто пишут в дизайн-документе: «патрулирует». А программист это может перевести 50 разными способами. Что такое вообще патрулирование? А здесь геймдизайнер пишет именно то, что он имеет в виду. И это победа, друзья мои. Именно для этого вам нужны собственные инструменты. Для того чтобы сглаживать переход от вербального определения вашего визионера, который видит игру, так сказать, внутри головы, до программистов. А иначе они перестанут быть программистами, станут девелоперами и всю жизнь будут рассаживать травку.
Подведём итоги. Мы говорили о поводах писать свой движок. Скажем, если вы смотрите назад, на устаревшие устройства, то это не хорошо и не плохо. То есть, вы хотите, чтобы ваши игры запускались на некоем диапазоне устройств, которые сейчас уже не поддерживаются коммерческими движками. При этом вы хотите современно выглядеть. Как этого добиться? Писать своё.
Вы хотите владеть платформой? У вас специфический проект, который просто не требует использования универсальных решений? Или у вас, наоборот, очень большой и сложный проект со специфической картинкой? В этих ситуациях, опять же, можно задуматься о своём движке. При этом для того, чтобы сделать свой движок, нужны ресурсы. А ресурсы — это программисты.
В результате, если вы имеете поводы писать свой движок, и у вас есть ресурсы — берите и пишите.
Какова стоимость вашего движка, если оценивать её в деньгах и в трудозатратах?
Сколько это стоило в деньгах, я, наверное, сейчас не могу сказать. А если говорить о трудозатратах, то это девять месяцев команды из шести человек. Но надо понимать, что это наша последняя разработка, и тут мы целимся достаточно высоко. Я не рассказываю о нашем наборе инструментов, о том, что мы делаем с Lua, или о том, что мы делаем с JavaScript такого, что не делает вообще никто. Мы планируем выпустить в опенсорс пару модулей, которые, если и не перевернут индустрию, то, как минимум, помогут людям осознать — что такое скриптовые языки. Наш предыдущий движок делали два человека четыре месяца. Он — тоже 3D, но попроще, телефонный. Можно быстрее, я уже рассказывал, как «Астероиды» пишут за 8 часов, но это, конечно, далеко от реальности.
Сколько времени потребовалось на реализацию дерева поведения?
Это я могу точно сказать, делалось это совсем недавно. Два человека занимались этим месяц. Но проблема тут шире, чем создание дерева поведения. Дело в том, что экшны у нас пишутся в Lua, занимает это, наверное, дня четыре, а написать редактор на Qt — месяц.
Насколько я понимаю, вы используете Lua, у вас есть экшн-система, которую вы изначально написали, а дерево поведения просто дёргает эти экшны?
Да, так и есть. На самом деле, мы работаем над тем, чтобы вывести это в опенсорс, пишем документацию, систему сборки, примеры.
Наша компания имеет очень схожие взгляды с вашими, и проблемы у нас тоже интересные возникают. Хотелось бы узнать — какое у вас соотношение трудозатрат на игру, на движок, на инструменты? То есть, сколько людей, например, работает над движком, над игрой, сколько игр используют один движок?
У нас сейчас два движка, предыдущая редакция и новая. То есть это не рефакторинг. Это полностью новый движок. Если говорить о трудозатратах, то можно сказать, что компания у нас большая, работает около 500 человек, программистов около 250, 5 офисов. Проектная команда работает над играми. Проект — это некая игра, и ей занимается некоторое количество людей. Команда разработки движка — это отдельный коллектив. Это — тот самый кефир, о котором я говорил, элитные подразделения, там немножко другие деньги и подходы к формированию команд. Сейчас мы немного обгоняем разработку. Две новые игры запущены на новом движке. Это достаточно мучительно, так как разработчикам игры не очень комфортно, потому что они работают в ситуации, когда у них что-то может буквально из-под рук взять и взорваться. И у нас команда движка — это 6 человек. Команды продуктов — это, в среднем, человека по четыре программиста, они не пересекаются.
Под движком вы подразумеваете и инструменты тоже?
Да, у нас есть отдельная команда по разработке инструментов. У нас был очень неудачный пример. Очень плохо разрабатываются GUI-инструменты. Потому что любой нормальный программист считает, что это очень просто. Мы попытались это аутсорсить. Потому что понятно — ты отдаёшь полный интерфейс, у тебя всё есть, ты говоришь: «Создай окно, нарисуй кнопки — и всё». Но эта затея провалилась, поэтому сами делаем, мучительно работаем с Qt, потому что нам важно, чтобы это работало на всех трёх настольных платформах. Поэтому сами делаем. И у нас 6 человек делают и то, и другое, и третье. Но мы всё равно находимся чуть впереди запросов продукта.
Реально ли сейчас продать свой движок?
Нет. Сейчас нельзя продать свой движок. Можно продать экосистему. То есть, работать по схеме «дай мне денег, а я тебе дам движок» нельзя. Обратите внимание на то, сколько у нас компаний имеет собственный движок, и сколько из них движки продаёт. На самом деле — никто из них движки не продаёт. Для начала — это достаточно большая головная боль с точки зрения того, что это надо превратить в продукт. То, что у вас работает внутри компании, никак нельзя продать. Вы должны, как минимум, написать документацию, которую поймут окружающие. Вы должны нанять просто какую-то армию волонтёров, которые будут это дело евангелизировать. И не вполне понятно, что вы с этого получите. А если сделать мобильную игру на этом движке, то вполне можно проснуться миллионером. Поэтому, чтобы такие вещи делать, надо быть фанатом, надо быть уверенным в том, что делаете. Я рассказывал о причинах, которые могут привести к разработке своего движка, а у вас тут — ещё одна причина. Скажем, вы думаете, что сделаете движок лучше, чем Unreal. Если это так — идите на рынок. Но я не думаю, что сделаю лучше, чем Unreal.
Я так понимаю, что ваш новый движок — это С++ и Lua?
Да, C++, Lua и ещё JavaScript.
А почему C++? Были ли варианты, или вы чётко знали, что именно возьмёте?
Смотрите, существует такая мода. Каждый второй, кого встречаешь, говорит тебе: «Golang», или говорит тебе: «Rust». И если бы это было сейчас, я бы в принципе задумался. Но когда ты приходишь в компанию руководителем процесса разработки движка, а было это год назад, тебе надо строить какие-то планы, а так придётся включать в эти планы пункт «Почитать о Go». Тут ведь важна производительность, а на C++ мы достаточно давно работаем, умеем им пользоваться.
А почему мы используем Lua? Потому что это недооценённый язык, он отлично подходит для встраивания. Почему JavaScript? Потому что так получилось. Потому что на рынке кроме V8 и Webkit ничего нет. А это монстроиды. Как я уже говорил, мы делали браузер, который занимает 2.5 мегабайт памяти, там есть JavaScript-движок, который проходит все тесты. У нас это есть, и вот поэтому — JavaScript. В результате, например, можно брать тех, кто знает JS и писал сайты на React.
Скажите, вы дерево поведения используете только для управления поведением, или применяете его ещё для управления игровыми механиками и для продвижения игрового прогресса?
Сейчас для поведения, но у нас еще есть несколько альтернативных механик. У нас есть ещё, скажем, сети Петри с редактором, а тут проблема немножко другая, которая заключается в том, что сети Петри тяжело объяснить гейм-дизайнеру. Есть ещё какие-то вещи с редакторами, которые позволяют нарисовать, скажем, конечный автомат. И мы пытаемся из этого всего что-то сделать. Мне теперь надо заставить тех людей, которые пишут сценарии, писать это вот в таком вот виде. Так что дерево поведения сработало, а остальное пока ещё в рабочий процесс не вошло.
Насколько трудно прогнозировать развитие технологий на будущее? То есть, как сложно предвидеть появление каких-то подводных камней и тому подобных вещей?
На данный момент я вижу одну проблему. Сейчас интересно выглядит технология WebAssembly. Flash умер. Мы хотим, естественно, издаваться ещё где-то на вебе. Портировать игру, скажем, с Unity на WebGL — это задача, которая не решается нажатием на одну кнопку. То есть сейчас мы смотрим на WebAssembly и пока неясно — будет ли это стандартом, или нет, начинать сейчас с этим работать, или подождать. В мобильных технологиях тоже ничего особенного не происходит. Нет пока каких-то сингулярных взрывов, но если будут — будем готовиться.
В итоге хочу сказать, что при нормальном модульном дизайне, при нормальном проектировании, а я очень сильно надеюсь, что у нас они нормальные, когда появляются новые технологии, можно просто вынуть старое из движка, поставить туда новое, и всё будет работать.
Автор: eztiger
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/292475
Ссылки в тексте:
[1] доклад: https://www.youtube.com/watch?v=CT77PY9yrZE
[2] Источник: https://habr.com/post/423175/?utm_campaign=423175
Нажмите здесь для печати.