Главная » Игры » Зачем писать свой игровой движок?

Зачем писать свой игровой движок?

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

Unity в условиях многообразия игровых движков

Зачем в современном мире, в котором существуют такие гиганты, как Unity, делать что-то своё, писать собственные игровые движки?

В следующем году ситуация, как вы понимаете, поменяется. Перед вами слайд с данными компании Unity Technologies по использованию различных игровых движков в 2017 году. Если взглянуть на 5 самых больших компаний, представленных на конференции, то у каждой из них будет свой движок. Нас интересует то, чему тут отведён 41%, то есть — движки собственной разработки. Далеко не всегда это — самое разумное в мире решение, но это так. Получается, что в большей части компаний, представляющих игровую индустрию, используются какие-то внутренние разработки.

Из каких базовых технологий могут выбирать компании, задумывающиеся о разработке игрового проекта?

Армия семи наций

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

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

Теперь проанализируем затраты времени, сил и средств, необходимых на разработку игры.

Назад, к основам

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

Чтобы вы ни делали, вам придётся заниматься еще всем тем, что попадает в зелёную область диаграммы. При этом деньги, время и всё остальное распределяется именно так. В результате, если у вас есть ресурсы, достаточные для поддержки всего процесса работы над игровым проектом, то разработка движка окажется не такой уж и дорогой. Она от движка к движку не меняется. Рассмотрим их. Однако если кто-то в компании начинает говорить о разработке собственного движка, он, вероятнее всего, столкнётся с определённым набором возражений.

Мифический человеко-месяц

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

Но если разработка с собственным движком пойдёт быстрее, то это — не аргумент. Долгая разработка движка? Поэтому все эти возражения очень субъективны. О том, что такое «рационально», пожалуй, вообще никто не знает.

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

13 причин почему

Когда может понадобиться собственный движок? Разберём этот слайд по пунктам:

  • Time to Market — срок вывода продукта на рынок. Это — по-настоящему серьёзно. Половина из тех движков, которые сейчас используются в больших компаниях, разработаны именно потому что в тот момент, когда этой компании надо было быстро быстро занимать нишу, разработать своё было быстрее, чем взять что-то чужое и осваивать это.

Вот вам история. В одной компании на сайте было задание для программистов, выглядящее примерно так: «Ребята, если хотите у нас работать, напишите пожалуйста «Астероиды», которые должны запускаться на платформе Android без использования внешних библиотек. Мы считаем, что на это вам достаточно 8 часов. Время пошло». Потом время увеличили до 12 часов. Может быть, выглядит это смешно. Сначала я наблюдал за этим, снаружи, потом заглянул в эту компанию и попросил рассказать мне о том, что прислали в виде отклика на это задание. Как оказалось, отбор прошли больше двухсот программ, то есть — эти программы запускались и работали. Это значит, что если вы вдруг захотите издать «Астероиды» для Android, то найдется как минимум 200 человек, которые могут это сделать за 8 часов. Я не говорю, что это можно продавать. Но рассказал я эту историю к тому, что очень часто, собственно, движок — это и есть Time to Market. Скажем, просто потому, что у вас такие маленькие потребности, что вы дольше будете изучать документацию на тот же Unreal, чем просто взять и сделать своё.

  • Lord of the Platform — властелин платформы. Существуют платформы, для которых нет готовых инструментов. Например, STB, set-top box (ресивер цифрового телевидения) — коробочка для кабельного телевидения, которая стоит на столе у каждого третьего американца.

У Warner имеется 120 миллионов пользователей этой услуги. Если вы пишете туда софт, и игры в том числе, то вы имеете доллар с коробки. Это 120 миллионов долларов в год. При этом кроме вас писать для этой штуки не может больше никто. Потому что там нет DirectX, там вообще ничего нет. Если вы умеете писать программы для STB — то вы властелин платформы, вы имеете эти сто двадцать миллионов долларов в год. Чем не повод писать свой движок?

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

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

  • Weak but proud devices — малые, но гордые устройства. Если вы делаете игры для мобильных телефонов, собираете хоть какую-то статистику, то вы знаете, что с аппаратным обеспечением у устройств от Apple всё более-менее нормально, а вот с платформой Android — просто беда.

Половина устройств на рынке построена на базе чипсета Mali-400 от ARM, любой бюджетный телефон это Mali-400. И если вам платят за то, что вы занимаетесь телефонными приложениями, то вы должны писать для этих вот маленьких, но гордых устройств, которые пока уходить с рынка не собираются и уйдут с него очень нескоро.

Например, ожидается, что Unreal будет работать под iPhone 10, хотя пока всё это доведут до ума, будет уже какой-нибудь iPhone 12, 15 или 17. При этом в случае с iPhone можно делать хоть какие-то ставки на прогресс. Потому что апгрейд устройств происходит очень медленно. А вот в случае с миром вообще в краткосрочной перспективе на прогресс ставить тяжелее.

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

  • Own language for own ideas — собственные языки для собственных идей. Когда вы сами делаете движок — вы можете задействовать эту концепцию. Дело в том, что основная проблема нашей индустрии в том, что домен геймдизайнера — это филология. Он мыслит на обычном языке. Он ничего другого не умеет. А программист мыслит в домене программирования и между ними пропасть. Как результат, некая итерация, которую приходится непрерывно повторять, стоит, например, два доллара. И вы постоянно тратите эти деньги.

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

  • Unique Mechanics = Unique engines — уникальные механики = уникальные движки. Мои знакомые писали Minecraft в пятнадцатом году с использованием Unity. Был ли смысл всё это делать — вопрос открытый. Но движок они выбрали и принялись за работу. Однако движок им, очевидно, очень мешал. Им было тяжело. У них были очень долгие итерации. После того, как мы их проконсультировали, они написали, буквально за три дня, собственный рендер. Причём весь остальной код, ответственный, скажем, за построение мира, естественно, никуда не делся. Просто всё это перестало быть в C#, перестало быть в Unity. И работа закипела. Не знаю, удалось ли им на этом заработать, но главный вывод из этой истории заключается в том, что им изначально не надо было использовать Unity.

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

  • The game is not a render — the game is everything else — игра это не рендер, игра — это всё остальное. Мы об этом уже говорили. Если у вас проблема только в том, чтобы нарисовать что-то, или, скажем, использовать звук, делая многоплатформенную игру, то в рассмотренной ранее пирамиде можно было видеть подобные истории. Если вы говорите: «Я хочу проигрывать звук на трёх платформах», то вам для этого не нужна большая «U» — маленькой «c» будет вполне достаточно.

Причины для разработки собственного движка мы рассмотрели. Остановимся теперь на том, какие преимущества даёт компании разработка собственного движка.

Преимущества разработки своего движка

Рассмотрим преимуществах разработки своего движка, опираясь на основные идеи, вынесенные на слайд:

  • Buying is often better than mortgage — покупка часто предпочтительнее ипотеки. Игровая разработка — это, так или иначе, деньги. Есть способы монетизации, при использовании которых покупка не просто лучше, чем ипотека, а это просто единственно возможный вариант.

Если кто-то работал на мобильных технологиях, то вы всё понимаете. Если на коробке движка написано: «10 процентов роялти», то это категорически неприемлемо, вы не заработаете столько. У вас может быть прибыль сто процентов, но вы работаете из 2-х. То есть, если у вас есть роялти, то это чисто экономическая причина отказа от движка. А надо сказать что три, точнее — два из самых популярных на сей момент движков — это как раз вопрос отчислений. То есть такой вариант сразу отпадает.

  • Specificity is better than universality in the long term — на длинной дистанции специализированные инструменты всегда лучше универсальных. Очевидно, что универсальность всегда медленнее, она менее производительна и менее специфична, чем специализированные вещи. Движок, написанный под конкретную задачу, справится с ней лучше и быстрее, чем универсальное средство. На длинной дистанции специальные инструменты гораздо выгоднее, чем универсальные.
  • Tools and pipelines are developed within — пайплайны и средства разработки, созданные внутри компании. Любой движок, придуманный людьми вне вашей компании, ориентируется на несколько вещей. Первая — это best practices. То есть ориентируется движок другой компании не на то, как ваш художник рисует, а на то, как рисуют художники, идеальные с их точки зрения. Вполне возможно, что ваши художники рисуют по-другому. У них свой пайплайн и у них это получается.

У вас есть 2 варианта действий: либо их переучивать так, как положено с точки зрения best practices, либо использовать своё. Есть простые примеры. Предположим, вы говорите: «Мы импортируем 3D-модели». Вы не знаете — что там с той стороны. Поэтому вам нужен промежуточный формат. Промежуточный формат пускай будет FBX. Огрехи FBX все, кто этим занимаются, знают. А вам некуда деваться, потому что вы не знаете, что там будет делаться, вы не будете писать плагины под 450 средств 3D-моделирования.

На самом деле, это очень важно. Когда вы работаете внутри своей компании, то вы можете реализовать тот самый пайплайн, который у вас уже существует и надеть на него сверху то, чем вы занимаетесь. Поэтому, когда вы разрабатываете у себя, вы можете утилизировать тот пайплайн, который уже есть. Дело в том, что всё это имеет отношение ко времени разработки и, как следствие, к стоимости. Иначе у вас документ, который называется «Правило выгрузки 3D-моделей и создания материалов для художников» будет больше, чем дизайн документ, а это неправильно.

  • Reaction time — время реакции. Речь идёт о времени реакции производителя движка на ваши обращения, о возможности оснащения движка новым функционалом, и об оперативном исследовании новых технологий.

Скажем, в соседнем офисе сидят люди, которые делают движок. Каждый, кто пытался исправить баг в универсальном движке, то есть написать в багтрекер Unity или Epic, знает, что лучше даже не начинать. А если разработчики сидят в соседнем офисе, то вы можете к ним обратиться и решить вопрос за 15 минут.

Исследование новых технологий так же упрощается при использовании собственных движков.
Предположим, ваш программист съездил на конференцию, послушал там лекцию о чём-то новом. То же касается и предложения нового функционала, если у вас есть на это право. Вы можете прямо-таки реактивно пробовать что-то интересное из мира науки. Он тут же это попробовал, вы получили представление об этом новом и знаете, нужно оно вам или нет. При этом исследованиями можно заниматься и на том же Unreal, поскольку он поставляется в исходниках. А это, кстати, значит, что в компании может быть человек, который будет называться «исследователь».

  • Performance — производительность. Игровая индустрия — это всегда производительность. Первый подход достижения высокой производительности заключается в использовании специальных решений. Чем более специфичные решения — тем они производительнее. Второй подход — тоже, кстати, уважаемый, это оптимизация готовых движков. Как именно это будет выглядеть — сильно зависит от этих движков.

Разработка собственного движка — это не только преимущества. Это ещё и риски. Рассмотрим их.

Риски, связанные с разработкой своего движка

Рассмотрим риски сопровождающие разработку и использование собственных движков:

  • Development time — время разработки. Это понятие пересекается с тем, что мы говорили о времени выхода на рынок. Разработка движка может быть и очень долгой, и достаточно быстрой. Но время разработки движка, в любом случае, вносит вклад в общее время разработки проекта. Поэтому это тоже риск. Например, мне известны коллективы, у которых время разработки движка стремится к бесконечности.
  • Terminal cases of vendor-lock — терминальные случаи привязки к поставщику. Это относится не только к большим компаниям, но и к маленьким. Скажем, вы наняли Васю, он написал движок, потом влюбился, от вас уволился, и в том, что он написал, не понимает никто. В результате у вас vendor-lock похлеще Google. Потому что в Google еще можно письмо написать, хотя они и не ответят, а здесь с уходом программиста всё закончилось. В результате — потерянное время на разработку и другие неприятные последствия. Надо уметь избегать этих рисков.
  • Reinvent the wheel — изобретение колеса. Тут дело в том, что мы живём в мире, в котором вы всё равно изобретаете велосипеды. При разработке движка получается перенос велосипедного завода из кода игры в код движка, хотя там им и не место.
  • Closed ecosystem — закрытая экосистема. Всё, что делается внутри компании, принадлежит этой компании. Я знаю кучу компаний, у которых есть что-то вроде своего скриптового языка. Это может быть какой-нибудь XScript, который работает только в рамках их решения.

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

Главный вопрос жизни, вселенной и всего такого

Рассмотрим очень важный вопрос. Какой ресурс требуется в первую очередь для разработки собственного движка? Ресурс, без которого бессмысленно задумываться о том, надо или не надо делать собственный движок. Ответ на него, конечно, не 42. Вопрос в том — что вообще нужно, чтобы просто хотя бы иметь возможность сказать: «Да, у нас хоть что-то есть, мы можем начать что-то делать». Ответ на этот вопрос заключается в том, что для разработки собственного движка нужны программисты.

Программисты

Для того чтобы создать собственный движок, нужны программисты. Если не знаете — погуглите разницу между словами «developer» (разработчик) и «programmer» (программист). Это очень важно. Девелоперы — это основная группа. Игровая индустрия так устроена, что большинство людей в ней программистами назвать нельзя. Извините, но они разработчики. Разработчики не способны грамотно сделать движок. Опять же, если взглянуть на разницу между первыми и вторыми, то разработчики делают игры, а программисты делают инструменты. Разработчики делают продукт, компания зарабатывает за счёт продукта, но инструменты должны быть сделаны программистами, иначе они просто не будут работать.

Я, например, знаю код Unreal 4 и CryEngine, он открыт. С одной стороны, сейчас очень открытый мир. Это значит, что этим способен заниматься тот, кто является программистом и читает по-английски. Все, кто хотят знать, могут узнать код Unity, есть огромное количество соответствующих материалов. Но с другой стороны, как выяснилось, программистов, которые читают по-английски, найти очень непросто. Там нет какого-то rocket science. Если вы это умеете, то можно уже и о своём движке задуматься. Поэтому вы должны знать, где они водятся, должны уметь их набирать, использовать, поощрять. Примеров тому — тьма. Если у вас таких людей нет, то у вас всё равно ничего не получится. Просто есть такие вещи, которые не могут работать изначально. Дело не в том, что есть плохие и хорошие решения.

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

Где искать программистов? Если для разработки движка нужны программисты, то у нас сразу же возникают несколько вопросов. На что стоит обращать внимание, размышляя о путях развития игровых компаний? Как организовывать их работу?

Техническая эпидемия

Сейчас уместно вспомнить ещё об одном аспекте поиска сотрудников, который касается, преимущественно, больших компаний. У таких компаний есть несколько подходов к подбору персонала.

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

Как работает кефир? Во-вторых, есть подход, который мы, в принципе, и исповедуем. Берёте молоко, кидаете туда кефир — и нет молока, всё превратилось в кефир. Он всё вокруг превращает в себя. И я всем говорю, что если вы можете себе позволить сделать RnD-отдел, если вы — большая компания — то сделайте. У нас это выглядит так: «Ребята, давайте возьмём 5 сильных программистов, это будет внутренний технологический центр». Если компания укрепилась на рынке и перед ней возникает вопрос о том, куда расширяться, то ответом на этот вопрос может стать создание RnD-отдела. Пускай они даже ничего, с точки зрения денег, полезного не делают. Когда компания уже богата, для неё это не потеря денег, потому что она столько денег теряет уже на том КПД, на котором сейчас работает наша игровая индустрия, что расходов на исследования просто не заметит.

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

То есть, заказана физика, и вместо того, чтобы пилить какие-то свои штуки, мы говорим: «Давайте так. У меня, скажем, какие-то модули разрабатываются продуктовыми компаниями, потому что им это надо. А в рамках типовых задач это очень хорошо. Мы просто придумываем общие интерфейсы, несколько генерализированных, и вы будете это делать». То есть, в принципе, хорошо распространять технологии внутри компании.

Поэтому если можете — то пробуйте. Если компания уже настолько большая, что может себе позволить делать что-то интересное внутри себя, то это окупается даже с точки зрения денег. Я, например, в одной из компаний делал браузер, который помещается в 2. Выглядеть это может как угодно — скажем, делается своя ветка Unreal и там перерабатываем всё так, как хочется вам. И он работал. 5 мегабайт памяти. Зачем — я не знаю, но это было бесконечно интересно.

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

Два мира

Наступил момент продемонстрировать вам рабочее место нашего геймдизайнера. Это — реальная картинка. Тут показана какая-то демка, реализация поведения, чуть позже мы остановимся на этом подробнее.

Люди либо ориентированы на решение технологических задач, либо на нарратив. В игровой индустрии соседствуют два мира. То есть, инструментария практически нет. А посередине — кустарщина какая-то. Опять слова — и опять код. Слова, слова, слова — бах — код. Мы считаем, что требуются инструменты, которые позволяют подключать к тому, что получится в результате работы над игрой, геймдизайнера, менеджера, других сотрудников, не являющихся программистами.

В принципе, это штука, просто взятая из википедии, но перед нами её оттуда взял Unreal. На слайде можно видеть behavior tree, дерево поведения. Итак, документация к этому лежит на сайте 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 ничего нет. 5 мегабайт памяти, там есть JavaScript-движок, который проходит все тесты. Как я уже говорил, мы делали браузер, который занимает 2. В результате, например, можно брать тех, кто знает JS и писал сайты на React. У нас это есть, и вот поэтому — JavaScript.

Вопрос

Скажите, вы дерево поведения используете только для управления поведением, или применяете его ещё для управления игровыми механиками и для продвижения игрового прогресса?

Ответ

Сейчас для поведения, но у нас еще есть несколько альтернативных механик. У нас есть ещё, скажем, сети Петри с редактором, а тут проблема немножко другая, которая заключается в том, что сети Петри тяжело объяснить гейм-дизайнеру. Есть ещё какие-то вещи с редакторами, которые позволяют нарисовать, скажем, конечный автомат. И мы пытаемся из этого всего что-то сделать. Мне теперь надо заставить тех людей, которые пишут сценарии, писать это вот в таком вот виде. Так что дерево поведения сработало, а остальное пока ещё в рабочий процесс не вошло.

Вопрос

Насколько трудно прогнозировать развитие технологий на будущее? То есть, как сложно предвидеть появление каких-то подводных камней и тому подобных вещей?

Ответ

На данный момент я вижу одну проблему. Сейчас интересно выглядит технология WebAssembly. Flash умер. Мы хотим, естественно, издаваться ещё где-то на вебе. Портировать игру, скажем, с Unity на WebGL — это задача, которая не решается нажатием на одну кнопку. То есть сейчас мы смотрим на WebAssembly и пока неясно — будет ли это стандартом, или нет, начинать сейчас с этим работать, или подождать. В мобильных технологиях тоже ничего особенного не происходит. Нет пока каких-то сингулярных взрывов, но если будут — будем готовиться.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Тандем автора и эксперта: как сделать его эффективным?

В августе RUVDS и контент-студия Хабра провели семинар «Как мотивировать автора, даже если он программист». По итогам мы решили опубликовать некоторые интересные, на наш взгляд, доклады в нашем блоге. Журналисты писать умеют, но им нужна фактура. Эксперты обладают знаниями — ...

Мой любимый файл в кодовой базе Chromium

Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы ...