О важности прототипирования

5 июля 2020г. состоялась конференция-квест по игровым механикам в онлайн-формате, в виртуальном здании Вышки, воссозданном в Minecraft. Мероприятие было организовано проектом HSE Minecraft и руководителями образовательных программ по игровой индустрии ВШБИ — "Менеджмент игровых проектов" и "Основы создания игр". Это был первый опыт проведения мероприятия в таком необычном формате, и этот опыт оказался успешным! В течение всего дня спикеры, каждый из которых является профессионалом игровой индустрии, читали лекции на различные темы.

В рамках этой статьи мы рассмотрим выступление Алексея Савченко, Business Development Manager в Epic Games, о важности прототипирования в процессе разработке игр.

Вместо вступления или down to earth

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

Несколько слов о геймдизайне

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

Геймдизайн — это живой процесс, иначе — дизайн мёртв.

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

Когда вы начнёте проверять плоды этой работы в рабочей среде (особенно, если начнёте это делать скорее позже, чем раньше) вы, как и многие из нас, в первую очередь начнёте искать виноватых, а не винить себя. Это происходит практически со всеми, кто начинает сначала делать упор только на документацию. Простой способ избежать этой ловушки — постоянно проверять свои гипотезы на прототипах. Когда здесь говорится о прототипах, имеется в виду не прототип всей игры в целом. Речь идёт о конкретных прототипах даже отдельных фич, игровых механик или их наборов.

Что такое фичи

Часто может возникнуть заблуждение, что фичами называют какие-то действительно high-touch штуки, USP, уникальные игровые механики или наборы таких интересных штуковин, как, например, хлыст Индиана Джонса, возможность акробатики, stealth-kill’ы и прочие вещи, которые являются знаковыми элементами игры. При этом упускается из вида огромное количество low-touch штуковин. По этой причине большое количество игровых прототипов и вертикальных срезов не могут привлечь достаточного внимания издателя, игровой аудитории и т.д. Получается, вместо вертикального среза того, что будет на 80% работать в финальной игре, используя небольшое количество контента, делают 4 часа контента, механик и фич, которые недоработаны даже до половины. Ни один издатель в такое никогда не вложится. Вертикальный срез нужен для того, чтобы взять 1% финального видения игры и масштабировать его до 100%. А если вы показываете 4 часа игры, готовой на 40%, то не понятно, какой вы видите финал и способны ли вы, как человек или как студия, в принципе сделать этот финал.

Под low-touch штуками подразумевается базовый функционал, который почему-то многие упускают из вида, например, передвижение персонажа. Я видел десятки билдов за последние три года, работая, в том числе, с нашими разработчиками. В которых: запускаешь игру… есть какое-то супер-крутое навороченное введение… есть, возможно, даже прикольно выглядящий главный персонаж в интересном enviroment’е… у него 5 видов оружия, в том числе — экзотического… Но когда пытаешься начать им передвигаться, ты понимаешь, что это всё настолько сыро и не настроено… Это вообще дефолтная механика смены координат, с плохо настроенными анимациями… Это полностью отбивает желание дальше знакомиться с контентом игры!

Прототипирование — как основной метод проверки гипотез

Когда вам рассказывают, что "можно сделать механику на кубиках, graybox’ах или whitebox’ах" — это хорошо только внутри студии. Потому что когда вы выносите наружу какой-то результат, когда все эти системы не сведены вместе в базовое представление для какой-то общей репрезентативности, получается в итоге не очень хорошо. То есть основная теза, которую нужно держать в голове, заключается в том, что после того как документация, состоящая из ваших гипотез появилась, вы войдёте в процесс, который выглядит как декомпозиция на проверяемые гипотезы. Он выглядит как одна глобальная история: прототипирование, итерация этих прототипов, сборка, пробы, проверки, ошибки и повторения. Что не плохо, хотя и может звучать достаточно грустно или скучно.

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

Хороший пример по этому поводу из личной практики: 12 лет назад я работал над игрой под названием Salvation (консольный 3D adventure). Там был блок, посвященный stealth-механике. Вроде на бумаге всё хорошо: нарисованы карты того, как расположены вражеские персонажи в портовой зоне; примерно прописано базовое первое приближение их конусов видения; понятен главный персонаж; понятны условия победы/поражения; примерно понятно наличие двух режимов передвижения противников; плюс прописан базовый набор скриптов того, как они поворачиваются и смотрят по сторонам; прописано, как реагируют противники на мертвые тела и шум; у главного героя есть снайперская винтовка с глушителем и нож, которым можно совершать бесшумные убийства. Вроде бы, стандартный набор механик, который позволяет собрать достаточно крепкий stealth и довольно интересную сцену, если правильно всё рассчитать, разрулить. Это работает в миллионе игр, и нет никаких причин, почему бы это не сработало бы здесь. 

Собрали билд на движке. После первых тестов произвели техническую подстройку: изменили бленды анимаций; переработали часть системы укрытий; ограничили количество боеприпасов снайперской винтовки, потому что стало очевидно, что это некий «ульт»; изменили стрельбу, чтобы было интересней стрелять — всё равно скучно. В процессе дополнительного тестирования стало ясно, что очевидно не хватает как минимум системы рейтинга, чтобы эту сцену необходимо было проходить на время, чтобы был какой-то внешний фактор-индикатор, который позволяет простимулировать действия игрока. Ввели ещё несколько механик, которые сделали эту сцену в принципе интересней. Но придумать и продумать всё это на стадии планирования, до того, как в игру переиграло 10-20 человек по 12-20 часов — не представляется возможным. Таким образом, идеализирование того, что на бумаге всё можно с самого начала предугадать — не правда. Возможно и есть в индустрии какой-нибудь супер-опытный дизайнер, который 50 лет делает игры и 30 лет работает с одной и той же командой, и они друг друга телепатически так хорошо понимают, и у них практически одинаковый tool-set в голове и в настройках скриптов, и в прочих элементах, которые в совокупности позволяют им такое делать, но мы все — не эти люди. Поэтому тестировать придётся много и достаточно плотно.

Тестировать нужно на preproduction'е и прототипировать все базовые фичи нужно до прототипа отдельно, затем в базовом прототипе игры, а потом — в вертикальном срезе.

Есть такая сентенция: на preproduction'е происходит всё творчество и креативная часть. Это 20-25% всего времени разработки. А остальные 75% производства — это выполнение заложенных планов на preproduction'е. Не знаю, насколько это очевидно, но после того, как всё выдумано и задокументировано, собран вертикальный срез, который показывает, как это всё должно выглядеть в итоге (вертикальный срез игр всегда включает в себя основной игровой цикл и базовые механики, основных персонажей и субмеханики, которые будут отрабатываться), после всего этого, когда проект уходит в производство, вбрасывать какие-то “идеи-на-лету”, если вы работаете где-то в какой-то компании, никто не даст. А если вы строите свою студию, то сначала вы, скорее всего, будете это делать, а потом поймёте, что это ломает все ваши планы и перестанете это делать сами.

О доступности прототипирования

Прототипировать можно очень по-разному. Раньше было сильно сложнее. Эта история с дизайн-документом и проверкой гипотез на бумаге, с сессиями настольных игр и прочим, тянется ещё с тех седых времён, когда способов проверки было существенно меньше. Сейчас каждый современный движок, будь то Unity, Unreal или CryEngine, обладают внутренними нативными, либо внешними системами прототипирования и визуального программирования, что очень помогает. Я начинал с UE3, там для этого использовался Kismet, сейчас уже используются Blueprint’ы, которые намного удобнее, понятнее и проще. Раньше было совсем тяжело: ты пишешь документ, отдаёшь его в программный отдел, как правило, это происходило в компании, где использовался свой собственный движок. Чтобы геймдизайнеру что-то сделать, необходимо было, чтобы программисты отвлеклись от какого-нибудь своего рендера и написали для дизайнера какие-то тулзы, а они этого делать не хотят и т.д. Потом геймдизайнеру отдают эти тулзы, а они не работают и их нужно ещё настраивать. В итоге, из грязи и палок лепится что-то страшное, но симпатичное, и, можно сказать, что это базовый прототип.

Сейчас всё настолько проще, что для прототипирования базовых вещей вам даже не обязательно составлять половину скриптов, потому что на маркетплейсах практически любого движка уже лежат готовые темплейты, которые стоят копейки. Например, "система персонажей", "система камер", "система диалогов" и т.п. Можно это брать, комбинировать и смотреть, что получится. Очень важно прототипировать руками, потому что только прототипируя руками вы начнёте разрабатывать свой личный tool-set и понимание того, как работают механики, понимание грани между кросс-дисциплинарными языками и мышлением, которое вам нужно, чтобы заработала синергия внутри компании. Вы, например, придумаете оружие, как геймдизайнер-новичок: оружие такое-то, класс такой-то, стреляет из ствола, если нажать на курок, в обойме 30 патронов, выглядит как в Uncharted и т.д. Если вы прокаченный геймдизайнер, вы уже делаете систему оружия. Вы плотно поработали с настройками внутри движка и приходите уже с другой постановкой задачи: вот снайперская винтовка, она использует instagib — моментальная отметка цели поражения, скорость пули не существенна, баллистики нет, физика плоская и прочее. А вот эти три вида оружия используют баллистическую модель Projectile, скорость пули такая-то,  нужно ещё дополнительно 8 характеристик. Внутренний редактор оружия давайте соберём на blueprint’ах, чтобы я вас не отвлекал. Вот такой уровень интеграции очень сильно помогает и вам, и отделу, и компании в целом.

По поводу обманчивости

Первый шаг, который в голове обычно щёлкает, о том, что буквы дурят — надо визуализировать. Очень часто, преодолев этот момент, люди начинают использовать какие-то прикладные инструменты, начинают много рисовать. В моём личном опыте, я настолько разочаровался в паре результатов, что был долго при мнении, что игру вообще всю нужно раскадровать, как в кино, что только после этого ты будешь уверен, что всё будет хорошо. Но это дорого, достаточно сердито и мрачно. Здесь момент такой: когда вы выходите на стадию визуализации, начинаете использовать какой-нибудь SketchUp, какие-то картинки, карту и т.д. вы переходите от слова к 2D, ваше понимание лучше, но оно не финальное. 2D- и 3D-мышление настолько разное, и настолько оно по-другому будет работать в движке, что нужно всё равно прототипировать в нём. (Под 2D здесь подразумевается визуализация/зарисовки/схемы, а под 3D — прототипирование в рабочей среде. Прим.ред.) 

Из рабочих примеров. Мы когда-то делали с командой товарищей MOBA, но с военной техникой. Казалось бы, ну что может пойти не так? Профессиональные дизайнеры, люди с десятилетним опытом работы в индустрии. Нарисовали 2D карту: карта понятная, три лайна, техника; из инноваций — военные базы, которые располагаются в промежуточных точках (небольшой элемент Battlefield в этом всём); пересечённая местность, чтобы сделать это всё интересней; юниты типа «Hero of vehicles» — всякие танки, броневики, у которых по 4-5 абилок; цель — уничтожить базу. На бумаге всё прекрасно выглядит. Карта для MOBA, как вы наверное понимаете, не может выглядеть как-то по-другому, она может быть немножко вариативна, но в целом там тяжело ошибиться. 

Собираем прототип. Причём делается это супер-быстро, используя те же blueprint’ы, скрипторы и т.д. Вы элементарно лепите карту тулзами ландшафта, размечаете разный тип terrain’а разными цветами, чтобы не заморачиваться. Условно, сделать абилки юнитов — тоже очень легко, практически всё работает по tick’ам, по нажатию кнопки срабатывает какой-то модификатор, который меняет либо health, либо создаёт какой-то VFX, либо делает какое-то действие — в инструментах визуального скриптования можно прототипировать по 20 абилок в день. Как-то это базово настраиваем, запускаем… и что? 

Во-первых, ты понимаешь, что 3D тебя жестоко гнобит тем, что (вспоминаем Paragon) наличие любого вертикального аспекта в геймплее мобы — челлендж крайне дурацкого и невероятного уровня. Учитывая, что это ещё и техника, а у техники есть ограничения, например, поворот башни, дуло может смотреть выше или ниже (хотя это можно в игровых условностях отменять, но это плохая идея, потому что фанаты техники в целом за то, что ничего не должно меняться в hardware’ных характеристиках юнитов). Плюс абилки, по своей динамике, и по скорости, которую будет игрок ожидать от визуализации танка в 3D пространстве, просто не работают. И мы бились над всем этим ещё три недели, но идеальный бумажный план был проверен базовым приближением в визуальном отображении. В итоге сделали несколько вариантов, которые подходили под всё это лучше. Изменили сеттинг на фантастический, потому что можно будет вводить понятие hover-юнитов. Вспомнили игру Warzone, ту часть, где можно было ещё и юнитов немного модифицировать самостоятельно. Придумали прикольную историю с тем, что количество лайнов варьируемое и техника разнообразная, вплоть до вертолётов и т.д. Но в целом, без каких-то таких проб, ошибок и проверок гипотез в 3D пространстве, ты не поймёшь, что врут не только буквы, но и картинки. Пока руками не попробуешь — вообще не понятно. Когда начинаешь пробовать в 3D, то понимаешь, что уровень базовых настроек сожрёт большое количество времени. 

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

Вместо заключения

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

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

Это козырь, прямо сразу видно, что вы что-то умеете, помимо того, чтобы просто буквы писать. И по этому контенту видно, что вы как-то разбираетесь в предмете. 

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

Есть странное противопоставление в головах людей. Говорят, вот, "нарративщики". Нарратив — это же не про сценарий в широком смысле, это способ интерактивной передачи концепции в мозг другого живого двуногого. Я когда-то по прототипам за 2 недели собрал этакий ATBRPG, типа Final Fantasy VII, где нужно бегать по карте, можно было разговаривать с другими персонажами и брать квесты (этот кусок я честно подмотал на маркетплейсе), можно было переходить на экран боя, у меня там было четыре персонажа, у которых были разные абилки, штук восемь, которые все тоже работали по такому принципу смешному, из области, "при условии необходимого количества маны, по выбору данной функции отрабатывает VFX, который наносит такой-то damage в зависимости от характеристик другого персонажа" и т.д. И это всё очень быстро собирается. То есть если вы хотите оттранслировать какую-то историю посредством прототипирования в движках — это очень просто.

Вопросы от слушателей

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

В средних и больших компаниях, пока preproduction не пройден полностью и не получено утверждение вертикального среза какими-то ответственными лицами, production не начнётся. Собираются команды, собираются юниты, производится технический preproduction, проходит стадия Research&Development, отбирается набор уникальных фичей, механик и субсистем, которые будут составлять эту игру. Это всё описывается и тестируется сначала отдельно. Есть хорошая старая практика: если будете разрабатывать игру, вы будете пользоваться системой хранения версий (это система сейвов вашей игры, на случай, если вы сломали следующую версию. Например, Git, SVN и т.д.), а также будете использовать "грязное прототипирование", которое производится на машинах, не подключенных к системе хранения версий, и предназначено, чтобы за несколько дней или недель иметь возможность составить прототип, чтобы ощутить Fill&Fun, после чего его просто выкинут и ничего не пойдёт даже в исходники, потому что если хоть что-то из этого пойдёт в исходники, то это будет трагично.

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

Вы говорили о 3D мышлении, а что в случае разработки 2D игры?

Я имею в виду не формат игр 2D, 3D, а то, что ваше первое графическое приближение вне игровой среды вам врёт. Если вы делаете 2D игру, и если вы пробуете планировать многие вещи до игровой репрезентации, вы тоже наколитесь там на кучу моментов. Делали мы когда-то с товарищем игру Chaos Domain — это такая Contra, получившая оценку где-то 5,5 из 10 — средний платформенный шутер. Мы вроде тоже не глупые люди, играли с детства в миллион платформеров, все играли в Contra, Contra Hard Corps, в игры Дэвида Тейлора, играли в современные игры, я не беру уже подсемейство 2D-платформеров из области Another World, Flashback и т.д. — это другое. В итоге, все эти карты, которые были нарисованы, которые, как говорится, make sense, имеют логику, расстановку противников, типов противников и т.д. Всё это налетает на то, что когда ты начинаешь настраивать скорость передвижения, прыжки, двойные прыжки, расстояния, анимации и прочее — ты становишься перед кучей компромиссов, которые твою бумагу, конечно, не обесценивают, но тебе как бы снова реальность намекает, что вся эта бумажная, предварительная работа до проверки боем составляет максимум 20-30% от всего в целом.

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

Сложно проработать грамотный интерфейс?

Это супер-боль. Вообще в индустрии жуткая проблема номенклатуры, терминологии. У каждой студии какие-то слова могут называться совсем по-разному. Например, UX/UI. Их обычно пишут через слэш, однако я бы сильно разделял UX и UI. Потому что, базово, интерфейс — это способ взаимодействия с игрой. В понятие интерфейса входит джойстик, телевизор, человек и глаза. А если мы говорим конкретно о User Interface, как об отдельном понятии, обычно имеется в виду какое-то количество того, что мы видим перед экраном, вот эти десять квадратиков, десять сердечек и ножки куриные. Это второй вопрос. UX обычно добавляют к этой истории, потому что это фактор, который существенно влияет на юзабилити. Но юзабилити — это гораздо более широкая история, потому что все настройки влияют на фактор восприятия игры, даже настройки передвижения и т.д. 

Мы записывали лекцию с Ярополком Рашом, и там мы обсуждали то, что пользовательский опыт начинается с магазина, где игра покупается. Когда ты заходишь, покупаешь, скачиваешь, запускаешь — у тебя начинается фаза взаимодействия с игрой. Запускаешь и первое, что ты видишь — это UI, главный экран игры, который появляется после базовых заставок. И уже тут могут наступить проблемы. Потому что если период загрузки между заставками и заглавным экраном реализован слишком долго или коряво, либо если у тебя плохо представлены моменты, связанные с переходом между title-screen’ом и категориями, функциями выбора сложности и т.д. Это уже может компрометировать игровой опыт. То, насколько комфортно разные игроки могут взаимодействовать с игрой вы не сможете проверить без плейтестов.

Расскажите об оптимизации

Везде по-разному, но везде нужно предполагать, что будет несколько стадий оптимизации. Будет стадия после вертикального среза; вы в любом случае будете оптимизировать после сдачи альфа-версии; вы будете оптимизировать после стадии бета-версии, потому что будет добавлено много нового контента; также будет финальная стадия оптимизации, которая сильно зависит от того, работаете вы с издателем или нет. Потому что если вы работаете с издателем, QA будет заложена всегда, как одна из финальных стадий контракта с внешним контрагентом. Как это работает: вы отдаёте игру после того как она оттестирована внутри, её проверяет какая-нибудь внешняя компания, на этом специализирующаяся, либо отдел издателя на 500 человек, и к вам приходит фидбек на тысячу пунктов. И среди этих тысяч пунктов написаны в том числе вещи, связанные с чем-то, что влияет на User Experience.

Unreal Engine 4 vs Unity

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

Правда ли, что самый лучший геймдизайнер это тот, кто может сделать игру в одиночку, но сделает это просто дольше?

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

Видео и дополнительная информация

Полное видео того, как эта лекция проходила в Minecraft можно посмотреть на Youtube-канале разработчиков игр.

Все "фото" с мероприятия — в альбоме Группы разработчиков игр ВШБИ НИУ ВШЭ.

Руководители программы Менеджмент игровых проектов ВШБИ НИУ ВШЭ и студенческий проект HSE Minecraft уже запланировали новое мероприятие, которое пройдет в октябре. Следите за анонсами в Группе разработчиков игр ВШБИ НИУ ВШЭ!