Какого блока нет в модели разработки игры

9 пунктов, которые надо сделать до начала разработки игры

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

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

Целевая аудитория заметки: stakeholders, product owners, producers, game designers, indie, startups

0. Ожидаемые KPI

Вначале стоит изучить рынок, и понять, чем он дышит. Стоит посмотреть на показатели потенциальных конкурентов: игры топ гроссинга, вновь вышедшие игры — динамику их развития и модель выхода. Имеет смысл понять топовые и средние показатели рынка в разрезе:

Эти данные в открытом виде практически не возможно получить, если у вас нет инсайда. Я могу посоветовать обратится за помощью к знающим коллегам, например на сайте quora.com. На этом ресурсе собралась такая аудитория, которая готова делиться знаниями. Это происходит не быстро, и первый ответ на вопрос «Какой k-фактор у игр жанра HO?» вы получите в течении 2х — 3х недель.

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

1. GDD — ранняя версия

Документ, в котором уже на начальном этапе прописывается концепция игры:

• Сеттинг
• Основная игровая механика
• Саб-механики игры
• Обвесы для вовлечения, монетизации, ретеншена и виральности
• Игровая экономика и баланс

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

2. User Experience Flow

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

В начале вы рисуете основной цикл, не углубляясь в детали: начало — прелоадер — логин — дейли бонус — лобби — игра / IAP / социалка и так далее. Затем каждый компонент вы декомпозируете и создаете для него отдельный алгоритм. Чем больше в вашей игре функционала, тем больше разделов будет в вашем UXF.

Для создания таких алгоритмов я использую cacoo.com и gliffy.com, однако вы можете пользоваться любым удобным сервисом, который позволит вам быстро и комфортно рисовать блок схемы. Если будет вдохновение, напишу отдельную статью о создании UXFlow.

3. UI Wireframes

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

Для составления документа я использую всё те же cacoo.com, gliffy.com и удобный moqups.com.

4. AERM worksheet

Acquisition, Engagement, Retention and Monetization — компоненты игры, которые должны быть продуманы и прописаны до начала работы над игрой. Каждый из этих компонентов следует расписать в разрезе 3х блоков

• Core Loop
• Metagame
• Social Features

В итоге у вас получится такая таблица:

Core Loop	Metagame	Social Features
Acquisition	Как вы приобретаете пользователей при помощи ядра игры?	Как метагейм привлекает игроков?	Как социальные компоненты привлекают игроков?
Engagement	Как вы вовлекаете пользователей при помощи игровых циклов?	Что будет мотивом для пользователей оставаться в игре?	Что социальные функции делают для вовлечения игрока в игровой процесс?
Retention	Как игра возвращает игроков снова и снова?	Как метагейм возвращает игроков?	Какие социальные компоненты игры направлены на возвращение пользователя?
Monetization	Как монетизируется игра?	Что стимулирует пользователя платить?	Как социальные обвесы способствуют монетизации?

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

5. SDD

На сегодня социальные механики нужны во всех областях разработки: от игр до е-коммерс. Это продиктовано высокой стоимостью трафика, который окупается только при высоком k-факторе, хороших виральных механизмах.

В этом документе следует на базовом уровне расписать:

• сети для коннекта и способ коннекта
• способы приглашений
• способы публикаций
• open graph возможности и рейтинг в facebook
• возможности фан-страницы
• принципы создания ссылок для раздачи подарков
• пуши и уведомления
• e-mail рассылки

6. Prototype plan

План рабочих прототипов должен быть основан на экспертной оценке архитектора приложения. В основу плана закладываем «точки не-возврата» по архитектуре и функционалу. Этот план составляется без дат, так как сроки зависят от состава команды и её квалификации.

Формат плана такой:

• # Code Name
• functional list
  • critical
  • must have
  • additionally

  7. Art style guide

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

  • концепт-арт, сеттинг, макеты
  • цветовая палитра
  • шрифты
  • примеры интерфейса и его отдельных элементов (кнопки, рамки…)
  • эффекты (арт и программные анимации, тени, прочее)
  • стилистика персонажей
  • примеры фонов
  • примеры игровых значков (иконок)
  • mood-board

  8. TDD

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

  • технологии клиент/сервер
  • платформы и девайсы
  • вес приложения
  • использование памяти
  • разрешения экранов
  • скорость работы/загрузки

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

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

  Ссылки из теме:

  • cacoo.com — рисовать UXF
  • gliffy.com — рисовать карту экранов и диаграммы
  • moqups.com — рисовать мокапы
  • quora.com — узнать инсайд

  Программы для геймдева

  Делать игры — не так просто как вам затирают на курсах по созданию игр, особенно когда ты работаешь один. Зачастую, чтоб создать хорошую и качественную игру — надо использовать множество программ для арта, программирования, эффектов, планирования, звуков и всего прочего. А еще надо не забывать про работу с движком. Сегодня я вам расскажу о 45 программах и сервисах, которые очень помогут вам в создании игры.

  Арт инструменты

  Blender

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

  3DsMax

  Дальше у нас идет конкурент Блендера — 3DsMax. Тоже программа для 3д моделирования, но функционала у нее явно поменьше будет, да и интерфейс сложнее. Однако 3дмакс является некоторого рода стандартом индустрии, так что стремитесь на позицию 3д артиста в большую студию — вам надо уметь работать в 3дмаксе.

  MagicaVoxel

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

  ZBrush

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

  Artbreeder

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

  PureRef

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

  Substance painter

  А теперь, программа для текстуринга. Она единственная мне известная, однако она универсальна, а также является стандартом индустрии. Речь идет о Substance painter. Текстуры в ней, при должных навыках получаются просто отличные, а благодаря нормалям можно даже лоуполи объекты делать высокодетализированными. В общем, к изучению обязательна.

  Aseprite

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

  PyxelEdit

  Альтернатива Асепрайту — PyxelEdit. В целом, я не заметил чтоб они как-то координально отличались, но попробуйте оба варианта и выберите для себя любимый.

  Adobe Illustrator и Adobe Photoshop

  Интерфейсы, конечно, можно рисовать и в двух вышеперечилсенных программах, однако они подойдут разве что пиксельным и воксельным играм. Если вы хотите сделать плавный и красивый интерфейс — вам определенно стоит изучить Adobe Illustrator и Adobe Photoshop. Если иллюстратор поможет вам нарисовать что угодно для вашей игры, будь то логотип или интерфейс, то фотошоп поможет вам конвертировать векторные изображения в растровые, а также фотошоп иногда может пригодится в текстуринге.

  Inkscape

  Хочется еще дополнить, что если вы очень скупой, то можете вместо иллюстратора использовать Inkscape. Он абсолютно бесплатен, а функционал, при должных навыках, не сильно уступает, особенно если у вас не сильно высокие требования.

  HoudiniFX

  Эффекты, порой, очень решают то, как будет выглядеть финальный продукт. Лучшим софтом для создания эффектов и пререндеренных разрушений — является HoudiniFX. Я даже не знаю, что про него сказать, кроме как то, что это стандарт индустрии, который используют крупные компании вроде EA, Ubisoft и Naughty Dog. Эффекты из этой программы могут перевернуть восприятие вашей игры.

  Cascadeur

  Анимация — процесс сложный, особенно когда речь идет о 3д анимации. Однако все меняется, если вы используете Cascadeur. Уникальная фишка этой программы в том, что вы расставляете всего пару контрольных точек для анимации вашего персонажа, а все остальное программа доделает сама. Магия, да и только.

  SpeedTree

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

  Marmoset tools

  Еще одна программа — Marmoset tools. Вообще, это программа скорее для рендеринга, и не факт что вам понадобится, однако мне сказали, что в ней очень классно запекать текстуры. Я не уверен в этом на все сто, но в подборку все-же включу. Мало ли нужно будет.

  Quixel Megascans и Quixel Bridge

  Ну и последняя программа, некоторый эксклюзивчик для ленивых анриаловцев — Quixel Megascans и Quixel Bridge. Это библиотека сканированных из реальной жизни объектов, начиная от небольших пропов, заканчивая целыми кусками земли, которые можно легко вставить в свою игру, и они будут очень реалистично выглядеть. Эти сервисы бесплатны для игр на Unreal Engine. Я крайне не рекомендую использовать эти сервисы для игр на других движках, потому что в других движках нет системы Nanite, и они будут очень сильно нагружать игру. Ну а если же вы соберётесь качать ассеты бесплатно, и использовать их в коммерческих играх на других движках, что-ж, рекомендую к просмотру топ-10 лайфхаков для тюрьмы.

  Кодинг

  Что-ж, с арт-программами на этом можно закончить, теперь поговорим немного про кодинг. Все мы прекрасно знаем, что для написания кода нужна среда разработки, но какую выбрать? Хотите честно? Вообще не важно, это на ваш вкус и цвет, хоть в ворде код пишите, мне до лампочки. Однако мастодонтом все же является Visual Studio. Многие в ней пишут, и не жалуются, так что если не знаете что выбрать — выбирайте студию — не ошибетесь. Но если вам нужно что-то другое — попробуйте Rider. Он специально заточен под работу с кодом для игр, как на C#, так и C++.

  Игровые движки

  Ох, теперь наверное самая интересная часть. Игровые движки. Когда только погружаешься в геймдев — сразу встает вопрос, а на чем, собственно, делать игру? Движков огромное количество, но лучших всего 3: Unity, Unreal Engine и Godot. В основном, все на старте бросаются на Unity, якобы потому что он проще в изучении. Возможно, так и есть (хотя по моему опыту, тот же анриал в разы проще, но тут кому как). Можно сказать точно, что на юнити гораздо больше обучающих материалов. Да и коммьюнити у юнити более открытое, чем где либо еще, так что вы всегда сможете найти помощь. Годот-же в основном хорош за то, что он не берет никакого процента с выручки вашей игры, а также он достаточно прост в изучении. В целом, какой движок выбирать — дело ваше, как и в случае со средой разработки. В любом движке можно создать шедевр, при должном подходе.

  Музыка

  Теперь, поговорим про аудио. Музыку, пожалуй, проще всего и лучше всего писать в GarageBand. Единственный минус, эта программа исключительно на устройства от Apple, так что если у вас нет таких устройств, можно использовать FL Studio. Обе эти программы хороши для написания музыки к вашей игре, и каких-то плюсов или минусов я назвать не могу.

  Для записи и обработки голоса, а точнее озвучки, лучше всего подойдет Adobe Audition или его бесплатная альтернатива Audacity. Опять же, эти программы примерно равны по функционалу, когда мы говорим о записи голоса, однако ходили новости, что Audacity продавала данные пользователей третьим лицам. Используйте на свой страх и риск.

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

  Видеозапись

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

  Для начала, софт для записи, и тут два варианта: Nvidia ShadowPlay или OBS. Шадоуплэй потребляет гораздо меньше ресурсов, так как за запись отвечает отдельный чип, установленный на видеокартах, однако OBS более гибкая в плане записи, так как вы можете сразу же настраивать сцену для записи, а также стримить с помощью этой программы. Важно: используйте классическую OBS. Всякие кастомные версии использовать не рекомендую, так как они могут быть слегка ограничены, или же нагружать систему сильнее.

  Монтаж

  Теперь, программы для монтажа. Лично я пользуюсь, и вам советую Adobe Premiere. Он очень прост в освоении, однако на выхлопе можно получить очень хороший результат. А если использовать его в связке с After Effects — то ваше видео может достигнуть высочайшего качества.

  Но если же вам не нравится Премьер или Афтер эффектс — попробуйте Davinci Resolve. Он также достаточно мощный для обработки видео, а особенно приятно в нем работать с цветокоррекцией.

  Планировка процесса разработки и игрового баланса

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

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

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

  Очень часто бывает так, что вот едешь ты в автобусе, а тебе приходит гениальная идея для игрового бестселлера, а ты забываешь ее записать, потому что негде. На помощь в такой ситуации крайне подойдут приложения-блокнотики. Самыми лучшими будут Google Keep и Standart Notes. Второе приложение заявляет, что оно шифрует написанную тобой информацию на своих серверах. Впрочем, преимуществом этих блокнотиков является то, что ты можешь с любого устройства, войдя в свой аккаунт, прочитать свои заметки.

  Для построения блок-схем, например, при создании путей интерфейса, можно использовать сервисы Miro и draw.io. Первый будет немного более многофункционален, но если речь идет исключительно о построении схем — оба сервиса хороши, и выполняют свою работу на все 100.

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

  Прочее

  Ну и последняя категория, “прочее”, содержит все программы и сервисы, которые я не знал куда впихнуть, но впихнуть их хотелось.

  Написание сюжета

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

  Системы контроля версий

  Дальше будут две системы контроля версий — Git и Perforce. В основном, все предпочитают Perforce, но лично мне он не очень нравится, вот честно. Какой-то он… Мудреный. Git в разы проще, и в целом, меня устраивает. Но как обычно, выбор за вами, потому как разница не сильно велика.

  Средство просмотра фотографий

  Следующие две программы будут полезны не только в геймдеве, но и в целом при работе с компьютером. Во-первых, это Google Picasa. Реально лучшая программа для просмотра фотографий, рендеров, и чего угодно. Она очень быстро открывает фотографии, красиво их перелистывает, и может увеличивать вплоть до 1000%.

  Ручная чистка ПК без боли в заднице

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

  Google

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

  Ну вот и все на сегодня. Это все программы и сервисы, которые я лично использую, и вам советую.

  • Программирование
  • Работа с 3D-графикой
  • Разработка игр
  • Дизайн игр
  • Игры и игровые консоли

  Вы точно хотите пойти программистом в gamedev?

  

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

  Если увольняется арт-директор, который несет «видение» проекта, то проекту становится очень плохо, в большинстве случаев визуально он изменится до неузнаваемости, хотя ассеты могут быть те же самые. Программисты делают всё, кроме самой игры: рендер, звук, физику, сеть, AI, инверсную кинематику, поиск пути и т.д. Можем подискутировать в комментариях.

  Что вообще тут делают програмеры?

  Когда я получил свою работу мечты в Ea Spb тоже думал, что «вот щас» буду делать игры — нести светлое, доброе и вечное через уникальные механики. Но увяз в куче кода на с/с++, поиске ботлнеков на лоуенд девайсах и получил в саппорт кривой индусский (его действительно в Индии разрабатывали) фреймворк для показа рекламы на 5 дюймах экрана.

  Так для примера, код из парсера значений, которые вычитывались из json’a рекламного блока. Пару раз даже менял код, но с обновлениями все возвращалось как было. А лид получил гневное письмо, с просьбой не менять ничего, потому что это будет сложно поддерживать.

  if(value1 == "-0") value1 = "+0"; if(value2 == "-0") value2 = "+0"; if(value1 == "-0.0") value1 = "+0.0"; if(value2 == "-0.0") value2 = "+0.0"; if(value1 == "-0.00") value1 = "+0.00"; if(value2 == "-0.00") value2 = "+0.00"; 

  оттуда же в другой функции, и так было везде — что не открой.

  switch (*p) < case '0': id += 0; break; case '1': id += 1; break; case '2': id += 2; break; case '3': id += 3; break; case '4': id += 4; break; case '5': id += 5; break; case '6': id += 6; break; case '7': id += 7; break; case '8': id += 8; break; case '9': id += 9; break; case 'a': case 'A': id += 10; break; case 'b': case 'B': id += 11; break; case 'c': case 'C': id += 12; break; case 'd': case 'D': id += 13; break; case 'e': case 'E': id += 14; break; case 'f': case 'F': id += 15; break; case 'g': case 'G': id += 16; break;

  

  И на чём?

  С++ уже десятки лет без альтернатив является основным языком игростроя. Как он занял свою нишу где-то в начале нулевых, так и остается главным инструментом для создания игр. Выкладывал недавно статью, где описал с какими движками сталкивался для разработки (Не Unity единым…), все что более-менее используется сообществом и развивается написано на плюсах. Весь "кровавый ентрепрайз пота, слёз и пикселей" и подавно.

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

  UCLASS() class UTeaOptions : public UObject < GENERATED_BODY() public: UPROPERTY() int32 MaximumNumberOfCupsPerDay = 10; UPROPERTY() float CupWidth = 11.5f; UPROPERTY() FString TeaType = TEXT("Earl Grey"); UPROPERTY() EDrinkingStyle DrinkingStyle = EDrinkingStyle::PinkyExtended; >;

  Еще камней покидаю в Unreal

  TMap MyMap; for (auto It = MyMap.CreateIterator(); It; ++It)

  for (TFieldIterator PropertyIt(InStruct, EFieldIteratorFlags::IncludeSuper); PropertyIt; ++PropertyIt) < UProperty* Property = *PropertyIt; UE_LOG(LogCategory, Log, TEXT("Property name: %s"), *Property->GetName()); >

  // Find first Thing whose name contains the word "Hello" Thing* HelloThing = ArrayOfThings.FindByPredicate([](const Thing& Th)< return Th.GetName().Contains(TEXT("Hello")); >); // Sort array in reverse order of name Algo::Sort(ArrayOfThings, [](const Thing& Lhs, const Thing& Rhs) < return Lhs.GetName() >Rhs.GetName(); >);

  Но если вы хорошо знаете С, то вас с удовольствием возьмут для перекапывания legacy кода. А еще есть Git, JVM, MySQL, Nginx, PostgreSQL, tarantool, tensorflow и море другого c-кода, которое используется и встроено зачастую в сами игровые движки, функционал этих компонентов тоже надо менять и подстраивать под запросы команды разработки.

  Справедливости ради стоит упомянуть, что С все еще используется в движке Unity (наравне с С++), как для написания модулей движка, так и для основной логики. Весь рендер юньки был написан на чистом C. Мои данные могли устареть, с движком я работал в 2014-16, но обычно коркомпоненты движка переписывают в крайних случаях. Как вариант можно пойти работать туда.

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

  

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

  Есть и другая сторона, часто игровому программисту даже ничего и не надо писать вообще. Больше важны навыки тестирования и анализа, улучшения существующего кода из движка, интеграция тулов, обработки данных телеметрии. Какие-то решения и подходы можно взять из других движков или ядра ОС (например linux), на удивление там есть много пересекающихся тем, особенно по управлению ресурсами и памятью. Так, например, если вы используете системный менеджер памяти, то теряете до трети (30%) перформанса, у Unity менеджер памяти вообще самописный по принципу memory arena, у Unreal форк от dlmalloc, Dagor тоже его использует.

  Собеседования

  Собеседования вообще больная тема из-за отсутствия людей, штаты пылесосят рынок уже третий год, в этом плане европейский игрострой оказался в очень уязвимом положении, потому что не может предложить 1.5-2x зп и вынужден терять разработчиков, и что еще хуже дизайнеров. Гугл конечно может уволить 10к ит-людей, но в игрострое как был дефицит около 70к людей на всех позициях от программеров до арта, так и остался. Проблему с дизами я описал в начале, остается молиться на старичков, лидов и кор команду, которых не так легко перехантить. Вопрос денег здесь уходит на второй план, потому что эти люди уже делают свою игру мечты.

  Затравочный вопрос, который обычно задают всем претендентам звучит так:
  — Есть ли доведенные до релиза проекты?

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

  Второй вопрос обычно:
  — Готов работать с legacy кодом?

  Это, напомню, на позицию, где основные задачи будут по написанию нового функционала.

  Третий уже как‑то ближе к теме. Звучит обычно так:
  — Готов ли разбираться со смежными задачами вне своей области экспертизы?
  — Согласен заниматься анализом решений/reverse engineering?

  Если ответов больше НЕТ чем ДА, то с лидом вы, скорее всего, не подружитесь.

  

  Переработки

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

  Как устроиться

  Что забавно, на европейском рынке gamedev компаний есть одна любопытная особенность, чем более крупный и известный проект, тем проще туда попасть на практически любую открытую позицию. А на какой-нить стартап или инди разработку из пяти студентов будут гонять по всем темам игростроения, Computer Science, захватят немного звука и AI, а потом выясняется, что компания делает очередной три-в-ряд на Unity. В Arkane на тогда еще начинавшийся Deathloop вместо техревью получил разговор по душам с техлидом (engine team, лид наш соотечественник из Казахстана), а когда пытался договориться о сотрудничестве с Triskell Interactive не спросили разве что, какого цвета глаза у лошади Вронского. И все равно вышло, что моего опыта разработки не хватает для клона одного старого ситибилдера про египет на Unity, может и к лучшему, игру "слили" мобильными механиками и идеями.

  Юниттесты

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

  Ситуация лучше разве что у Larian/Dice и крупных студий. Они пишут движки, которые изначально исповедуют другой принцип разработки на основе (TDD) или чего-то похожего. Чинить все баги за месяц до майлстоуна и сейчас в порядке вещей, увы. Большие компании еще хоть как-то следят за этим, а средние и инди просто делают игры. Как умеют так и делают. Отчасти это вина многократно ускорившегося пайплайна разработки и мощных движков комбайнов, которые ограждают от возможности выстрелить в ногу, в худшем случае будет сообщение в лог, но игра продолжит работать, хоть и не всегда правильно.

  

  Вот тут lead gameplay Ларианов рассказывает, как они такого добились. Это традиция студии, о традициях ниже.

  Но, не все так плохо! Ситуация меняется и к нам пролезают общие механизмы безопасной разработки ПО. В gamedev программисту очень трудно убедить студию начать использовать новые инструменты. Что-то по мелочи - без проблем, новый моник, комп, клаву, смузи утром на кухне. Продавить инструменты статического анализа, если он не встроен в пайплайн, практически нереально, пишите таску на QA.

  Отношения с инди-разработчиками

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

  

  Можете почитать, как делали Казаков.

  

  Традиции

  Зато в каждой студии сложился целый пласт традиций. Тут речь идет не о тех традициях, чтобы облить новичка Шато десятилетней выдержки (одна французская компания) или сходить всем отделом в баню и выпить пива (Remedy, эти своей гордятся). Традиции спускаются вплоть до кодстайла, которым пользовались отцы-основатели (отступ с табом в пустой строке после имени функции и кеширование значений в объектах, Unity) или CamelCase, использование префиксов для идентификации типа объекта: "A" для акторов, "U" для объектов, наследующих UObject (Unreal). Хуже, если в традициях узаконены не самые лучшие практики, вроде устных задач, которые могут быть не заведены тасками в jira, или передача таски другому исполнителю без ведома автора (питерская студия, которая делала xcom на мобилки).

  

  Фреймворки и кодовая база.

  Тут вообще полная анархия, кроме крупных открытых игровых движков и опенсорс проектов нет доверенной покрытой тестами кодовой базы. Есть EASTL, но не все готовы его использовать в силу нелюбви к EA, платформенные std не любят из-за привязки к вендорам и тормозам. Вроде бы и алгоритмы одинаковые, да вот реализация разная на боксе и плойке. Про злую memcpy на плойке я уже как-то писал, это системный вызов, который проверяет пересечение используемых адресов с защищенными областями памяти консоли. Не готовы что memcpy тормозит? Пишите свою.

  Легенды игростроя вроде Кармака, Суини, Кейна так вообще увлекались повальным велосипедостроением. Нужен vector? Давайте напишем свой с преферансом и дамами, и пофиг, что в третий раз. Unity/Frostbite/Unreal/CryEngine/Dagor - везде написаны свои стандартные библиотеки алгоритмов. То есть нет тех самых кирпичей, из которых можно было бы гарантированно собирать работающее переносимое решение, добавьте сюда различия в реализациях под платформы. Нет никакой общей культуры разработки движков (разве что кроме god object, этот шаблон есть везде), нет преемственности, нет общей терминологии. Везде свой фольклор и богатый внутренний мир.

  

  На моей памяти в Unreal уже четвёртая смена идеологии развития, Tim Sweeney - программер старой школы, если вы посмотрите на код образца 2007 года, когда были первые утечки, то движок представлял собой монолит с кучей велосипедов. Потом настал черёд Jim Brown и движок двинулся в сторону стандартных компонентов и унификации кода, но часть великов заботливо припаркована, а про другую вообще забыли. Потом пришёл Nick Penwarden, движок вывели в опенсорс, стали разворачивать анриал в сторону мобилок, что потребовало переделки внутренней архитектуры, наворотили кучу новых фичей и сломали не меньше старых. Сейчас у руля Mike Fricker и движок двигается в сторону плагинов и AI контейнеризации всего до чего дотянутся, посмотрим к чему это приведёт. Все еще верите, что Unreal хороший выбор? Посмотрите на архитектуру clang'a, а потом загляните под капот Unreal. Такое чувство иногда появляется, что его пишут студенты

  Привет, сосед

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

  Также они часто уходят в ресерч и реализацию новых технологий, выхлоп от которых будет видно хорошо если через год. Так что готовьтесь часто слышать: "Твой код - @#$%^&" и улетать на респ, т.е. на переделку комита. В силу большого опыта они предпочитают проверенные простые инструменты и скрипты, вместо солюшенов и IDE.

  C git'ом, кстати, тоже есть проблема, он хорошо подходит для сорцов, а вот что делать с гигабайтными текстурами или файлами модели по 100мб, или луашником/json'ом уровня размером под 20-30 мб текста? Тут либо держишь 2 cvs - одну для сорцов, вторую для контента, либо пишешь своё решение.

  Будьте готовы, что вас не раз ткнут носом в незнание алгоритмов, кодовой базы или традиций студий, слабое знание векторной математики или специфику области. Если ты попал к хорошему лиду, который знает свою область движка, будь готов плакать ночами над комитами, которые вернули в десятый раз. Если выживешь и останешься в отделе, будешь делать движок игры наравне с отцами-основателями. Среднее время работы программиста в студии год-полтора. На группу 40-50 человек, коркоманда составляет 10-15 человек, это люди, которые работают больше 4 лет и являются носителями знаний и технологий, ещё 2-3 техлида, которые определяют, куда движок развивается.

  

  Дизайнеры

  С дизайнерами разговор отдельный, дизайнеров надо любить, потому что, как я уже сказал выше, игру делает дизайнер. Разговаривать, учить, помогать, не давать делать @#$%&. Дизайнеры должны быть творческими людьми, иначе игра не получится, даже три-в-ряд. Для дизайнера умение писать стихи и рисовать гораздо важнее, чем умение писать код. Писать код можно научиться, умение писать стихи и делать игры даровано природой.
  Дизайнеры придут к вам со своими идеями, вопросами и багами, если дизайнер пишет багу, это уже не его проблема, а программиста. Иногда последней защитой от дизайнера будет только лид, который сумеет объяснить, почему мы так сделать не можем, ну или волевым решением отправить таску в бэклог.

  Хорошим дизайнерам вообще прощают очень много, их "код" (BT, скрипты, AI) не изучают, не анализируют, не тестируют. Вряд ли вы услышите от них такие слова как "архитектура", "тесты", "кодревью". Интерес представляет только готовое поведение в игре. Дело в том, что обычно дизайнер полностью отвечает за свою область на карте, логику, пропсы и если заставляют подгонять качество под стандарты, то оно в итоге только ухудшается. Поэтому дизайнеров в студиях ценят выше, чем программистов. Программистов можно заменить дешёво, дизайнера заменить дорого.

  Как в итоге пишут код/бт/аи дизайнеры никого, в общем-то, не волнует. Главное - результат. Эта логика никого кроме одного-двух дизайнеров, которые сапортят фичу, не интересует. В одной питерской студии (та, которая xcom на мобилы делала) дизайнер называл функции в скриптах именами героев из "Атаки Титанов" и это никого вообще не волновало, так как кроме него с этим кодом никто не работал. При этом он был на хорошем счету в проекте, и на этот бзик закрывали глаза, равно как и на поздний приход на работу и желание разогреть рыбу в микроволновке в обед.

  

  Школы разработки и их влияние на студии

  Из-за соло-разработки движков и принципиальной закрытости и секретности разработки игр, сложились множество различных движкостроительных школ. Можно условно их назвать Unreal/Unity и Housemade/Solo. Причём Unreal/Unity больше распространены в Европе и Азии, а housemade в Штатах. БОльшая концентрация gamedev студий в штатах делала разработку собственного движка одним из знаков качества и статусности студии. Unreal школа больше ориентирована на мелкокомандную работу и модульные проекты, которые легко прототипировать, насобирать асетов и сделать на коленке mvp, а дальше уже разбираться, как придать проекту уникальности. Ответственность разделена между всеми участниками, минимум использования труда программиста в доработке движка, и больше упор в игровые механики.

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

  Довелось поработать в компаниях, где применяют оба этих подхода и могу сказать, что возникают серьёзные конфликты между представителями разных школ внутри одной группы, и тут надо искать компромиссы, причём последователи Unreal последнее время побеждают. Это как споры между приверженцами Windows и Linux.

  Заметил ещё одну особенность: если студия переезжает на другой движок вместо своего, значит, развалилась коркоманда (https://gamerant.com/cd-projekt-red-explains-using-unreal-engine-5-the-witcher-4/) и в игре не будет оригинальных решений. Это не хорошо и не плохо, просто пришло другое поколение разработчиков, которые не умеют работать со сложными вещами, но умеют делать хорошие игры. И наоборот, если студия начала писать или форкнула один из движков, значит, там выросли спецы, которые умеют писать вещи сравнимые с Unity\Unreal, а зачастую и лучше.

  Первая часть Cities Skylines написана на Unity, программисты взяли движок и переписали его под игру. Вторая часть игры написана на ядре Unity 2206 и судя по тому, что я увидел - его даже не пробовали дорабатывать под игру. Проблемы вы видели сами (Почему Cities: Skylines 2 так тормозит), хотя надо было всего лишь сохранить старую команду.

  

  Мало общения на работе

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

  Обыкновенная ситуация, когда программист в принципе ни с кем не обсуждает кроме лида свою фичу по несколько недель, а потом выкатывает в репо сотню-другую комитов, нанося добро всем подряд и блокируя работу студии, хорошо если на пару дней, пока все баги не выловят в аврале. На расстоянии вытянутой руки сидит другой такой же разработчик из отдела рендера, свои комиты он выкатит через неделю. Рендер вообще отдельная опасТность, их не устраивают общие алгоритмы. Каждый местный Кармак старается написать свою версию стека, swap, расчет контрольной суммы, временные буферы и строки. Аllocator на стеке так это вообще милое дело, за это уже даже не ругают, и прочее и прочее, хорошо если юнит-тестов добавят. А еще два Кармака могут подраться на почве неприятия технологий, а ночью проигравший ультимативно удаляет код из репо и трет историю комитов.

  Промышленная разработка housemade движков в индустрии похожа на времена дикого запада. Каждый шериф строит своих индейцев по-разному и радуется, если они начинают петь в унисон. Каждый раз из проекта в проект шериф начинает героически решать одни и те же задачи. У программистов в gamedev нет менеджера пакетов, нет общих решений, как это повсеместно в ентерпрайзе, или в разработке на Python. Поэтому каждый раз в каждом новом проекте мы вынуждены проходить от первых шагов младенца до Майкла Джексона. Или тащить свое наследие из предыдущих проектов. Вам нужно вытащить данные из influxdb? Извольте написать это сами и желательно на плюсах.

  

  Развитие поколениями

  В gamedev, как в деревне, ничего не меняется десятилетиями. Не мы в этом виноваты, что-то действительно новое выходит примерно через поколение консолей, а это 7-10 лет. Что уж говорить, если на плойке до сих пор не полностью завезли 14 стандарт в соневском компиляторе, про свич и мобилки отдельная тема. Постоянный консерватизм в наборе технологий, в то же время взрывной рост стека в моменты смены поколений приводит вот к такому странному состоянию. Что в 2014 в Unity я боролся с ботлнеками на iPhone 4S на загрузке уровня, что сейчас нам не хватает шины ps5 на загрузке сейва. В то же время эта работа требует непрерывно доучиваться чему-либо, чтобы сделать наш массив еще более оптимальным и нереально быстрым.

  

  Девочкам тут не место

  Они есть среди дизайнеров, художников, но их практически нет среди разработчиков движков. Могут случайно заскочить на полгода, или появляются по ошибке и недоразумению, но надолго не задерживаются. Знаю профессионалов девушек-программисток в банках, CAD и embedded разработке, не знаю их в gamedev.

  Знания и экспертиза

  Вы вряд ли услышите такие слова как FrameWork, boost, std::map, std::thread. Более того, если вы попробуете протащить это через ревью, то коллеги строго на вас посмотрят и скажут "Вай-вай, убери это @$%^&, дорогой друг". Фреймворки не возбраняются, но если этого еще нет в движке, то его можно написать и незачем тянуть новую зависимость. Хотя список зависимостей от SDK у движков обычно под сотню разных либ, но это все проверенные временем библиотеки и технологии, которые достигли зрелости, вроде zlib, squish, lua. Главный принцип в разработке - это должно быть быстро и своё. Никаких бантиков и стразиков в движке не будет, ибо это снижает перформанс. У нас тут только один шаблон: это должно работать быстро и только одна абстрактная структура данных - это массив. Все остальное сделано с использованием этих двух компонентов.

  Слишком мрачно?

  

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

  В игры играют люди

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

  Я тут хозяин

  Главное достоинство - это возможность влиять на разработку практически с самых нижних позиций. Вряд ли где-то еще вам дадут поресерчить и переписать реализацию спинлока в готовом движке на котором уже выпущена игра(https://habr.com/ru/articles/689310/), все завязано на ваши знания и умение питчить свои решения. На консолях ближе вашего игрового кода только ОС, есть полный контроль за девкитом (пк пока оставим за скобками), и даже ОС пляшет под вашу дудку. Всё можно измерить, любые параметры снять через SDK и посмотреть, а девкоманда консолей всегда готова помочь с разработкой под свое железо.

  Тебя слушают

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

  Маленький уютный мирок

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

  З.Ы.

  Gamedev-мир отстает от "большого IT". У нас есть все, от систем контроля версий сорцов до сборки из скриптов, есть подобие командной работы, планёрок, авто тестов, но это все свое, домостройное. Зарплаты программистов в gamedev средние по рынку, но ниже чем в WEB(е)/FinTech или enterprise. Если сравнивать создание игр с web/fintech, это как водитель болида формулы-1 и водитель комфортабельного седана S-class. Жесткий кузов, минимум удобств, зато быстро и Шумахера знают все. Но попробуйте уместить всю вашу логику в 15мс, с обработкой четырехсот NPC на уровне, физики, музыки, рендером на экран без просадок фпс.

  Все это ради совместного фото команды на релизе игры и твоего имени в титрах. Приходите в gamedev, тут делают игры.

  З.З.Ы.
  Много в личку спрашивают как устроиться. Пишите письма напрямую в студии, даже если там нет приглянувшейся позиции. Людей всегда не хватает, а задач всегда много, впрочем как и везде в IT. ЗП, говорить могу только за себя. Если нет опыта, шипнутых проектов и горят глаза соглашайтесь на то, что дают (спорно конечно). Отработаете полгода-год и поймете что к чему, как правильно сказал @Eltayв коментах.

  Зарплаты - да средние по рынку, но найти компанию с достойной оплатой в целом реально. Хотя золотых гор вы тут не получите в найме.

  • c++
  • разработка игр
  • разработка
  • управление проектами
  • управление

  Создание игры от идеи до продвижения после релиза

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

  Всё, что нужно знать начинающим создателям игр, — в четырёх лекциях Высшей школы бизнес-информатики НИУ ВШЭ, прошедших в рамках проекта «Университет, открытый городу: Вышка на ВДНХ»

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

  На лекциях преподаватели образовательной программы «Менеджмент игровых проектов» рассказали, как можно выйти на этот рынок и создать свою игру. Они осветили все аспекты разработки, начиная от набора команды и технической поддержки и заканчивая маркетинговым планом. Всего лекций было четыре: «Построение процессов работы команды для создания игры», «Геймдизайн и креатив в игровой разработке», «Технические основы разработки», «Релиз близко. Маркетинг за месяц до выхода игры и месяц после». Мы собрали для вас краткий конспект каждого занятия и ссылки на видеозаписи.

  Построение процессов работы команды для создания игры

  На лекции были рассмотрены важные процессы работы над проектом: определение концепции продукта и выбор «product owner», подбор команды, распределение ролей в команде и выбор SCRUM-мастера, составление бэклога (backlog) и работа с ним, оценка задач и планирование спринта. Слушатели узнали о том, какие есть ключевые ритуалы в работе, как верно оценить результаты и повысить мотивацию команды.

  Сергей Голубкин
  преподаватель программы «Менеджмент игровых проектов» ВШБИ НИУ ВШЭ, владелец издательства «ГЕМЕНОТ»

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

  Согласно статистике, среди всех игр, которые начинали запускаться, коммерческого запуска достигли меньше 1 %: начинающие разработчики часто ошибочно считают, что идея игры — это главное. Но идея становится ценностью лишь тогда, когда выполнено два условия:

  1. Она оформлена хотя бы в виде первичной документации.
  2. У вас появляется команда, способная воплотить эту идею в жизнь.

  Разработка игры состоит из следующих этапов:

  1. Подготовка.
  2. Препродакшн.
  3. Продакшн.
  4. Релиз.

  Подготовка

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

  «На рынке много инди-проектов, которые выходят в магазины самостоятельно. Преимущественно это игры для платформы Steam. Не стоит забывать и о краудфандинге».

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

  Вижн — это самое главное, что у вас есть на начальном этапе разработки. Хороший вижн занимает одну страницу А4, на которой должно уместиться описание игры (платформа, жанр, сеттинг, модель распространения, описание геймплея, основные фичи и механики, цели игрока), референсы, USP (1 killer-фича + 2–3 уникальных/новых фичи и др.) Любой человек, который прочитает вижн, должен сразу понять, что за игру вы делаете.

  «Когда у вас готов вижн, с вашей идеей игры можно работать».

  В геймдеве используется два основных подхода к управлению командой/проектом: Agile и Waterfall. Большинство компаний использует гибридные методы, берущие элементы из обоих этих подходов. Waterfall — подход к управлению командой, основанный на последовательном, линейном цикле разработки. Agile же основан на гибкости и итерациях в развитии продукта/проекта. У каждого есть свои недостатки и достоинства. SCRUM — один из самых популярных методов практического внедрения философии Agile в IT-командах, он определяет роли, обязанности и ключевые «церемонии» в команде. Итерации в SCRUM называются спринтами.

  «Есть минимальный набор документации, без которой дальше двигаться сложно».

  Препродакшн

  Препродакшн включает в себя составление документации, концепт, feature-list, art-style doc, бюджет, бизнес-план, проектный план, адаптацию и «срабатывание» команды, построение процессов. Самый незаменимый документ — это концепт, который позже «перерастает» в геймдизайн-документ. Бюджетом и бизнес-планом пренебрегать тоже не стоит, т. к. без них будет трудно понять, сколько вы заработали на продаже игры, выгодно ли вам продать игру за ту сумму, которую предложит заинтересовавшийся издатель. Результатом препродакшна является прототип или демоверсия вашей игры для демонстрации.

  «Пока прототип не цепляет игрока, не стоит делать из него игру. Лучше разработать новый прототип».

  Продакшн

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

  «Продакшн — это самый длинный этап, на котором игра реализуется в полном объёме, со всеми её фичами и возможностями».

  Разработка игры — это стрессовый процесс. Не забывайте о мотивации и уровне счастья сотрудников. У нормальной организации две задачи: максимальная прибыль предпринимателя и максимальное благосостояние сотрудника, причём не только в деньгах. Максимальное благосостояние в такой системе равно максимальной производительности всех участников процесса.

  «Счастливый сотрудник = эффективный сотрудник!»

  Релиз

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

  Намного более подробно все эти темы объясняются на занятиях курса «Управление командой» программы «Менеджмент игровых проектов» в Высшей школе бизнес-информатики НИУ ВШЭ. Кстати, на этом курсе слушатели сразу пробуют сами пройти путь разработчика на игропрактике Game Dev Sim. Это настольная игра — симулятор работы игровой студии, где участники как владельцы собственной компании набирают себе команду и проходят через все этапы разработки, решают возникающие проблемы, пользуются возможностями и воплощают мечту о создании игры.

  Полностью послушать лекцию можно на YouTube-канале Высшей школы экономики.

  На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

  Геймдизайн и креатив в игровой разработке

  В чём различие между геймдизайном и продюсированием? Какова роль геймдизайна в создании игр? В чём польза и вред креатива? И главный вопрос: как правильно подходить к креативным задачам в геймдизайне?

  Константин Сахнов

  «Игровая индустрия большая и очень-очень богатая. Объём мирового рынка составляет около $130 млрд».

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

  Специалистов команды разработки можно условно разделить на три категории: «технари» (программисты, веб-разработчики, системные администраторы и т. д.), художники (специалисты, отвечающие за визуальную составляющую игры) и идеологи (геймдизайнеры и продюсеры). Инди-команды как раз могут состоять всего из трёх человек, которые значительную часть работы отдают на недорогой аутсорсинг.

  Идеолог игры

  Многие думают, что игры придумывают и делают именно геймдизайнеры, но это не так. Идеологом игры является продюсер. Главные задачи продюсера: обеспечить всё необходимое для создания игры, привлечь ресурсы (деньги, люди, время), иметь чёткое видение и план достижения целей, довести проект до релиза и коммерческого успеха. Именно продюсер принимает все ключевые решения по игре, но несёт полную ответственность за результат и качество проекта. И он практически всегда участвует в собеседованиях потенциальных сотрудников.

  У продюсера три ключевых подхода к созданию игры:

  1. 100-процентный клон.
  2. Инновация.
  3. Венчур.

  И, конечно же, у каждого из этих подходов есть свои плюсы и минусы.

  «Ваша игра успешная, если она зарабатывает деньги».

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

  «Чтобы сделать крутую игру, нужно набраться опыта».

  Геймдизайнер

  Геймдизайнер — это человек, который делает всё и сразу. Это редкий специалист, которому нужно иметь опыт и знания практически во всех областях, но профессионалом в каждой из них можно и не быть. Геймдизайнер реализует видение продюсера, пишет и актуализирует ГД-документации, рассчитывает характеристики, баланс и экономику игры, участвует в разработке сюжета/ЛОРа, нарратива, разработает ТЗ для других специалистов, контролирует исполнение этих задач, конфигурирует продукт, создаёт инструментарий, участвует в работе над левел-дизайном, проводит тестирование.

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

  «Написать диздок — это одна задача, но не менее важно донести информацию максимально просто и легко».

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

  Приведём пример проектирования интересного геймплея, который создаёт Retention (удержание игроков в игре).

  Цели должны отвечать на главный вопрос игрока: «Зачем мне в это играть?» или «Почему мне это интересно?». Цели бывают сиюминутными, краткосрочными и долгосрочными.

  «Работа геймдизайнера — это, прежде всего, исследование».

  Есть два способа стать геймдизайнером:

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

  Какой подход лучше? Это вы сможете понять, если посмотрите полную запись лекции.

  На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

  Технические основы разработки

  На третьей лекции у слушателей была возможность узнать о технических задачах при разработке игр: игровой логике, графике (двухмерной и трёхмерной), физике игрового мира, звуке, игровых картах, хранении данных, тестировании игры. Участники узнали об игровых движках (на примере UE4 и Unity) — логике, физике и картах, средствах разработки графики и звука (Photoshop, Max/Maya, Audition) и инфраструктуры — базы данных, репозитории, сборка проекта, автоматическое тестирование.

  Дмитрий Табаков

  преподаватель курса «Технические основы разработки игровых продуктов» программы «Менеджмент игровых интернет-проектов» в ВШБИ НИУ ВШЭ, креативный директор Mail.Ru Group

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

  Раньше один разработчик игр был всеми и сразу: геймдизайнером, программистом, иллюстратором, автором звуковых дорожек, тестировщиком и т. д. Но сейчас ситуация изменилась: в крупных компаниях и командах над одним проектом работает около 200 человек и больше, с разными специализациями, на самых разных должностях. Тем не менее, даже сейчас люди продолжают делать игры в одиночку или маленькими командами.

  «Делая игру, вы должны верить, что она заработает, что она будет интересна и востребована».

  Состав игры с технической точки зрения выглядит следующим образом:

  1. Игровая логика.
  2. Графика (2D и 3D).
  3. Интерфейс.
  4. Игровые карты.
  5. Физика игрового мира.
  6. Звук.
  7. Хранение и пересылка данных.
  8. Инфраструктура.

  Игровая логика — это спецификации того, что при условии А произойдёт событие В, например: если персонаж ударит монстра мечом, то он нанесёт ему 3 урона из 10 hp. И всё это должно быть где-то закодировано — этим занимаются программисты гейм-механики, но часто этим занимаются геймдизайнеры.

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

  Большинство игр тяжело представить без графики, которую можно, с точки зрения технологического производства, разделить на два основных типа: 2D и 3D. Интерфейс — это то, как игрок взаимодействует с игрой. На практике интерфейсами занимаются отдельные люди, потому что для этого требуются особые навыки, отличающиеся от тех, какими владеют даже очень хорошие художники.

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

  Важная часть игрового мира — это физика; задача сложная и для программиста, и для геймдизайнера. Звук — широкая область деятельности: музыка, простые звуки (выстрелы, взрывы и т. д.) и озвучка. В игре очень много данных, которые нужно хранить и пересылать (клиент-серверные протоколы). Инфраструктура же нужна для того, чтобы всё перечисленное стало возможным: репозиторий, различные системы хранения документации, билдеры и т. п. Сейчас даже в инди-командах используют достаточно много хороших практик, чтобы упростить разработку.

  Средства разработки и решения при создании игры:

  1. Дизайн (спецификации).
  2. Целевые платформы.
  3. Движок.
  4. Код.
  5. Клиент и сервер.
  6. Ассеты (карты, арт, звук и т. д.).
  7. Специалисты.

  Особенности работы с движком

  Движок — это комплексное ПО, которое позволяет вам не делать всё с нуля, а сразу даёт много готовых решений, например: редактор карт, систему искусственного интеллекта и многое другое. Важно понимать, на каких языках программирования вы будете писать код. Самые частые решения для клиентских и большинства мобильных игр — это C++ и C#. Для серверной же части применяются намного больше вариантов: PHP, Python, Java и множество других языков.

  «Движок — ключевой выбор для разработки игры».

  Когда-то движки были прерогативой крупных студий, т. к. их нужно было делать с нуля, а коммерческие (например Unreal Engine) стоили дорого. Но сейчас они стали практически бесплатными и доступны даже ограниченному в средствах инди-разработчику. Что же даёт движок? Прежде всего, это:

  1. Графика/рендеринг.
  2. Физика.
  3. Звук.
  4. Искусственный интеллект.
  5. Редактор.
  6. Сетевой код.
  7. Оптимизация.
  8. Готовые библиотеки и решения: платежи, VR/AR, многое другое.

  Чтобы понять, какой именно движок подходит для вашей игры, нужно обратить внимание на следующие характеристики: графика, логика (Blueprints, Flowgraph и др.), языки программирования, физика, средства 3D-разработки, интерфейсные решения. Современные движки значительно упрощают работу с базами данных.

  «Об оптимизации лучше задуматься заранее».

  3D-модель начинается с 2D-модели. Концептом может быть не только отрисовка, но и реальный объект или даже фотографии, которые называют референсами. Сначала делается базовая 3D-модель, а после неё — HighPoly (детализация). На выходе получаются красивые 3D-модели, которые часто показывают на промо-артах, но в самой игре этих моделей, скорее всего, не будет. Причина проста: на основе HighPoly создают LowPoly-модели, в которых меньше полигонов и немного ниже качество, но зато такой подход помогает лучше оптимизировать игры. Далее на модели накладываются текстуры для последующего экспорта в движок, где уже ведётся дальнейшая работа по анимации. Наиболее популярные программы для работы с 3D: 3ds Max, Maya, Blender (free).

  «Снизить качество проще, чем повысить».

  Звуковые эффекты большинство разработчиков берёт из различных доступных библиотек звуков. Главная проблема работы со звуком в играх — это озвучка: готовые голоса вы не найдёте нигде. Озвучка, сделанная своими силами, обычно звучит непрофессионально и слабо. Есть два решения проблемы: 1) игра без голосов; 2) работа с профессиональными актёрами. Самые распространённые звуковые редакторы: WavePad, Adobe Audition, Audacity (free).

  Чтобы не запутаться во всей этой информации при работе, используют такие инфраструктуры, как системы документооборота, постановки задач, контроля версий и т. д. Системы документооборота применяют для хранения дизайна, выкладывания артов, планов, комментирования и т. д. Наиболее яркие примеры систем: MediaWiki, Confluence, GoogleDocs. Системы постановки задач подразделяются на локальные и удалённые (онлайн) и позволяют контролировать и оценивать: каково текущее состояние проекта, какие задачи выполнены или выполняются, и кто их выполняет, сроки и объёмы выполнения и т. д. Самые популярные системы: Jira (Atlassian), Youtrack (JetBrains), Redmine, Trello, Мегаплан, Asana, Wrike. Системы контроля версий позволяют работать вместе над одним проектом, иметь полную историю изменений с возможностью отката и переноса и интегрироваться со всей остальной инфраструктурой. Примеры: SVN, Git, Mercurial, Perforce, Microsoft TFS.

  «Не стоит разрабатывать игры без системы контроля версий, даже в одиночку».

  Посмотреть эту лекцию полностью вы можете на YouTube-канале Высшей школы экономики.

  На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

  Релиз близко. Маркетинг за месяц до выхода игры и месяц после

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

  Сергей Зыков

  преподаватель дисциплины «Маркетинг игр» на программе «Менеджмент игровых проектов» в ВШБИ НИУ ВШЭ, координатор проектов в SoftClub

  о том, как подготовить маркетинговые материалы, обеспечить PR-поддержку и наладить работу с лидерами мнений.

  «Когда останется месяц до релиза игры, у вас появится ощущение, что вы не всё успеваете… И чаще всего оно будет верным».

  Так как же за один месяц сделать то, на что у многих уходит по полгода?

  Рассмотрим гипотетическую ситуацию: у вас есть хорошая игра, месяц до выхода и некоторый бюджет. Есть у вас и конкуренты: каждый день в Steam выходит от 10 до 30 новых продуктов, в App Store и Google Play — около 1500. Большинство разработчиков игр столкнётся с маркетингом ещё на этапе разработки.

  «Если не заниматься маркетингом игры, то шансы, что она «взлетит», равны нулю».

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

  1. Осознание: релиз неизбежен! Чем ближе дедлайн, тем больше мобилизуется команда.

  Для маркетолога самое важное на этом этапе понять, что от него хотят, и поставить цели. Все цели должны отвечать следующим критериям:

  1. Быть чёткими и конкретными.
  2. Быть измеряемыми.
  3. Быть достижимыми. К этому критерию нужно относиться с особым вниманием, т. к. в случае неудачи виноватым останется именно маркетолог.
  4. Иметь чёткие временные рамки.

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

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

  3. Ревизия. На третьей стадии маркетологу нужно понять, что сейчас имеется из маркетинговых ассетов, с чем вы будете дальше работать, и что нужно доделать прямо сейчас. Маркетинговые ассеты анализируются по трём основным аспектам: для игроков и комьюнити, для прессы и инфлюенсеров и для рекламы.

  Что есть для игроков и комьюнити?

  «Именно на основе страницы вашей игры в магазине люди принимают решение: купить её или нет».

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

  Чтобы успешно всё это сделать, маркетологу нужно заранее составить контент-план, в котором будет чётко указано, что, когда и где публиковать, чем развлекать аудиторию. Для комьюнити ваша игра начинает медленно «умирать», если в группе не делаются посты хотя бы два раза в неделю.

  «Комьюнити не прощает одной вещи — пустоты».

  Что есть для прессы и инфлюенсеров?

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

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

  Что есть для рекламы?

  Рекламу нужно выбирать по имеющемуся бюджету: если большой — можно экспериментировать, пробовать разные форматы рекламы и продвижения, если маленький, то лучше найти 1–2 наиболее эффективных канала, которые принесут максимальную пользу.

  По итогам ревизии вы сможете выбрать эффективную стратегию выхода на рынок. Например:

  1. «Анонс пока не поздно»: анонсируем игру сейчас, чтобы успеть за месяц набрать хотя бы какую-то аудиторию.
  2. «Apex method»: анонс в день релиза и отсутствие маркетинга до этого момента. Сосредоточение усилий на дне релиза, когда за несколько дней нужно «выложиться» по максимуму. Стратегия хороша для мобильных игр.
  3. «Помогите, кто чем может». Подходит для тех, у кого уже есть комьюнити, у которого можно попросить помочь с набором аудитории. Но нельзя пытаться реализовать несколько стратегий одновременно, выбор зависит от платформы игры, её жанра и многого другого. Вам нужно выбрать только один путь выхода на рынок.

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

  На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

  5. Исполнение. Самое главное — придерживаться составленного плана и решать текущие задачи. В процессе нужно вести учёт активностей, чтобы понимать, куда вы двигаетесь и анализировать всё то, что уже сделали. Аналитика должна быть у вас до релиза. Если понимаете, что план сложно реализовать — меняйте его. Это живой документ.

  «Игроки не готовы терпеть ваши недоделки и ошибки: они уйдут в другую игру».

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

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

  Следующий этап — оперирование игры, но это уже совсем другая история.

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