Игры более чем другие виды искусства зависят от технологий. Мы говорили о том, как придумывать виртуальные миры, как их проектировать, а теперь поговорим о том, какой ценой достигается их стабильная и плавная работа. Особенности игровых движков, производство крупных игр для мобильных платформ и многое другое мы обсудили с техническим продюсером компании Social Quantum Егором Новиковым. 

Привет, расскажи немного о себе и о том, чем ты занимаешься. 

Я технический продюсер в компании Social Quantum. Руковожу программистами, а также всей технической частью проекта. В нее входит: тестирование, техарт и все, что касается технических аспектов. Начинал я с Unity-программирования, еще когда был студентом. Потом отошел от геймдева и пошел в разработку рендеров на C++. 

Раз мы затронули эту тему, расскажи, насколько легко или тяжело дался переход с Unity на Unreal Engine?

У меня не было как такого перехода. Я начинал с unity и C#. Потом уже был чистый C++. На нем я работал в отрыве от коммерческих движков, и вот тогда плавно перешел на Unreal. Сначала мы его использовали как редактор для нашего собственного движка. То есть мы быстро мастерили на нем сцены, чтобы затем воссоздавать их у себя. Я делал плагины для UE4, затем их разработка плавно перешла в геймплей. К тому времени, на Unreal пробовать идеи было гораздо быстрее и лучше, чем если бы мы их делали с нуля. Таким образом я стал программировать на UE4. 

Если я правильно понимаю, вы сейчас разрабатываете на Unreal проект для мобильных платформ?

Да, все так.

Тогда расскажи поподробнее о том, в чем особенности работы с Unreal Engine при фокусе на мобильных платформах? Потому что мне кажется, что для смартфонов все преимущественно делают на Unity. 

Можно порассуждать, почему Unity считается более популярным движком для мобильных устройств. На мой взгляд, с технологической точки зрения, Unreal дает тебе больше возможностей. У Unreal, по сравнению с Unity, есть преимущество — ты можешь сделать игру на блюпринтах. На блюпринтах спокойно могут разрабатывать гейм дизайнеры, а еще это выгодно с точки зрения обновлений приложения.  Обновление обычно идет через App Store или GooglePlay. Т.е. если ты меняешь код игры — меняются dll, и необходимо проходить процесс ревью со стороны стора. В случае, если ты обновляешь только контент, то тебе этого делать не нужно. Блюпринты с точки зрения UE4 — это контент. Чем больше ты вкладываешься в блюпринты, тем больше ты может откладывать программные апдейты. Плюс у тебя есть доступ к исходным кодам. У Unity с этим сложнее. 

Насколько вам было принципиально получить исходный код?

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

А вы сейчас делаете большой проект относительно мобильных устройств, или это в абсолютном значении большой проект для любых платформ? 

Да, это большой мобильный проект с упором на качество консольных проектов. Мы делаем survival action RPG в открытом мире. Все это с мультиплеером, конечно. Понятно, что планируется и сингловая кампания, но там будет возможность поиграть в PvP или PvE со своими друзьями. 

А что вас мотивировало создавать большой проект для смартфонов? 

Наша студия изначально ориентирована на мобильные платформы. У нас есть экспертиза в этом формате, поэтому вопроса о платформе не стояло. Почему большой? Потому что, во-первых, технологии доросли. Во-вторых, челлендж. Мало кто за такое берется на рынке. Можно взять гигантов, типа PUBG, Fortnite, Genshin Impact, но они все исчисляются единицами. Сделать что-то подобное — челлендж, и у нас есть уверенность, что мы его выполним. 

Сколько человек над проектом работает?

Всего — более пятидесяти человек. Сложно сказать точные цифры, потому что много работает на аутсорсе. Кто-то приходит, кто-то уходит, но костяк - около пятидесяти человек.

Давай вернемся к сложностям разработки. О каких еще интересных особенностях ты можешь рассказать?

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

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

А так всегда. Любые ограничения мы можем преодолеть технически, геймдизайнерски или левел-дизайнерски. Например, мы не можем позволить себе  большие открытые пространства. Давайте сделаем больше рельефа, гор, максимально заокклюдим то, что мы не видим сейчас. Это левелдизайн, а с геймдизайном иначе. К примеру, у нас игра про зомби, а зомби обычно много. Задача геймдизайна сделать так, чтобы ограничение по количеству юнитов было как-то обусловлено механиками игры и сюжетом. Игра — не только код, а работа многих отделов, в том числе арта. 

А в вашем случае как вы обходите ограничения? Бремя решения этих проблем больше перекладывается на геймдизайн или на техотдел?

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

Интересный подход.

Надо понимать, что мобильные игры могут играться без сюжета. Можно взять любую мобильную игру, которая сейчас есть на рынке, рассмотреть ее и понять, что если пройти в ней сюжет, то игра не останавливается. То есть сюжет опционален для такого формата. 

Значит ли это, что для вас сюжет не столь важен?

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

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

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

Если я правильно понимаю, ты заведуешь FX, материалами и прочим?

Не совсем. У нас техарт не делает FX. Они могут оптимизировать то, что уже сделано. Или если нужен RnD. Должность техартиста в индустрии везде по-разному устроена. Они делают много всего, и многие их направляют в разные отделы, в зависимости от своих потребностей. У нас потребности больше связаны именно с техническим взглядом на проект. Есть свои решения по свету и по всему арту в целом. 

До этого в разговоре с Дмитрием Вороновым я узнал, что в студии Vizor геймдизайнеры подразделяются на две категории: тех, кто придумывает интересные решения и тех, кто их технически воплощает, то есть техгеймдизайнеров. У вас есть такое разделение?

Нет. У нас в компании нет геймдизайнеров, которые не могут настроить свою фичу в движке. Все геймдизайнеры в компании технические. Они все так же пишут GDD, апробируют механики и встраивают их в игру. 

Хорошо, и последний вопрос. Если человек хочет стать техпродюсером, с чего ему начать?

На мой взгляд, если ты хочешь руководить программистами, тебе нужно быть программистом. Если ты не понимаешь, как пишется код, и ты не понимаешь, хороший тебе материал прислали или нет, то ты не можешь руководить техотделом. Твой уровень программирования может быть разный. Кто-то считает, что это должен быть senior программист, кто-то, что middle. На мой взгляд, это неважно, нужны прежде всего другие качества: легкая коммуникация, открытость, умение планировать, стратегическое мышление и, собственно, желание руководить. Надо понимать, что лид — не то, к чему стоит стремиться всем программистам. Я знаю многих людей, которым очень хорошо на своем месте, притом, что они отменные специалисты.