Все хотят выпустить игру-мечты, но бывает так, что от начала до конца разработки происходит столько событий, недель, месяцев и лет, что от первоначального замысла, механик, сюжета и побочных активностей остается хорошо, если треть. А остальные задумки переносятся в DLC и следующие номерные части. Но даже эту треть задумок нужно довести до релиза, протестировать и отполишить.
На этой лодке, корабле или дредноуте, под названием "игровая студия", "вместе гребут" и живут, и трудятся очень много людей. И от каждого из них игра получает частичку души, много времени и уникальное видение. У большинства разрабатываемых игр есть заказчик, а недоступное многим крупным и средним студиям право "делать что хочу, как хочу и когда хочу" есть лишь у небольшой прослойки инди (independent/независимых) студий, которых еще не купили крупные издатели, но и денег с предыдущей разработки хватает на текущую жизнь.
Конечно, чтобы создать игру, требуются начальные инвестиции. Это касается вопроса, почему игры стоят 10-20-40-80 убитых енотов. Когда вам скажут, что игра разошлась миллионным тиражом и разработчики должны купаться в шампанском, вспомните этот пример: авторами достаточно известной action-RPG Nier: Automata были PlatinumGames, издателем и заказчиком были Square Enix, инвесторами и соинвесторами были Tencent Invests, JPMorgan Chase & Co и Sega Corporation. У игры были два главных продюсера, и в общей сложности в разработке игры участвовали более 300 человек из трех игровых студий в Японии и США. Затраты на разработку игры составили более 20 млн долларов, а продажи превысили 7.5 млн копий. Почему студия заработала на игре "всего" 35 млн долларов при средней цене 35 за копию (7.5M * 35 == 35M)? Об этом я расскажу в конце статьи. Такая вот высшая игровая математика. Но сначала давайте посмотрим, как устроена разработка игры.
Вертикаль власти
В большинстве случаев "вертикаль власти" состоит из заказчика, инвесторов, издателя и исполнительного звена (директора и лиц, ответственных за разработку). На ступеньку ниже директоров и совладельцев студии стоят лица, принимающие решения: люди или организации, имеющие права или часть прав на интеллектуальную собственность, полученную в процессе разработки. Это не обязательно должен быть кто-то из мира игродева; так, например, в процессе разработки Nier: Automata права на разработку аниме по вселенной игры получила Aniplex of America. Тогда же сценарий игры претерпел некоторые изменения, чтобы иметь больше общих моментов с аниме. Или франшизы компаний, занимающихся выпуском сопутствующих товаров в виде игрушек, книг, фигурок для раскраски, вплоть до подушек и ластиков.
Менеджмент студии
Что касается управления студией: я встречал два основных типа управления. Первый - когда разработкой управляет продюсер и/или главный гейм-дизайнер, а руководство отделами ложится на плечи лидов (Lead) и principal, человека, ответственного за развитие отдельной части игры/движка. Еще могут быть выделенные люди для исследований или техлиды (Tech Lead), которые занимаются внедрением новых идей или технологий, или хранят экспертизу по движку/игре и занимаются сложными вещами/багами/системами. Но чаще техлид - это сенсей, который знает ответы на все вопросы и создает за счет своих больших знаний высокопроизводительную команду. А если не знает техлид - ну что ж, эта таска досталась тебе.
Второй тип команды - когда у игры есть Project Manager, который отвечает за команды, качество, сроки и постановку задач, и Product Manager, который отвечает за то, чтобы разработка игры шла в соответствии с планами (Диздоком, Designer Documentation).
Размер студии
Принято считать, что игры и студии делятся на Trash, Indie, Mobile и AAA. Не уверен, что именно это полностью правильная градация; сегмент AA/BBB+ тоже достаточно широко представлен во всем мире - это игры ценовой категории (20-40$). Всё, что ниже 20$, считают B+/III сегментом. Эти границы были придуманы, большей частью, платформодержателями, чтобы легче было договариваться с издателями. И это был не Steam.
Indie – это небольшие студии, или вообще один человек, которые делают разные по размеру игры, не связаны обязательствами с паблишером и инвесторами. Т.е. студия не обязательно это гараж с пятью разработчиками и древним компьютером: Rovio Entertainment, Telltale Games, TaleWorlds, Hello Games, Firefly Studios - это все инди-разработчики. И у каждой в штате больше сотни человек. AAA появилось из отчетов Nintendo/SEGA, когда затраты свыше 1M$ заменялись буквой A, 500K$ - буквой B, 250K$ - C и так далее... Но в начале 2000-х игровые бюджеты рванули вверх, так что необходимость в других буквах отпала, а все игры с бюджетом до 100М$ относят к triple A играм.
Неофициально AAA имеет несколько расшифровок, мне больше нравится такая:
А - A lot of resources
A - A lot of time
A - A lot of money
Понятно, что в разное время требования к этим ААА игры были совершенно разные, но объединяло их всегда одно, A lot of people knows the game. Есть еще очень редкие AAAA игры, стоимость разработки которых подбирается к 500М$, на данный момент их всего две
Star Wars: The Old Republic - заявленная стоимость разработки и поддержки которой, превысила 380М$ и Star Citizen - стоимость разработки которой, уже перевалила за 440M$
Потом такая буквенная индексация распространилась и на другие категории игр: III - по отношению к инди-играм, или BBB/BB/B+ игры. Где-то в углу стоят и ржут "Trash" игры, это отдельная категория игр, которые появились вместе со снижением порога входа в игрострой, появлением простых и бесплатных сред разработки (Unity/Unreal/Godot) и дешевых ассетсторов. Хм, сколько вы думаете можно заработать на таком треше?
Pre-production
Вначале было слово... вернее, идея. Идея сделать игру мечты. Кто-то мечтал о танчиках и получилось на выходе War Thunder, кто-то зачитывался Сальваторе и Долиной Ледяного Ветра напару с D&D третьей редакции и подарил миру BG2.
Сначала рождается концепт, идея. Это может произойти, например, на пятничных питчах. В тех студиях, где мне довелось работать, в том или ином виде был такой ивент, как "пятничный питч": раз в пару месяцев команды собираются и представляют разные интересные механики, а самые лучшие потом выносятся на суд game-дизайнеров и реализуются на тестовых уровнях. Не обязательно, что эта механика подходит для текущей игры; это вообще может быть мини-игра про космос, когда вся команда пилит RPG.
После выбора основной идеи, определяют время действия и сеттинг – набор условностей, которые наше общество выработало по отношению к определённым территориям, временам и событиям. Причем есть как условно "ходовые" у любой аудитории сеттинги, вроде средневековой Европы или Второй мировой, так и не очень любимые игроками. Например, игры в сеттинге истории Южной Америки или крестовых походов – единицы. И, конечно, всеми любимые виртуальные миры в стиле фэнтези, альтернативной истории или будущего.
Далее обсуждается художественное наполнение игры: будет ли она ближе к реализму, или наоборот в мультяшном стиле, или же выбирается уникальный визуальный стиль. Вся собранная на этом этапе информация формирует три основных документа игры, на которых потом держится процесс разработки.
Concept Document
Это базовый документ, где достаточно сжато описаны основная идея, жанр и жанровые особенности, целевая аудитория и возможные группы людей, на которых фокусируется игра, сюжет и основные его этапы, особенности игры и ключевые отличия от существующих проектов, кор-механики.
Часть с ключевыми особенностями обычно содержит простой список уникальных элементов, присущих игре. Например, ключевой особенностью Prince of Persia была система паркура с бегом по стенам, впечатляющий бой на мечах и уникальная механика перемотки времени. В Bioshock Infinite был уникальный художественный стиль и сеттинг — летающий город Колумбия. Fortnite предлагает механику разрушения и строительства, что сделало его одной из лучших систем разрушения в шутерах.
Или, например, система удержания внимания (и я сейчас не про мусорный сбор монеток в мобилках, хотя и это тоже заранее просчитанная механика, к сожалению). Многие из вас, наверняка, сталкивались с подобной системой в играх серии Civilization – это простая, но действенная механика "последнего хода". Задумайтесь, почему все основные открытия, напоминания, убирание тумана войны и действия оппонентов выполняются после подтверждения хода. Да, 90% игровых событий игра уже просчитала, моментально переместить фигуры и отобразить результат не составит труда, но тогда у игрока не будет заинтересованности в изучении возможностей игры. Да и само нажатие на кнопку конца хода тоже превратили в подобие мини-игры: подсказки о новых технологиях, перемещения юнитов с остатками очков движения, дипломатия. Ребята из Firaxis очень хорошо освоили механику "last turn action" и довели её до такого состояния, когда она не выглядит как отдельный элемент, а полностью вписана в игру.
Также сюда часто включают базовое описание игрового мира и персонажа, без мелких подробностей. Технические подробности, включая платформы, на которых планируется выпуск игры, и используемые технологии. Сроки и бюджет разработки выделяются в отдельный документ (Resource book), но ранее они также входили сюда. Все это старается уложиться в небольшой формат 15-25 страниц формата А4. Пример такого документа можно найти у игры Monaco, написанной Daniel Bloodworth.
Или например СonceptDoc для первой GTA
Vision Document
Этот документ описывает игру как законченный продукт, будто она уже вышла и в неё можно поиграть. В некотором смысле, это может быть похоже на художественное произведение, где, подобно книге, описываются происходящие с героем события, как сценарий, только без диалогов. Описание может представлять собой более длинную версию концепта, но с большим фокусом на правилах игры, элементах графического интерфейса, условиях победы и поражения, а также правилах получения игрового опыта. Включает в себя карты игрового мира, если он присутствует, элементы дизайна и концепт-арт. При описании кор-механик в vision документе стараются избегать копирования референсов популярных игр (это не относится к треш-сегменту), поскольку готовые изображения могут привлечь на себя внимание. Если и описывают механики и референсы, то в основном текстом.
Также Vision Document включает в себя исследование рынка и конкурентов, содержит референсы на особенности ЦА, таблицу выхода игр, способы монетизации и пост-мортем предыдущих частей или игр конкурентов. Vision Document рассчитан в первую очередь на разработчиков. Здесь вы можете найти небольшую подборку таких документов, там много разного, но есть и VD.
Или вот пример от мастеров жанра.
Feature List
Также включается выжимка из предыдущих двух документов и так называемые "Unique Selling Points". Это те элементы, которые будут выделять игру среди десятка конкурентов и показывать её особенности. Элементы, которые могут быть "selling points" ограничены только фантазией автора, начиная от передовой графики, "bleeding edge" технологий, например как отрисовка отдельных травинок и геометрии в играх FarCry/Crysis, или физически корректно разрушаемая геометрия, как в сериях игр Red Faction или Control. Но конечно же самыми большими "selling points" были и остаются Сюжет и Реиграбельность.
Сюда также включают описание искусственного интеллекта, звукового окружения, части пользовательского интерфейса и механизмы создания уровней (roguelike, рогалики) как явный пример этого. На основе этого документа формулируются фокусы разработки для команды и устанавливаются приоритеты отделов на всё время разработки.
Design Document: You are here...
Все эти три документа вместе составляют Design Document, DesDoc. Больше всего работы по его составлению и заполнению ложится на игровых дизайнеров (Game Designers), и вряд ли вы увидите его на бумажном носителе, хотя бумагу, конечно, никто не отменял. Просто весь этот огромный объем данных будет в Confluence/Wiki, попутно обрастая связями, таблицами, референсами и документацией, планами и детальным описанием игровых механик, тестовыми наборами и т.д. После появления диздока, в студии обычно появляются и первые технические задания. Например, на написание или дополнение лора игры, т.е. истории игровой вселенной, сценария, связей между персонажами, игровыми событиями. Но бывает и так, что от появления базового документа до реальных задач проходит месяц, два или больше. Не думайте только, что команда спокойно потягивает пиво на террасе, если нет задач. Если в студии нет задач, значит или студии нтет или вы спите.
References/Research
По созданным техническим заданиям команда начинает собирать референсы и проводить исследование технологий, пишет тестовые уровни с прототипами механик. Референсы - это набор фотографий окружения, природы и объектов, записки и звуковые файлы, которые относятся к участку уровня, идее или механике. Разработчики проводят интеграцию и пробное использование некоторой технологии, например, системы генерации навигационной сетки по геометрии уровня, телеметрии или обновление физического движка.
Далее на основе этих собранных данных формируется Pitch Book/Document, который представляется для анализа главному дизайнеру, инвесторам и заказчику. Утвержденный и исправленный документ уходит к концепт-художникам, которые на его основе начинают придумывать детали мира и персонажей. Они создают "на бумаге" прототипы, эскизы и иллюстрации отдельных его частей, локаций, героев или даже механик. Техлиды и программисты продолжают изучать возможности применения существующих технологий или необходимость разработки новых - всегда найдется область, где можно что-то улучшить, переписать или вообще сделать заново. Объем собранных данных на этом этапе исчисляется терабайтами, большая часть из них уходит в корзину или откладывается на другие проекты.
Prototype
Полученные от концепт-дизайнеров, художников и лидов решения, дизайнеры начинают переносить в прототип. Это такое состояние проекта, где можно будет увидеть как работают задуманные идеи. Из г...а и палок самых простых элементов (блоков, плоскостей, шаров и других костылей) строят уровни, расставляют болванки и placeholder'ы, фотографии того что здесь должно быть, звуковые описания, просто текст в воздухе. На этом этапе проверяется взаимодействие крупных частей и игра разделяется на главы или хабы (Hub).
Дизайнеры уровней начинают выделять зоны ответственности, разбивают его на слои или части. Обычно каждый участник разработки работает на своем слое. Это сделано для того, чтобы, во-первых, исключить возможность внесения изменений (случайных или нарочных) другими коллегами, и, во-вторых, сделать возможными неблокирующие коммиты в систему контроля версий. Когда хаб поделен на зоны ответственности, на нем начинают выделять отдельные локации в виде зданий, статических объектов или точек интереса. И по мере утверждения таких объектов, они уходят на проработку концепт-художникам, которые создают драфтовые (временные) версии устройств, персонажей, зданий, участков дороги и т.д., сверяясь с референсами для этого участка уровня. Для получения более подходящей информации по окружению, художники и дизайнеры могут выезжать поближе к "натуре", фотографировать, делать 3D-сканы или просто зарисовывать интересные локации.
Статические объекты после прототипирования отправляются художнику по мелким объектам (Props-Artist), который в свою очередь подбирает наполнение для конкретной обстановки: растительность, бочки, двери, окна, предметы интерьера и экстерьера. На этом же этапе подключается Effects-Artist (художник по эффектам), который собирает примеры эффектов для выбранной локации и формирует библиотеку эффектов.
Тем временем левел-дизайнеры продолжают наполнять прототип, детализировать участки.
Models: common objects
Уточненные и утвержденные концепты объектов передаются 3D-художникам. Создание игровых объектов - это многоэтапный процесс, в ходе которого используются различные программы и инструменты. Рассказ о процессе моделировании персонажа может занять отдельную статью, по объему побольше этой, поэтому расскажу кратко об основных этапах.
Сoncept - создается детально текстовое описание персонажа, его действий, реакций одежды и возможных ситуаций, затем на все это подбираются референсы. Обычно собранные документы оформляются в виде mood-board, комплексного описания каждого состояния персонажа, будь то человек, животное или робот. Каждый mood-board(фотографии, картинки и скетчи) характеризует какое-то отдельное состояние персонажа: злой, бежит, бездействует, спит, атакует и так далее.
Blocking/Sculpting/Hipoly - разбиение концепта на простые геометрические формы, шары, кубы и пирамиды, затем придание заданной формы, может состоять из нескольких подэтапов, каждый с усложнением формы. Финальный этап это обычно создание сверх детализированной модели, где добавлены такие мелочки как поры или морщины, шрамы и ресницы.
Retopology/Lowpoly - упрощение полученной 3D-модели для получения такой, которая может быть оптимально загружена в игру, так например исходная модель может содержать 10-15млн полигонов, тогда как движок может отобразить условно 20-40тысяч без сильной просадки производительности.
Texturing - один из самых важных этапов в создании 3D-модели. Здесь поверхности объекта приобретают видимые свойства. Большинство текстур используются для демонстрации физических особенностей модели, чтобы придать объекту естественный вид и оживить игру. Например морщины, складки, затенения.
Rigging & Skinning - Процесс риггинга включает в себя создание скелета персонажа. Это необходимо, чтобы в на следующем шаге можно было анимировать отдельные кости или скелет, тем самым придать движение 3D-модели.
Animation - Собственно все предыдущие шаги были сделаны ради этого этапа, анимации делают модель "живой".
Персонажей, природные и живые объекты обычно относят к категории Organic. Кроме моделей персонажей, начинают создавать, покупать или заказывать статические модели и пропсы (Props) – различные объекты для наполнения мира: здания, заборы, бочки, дороги и многое другое. Если объекты сложные, то они разбиваются на части, а в игре собираются как конструктор Lego. Такой же принцип применяется при процедурной генерации сложных объектов из отдельных частей или непосредственной генерации объектов в самой игре. Процедурную генерацию также используют для драфтового наполнения уровня, потому что пустые пространства игроки очень не любят, инвесторы их любят еще меньше. Все, что не двигается, даже если имеет подвижные части, относят к Hard/Solid Surface моделям, включая оружие и автомобили.
Есть еще одно направление в моделировании - это сканирование реальных объектов и последующая чистка получившихся моделей. Сканирование может производиться как специализированным оборудованием вроде лазерных дальномеров, так и фотоаппаратами, вплоть до камер обычных телефонов. Hipoly модели используют для создания рендеров, рекламы и анимационных роликов "на движке игры" и это почти правда, просто движок запущен на каком-нибудь монстре, который потянет десяток Crysis в 4к разрешении, а лоуполька идет в саму игру, чтобы ваша дохленькая "GF 4090" не загнулась на отрисовке зубов персонажа. Не хочется останавливаться на методах анимирования персонажей, очень интересная тема но, опять же в рамках этой статьи нормально рассказать не получится.
Models: key selling characters
Если в игре есть ключевые объекты или персонажи, то им уделяется отдельное внимание и проработка и над вокруг работы с такими объектами может быть выстроен целый отдел. В небольших играх создание персонажа не превышает 1000убитых енотов, с ростом качества игры растут и затраты на моделирование персонажей, например вот этот неизвестный герой стоил юбикам больше 100к$, хотя учитывая затраты программистов на внедрение и дизайнеров на саппорт, я думаю сумма будет выше. Отдельно для работы и создания героя было выделено 10 человек в Ubisoft Montreal, от аниматора до программиста физики. Более того, внешность персонажа застраховали от кражи и копирования, а отдельные элементы и движения запатентовали, прям как некоторые Дженифер свои лопес.
Prototype: review
В качестве прототипа обычно выступает большой участок уровня, или просто большой игровой уровень, где стараются показать все возможные механики и идеи игры. Затем он показывается заказчику и инвесторам для утверждения, а после улетает в корзину. Прототип редко уходит в целом виде в игру, это только набросок из которого вырастет сама игра, время создания прототипа больших игр занимает от полугода и больше. Когда прототип прошел утверждение его разбирают на части и анализируют, проводят первый фичекат (Features Cut), избавляясь от сложных или неинтересных идей и механик. Бывает что супер интересную механику тоже убирают, если у команды не хватает времени и ресурсов для её реализации или упрощают, такое тоже, к сожалению, случается.
Level Design: Схема + Blockout
Построение уровня начинается с бумажных вариантов, наборов lego или подручных материалов. Формируется список локаций, событий и тригеров - небольших областей, попадая в которые игрок запускает последовательность некоторых действий или скриптов. Составляются биомы или action areas, к которым привязываются типы врагов. Возможные исходы и решения, которые может принять игроки заносятся в специальные таблицы решений, такие таблицы будут нужны позже для балансировки уровня сложности, типов и количества врагов.
После того как построена схема уровня в игровом движке, создается блок-аут. Играбельный прототип уровня, который может быть пройден по правилам игры. В блок-ауте отсутствуют сложные игровые ресурсы, и он состоит из примитивной геометрии, которую можно быстро изменять: кубы, сферы, плоскости, пирамиды. Преимущества такого подхода в том, что большинство игровых движков предоставляют нативные средства для редактирования таких объектов, устраняя необходимость созданния объектов в 3D-пакетах и их импорта в движок. На таком прототипе четко определены навигационные метки и ориентиры. Здесь также формируют и корректируют "Golden Path" — прохождение игры так, как её задумывают разработчики. Обычно на этом этапе также создают базовый ландшафт с использованием сторонних инструментов, например, World Creator, или же средствами редактора.
Level Design: Graybox
Потом наступает этап graybox, блоки на уровне меняются на упрощенные модели объектов без каких-либо характерных элементов, основная задача которых четко передать назначение объекта: дом, дерево, камень, дорога и т.д. Этот этап предоставляет много возможностей для реализации идей левел-дизайнеров, требуется минимум ресурсов для создания интересного геймплея и максимум творчества. А еще для работы с такими "пустыми" уровнями требуется много фантазии и навыки пространственного мышления. При разработке уровней хорошо показала себя практика "парного программирования", когда над одним и тем же участком уровня работают сразу два дизайнера. Недочеты быстро подмечаются и исправляются, происходит естественный обмен опытом и знаниями между коллегами, особенно это видно, если в паре будут джун и опытный дизайнер. Решения могут быть обдуманы и обсуждены, что называется "на лету", что обычно приводит к более качественным решениям и идеям. C появлением graybox уровня, отдел тестирования (QA) начинает проверку механик игры и создание базы gameplay/integration тестов. Это такие юнит тесты для механик, игра запускается на специальных небольших тестовых уровнях, где выполняются все доступные действия, начиная от ходьбы и заканчивая полным прохождением квестов, боевкой или же загрузкой и сохранением.
Level Design: Whitebox
Далее геометрию уровня или его части замораживают, т.е. запрещается вносить крупные изменения и начинают заполнять whitebox'ами. Это этап заключается в размещении вместо кубиков и плоскостей, базовых моделей объектов, зачастую без текстур. Просто белые фигуры на уровне с базовой текстурой в сетку, от чего и пошло такое название whitebox. На этом этапе созданию уровня подключаются художники по окружения (Environment Artist) и концепт художники, которые работают над визуальной частью и расставляют на уровне концепт-модели, уже не кубы, но еще не полноценные модели. Составляют композиции объектов по референсам на уровне. На уровень начинают добавлять базовый функционал игрового ИИ, и начинают появляться комплексные объекты prefabs/kits. Это такой набор игровых ассетов (моделей, звуков, скриптов), который будучи размещен на уровне начинает выполнять заложенный в него функционал: пчелы летают вокруг улья, калитка открывается при контакте с персонажем, а включатель - включает лампочку, лампочка тоже кстати идет в префабе. Перемещаясь по такому уровню, вы может представить по силуэтам, какие объекты или места тут будут в игре. Также Whitebox это первая точка, где уровень может быть разделен на слои, чтобы отдельные группы могли независимо друг от друга работать на уровне: саунд дизайнеры настраивают погоду, AI дизайнер заполняет биом с органикой, а художник по окружения расставляет домики на уровне и пропсы. Все они одновременно могут работать в одной и той же части уровня.
Level Design: Dressing + Props
На этом этапе уровень обрастает моделями, которые с большой вероятностью уже будут в игре. Дизайнер уровня, иногда отдельный Level Environment Designer, занимается добавлением декора и объектов, чтобы придать уровню вид, описанный в референсах и диздоке. Размещает игровые и неигровые объекты (props), соответствующие общей концепции уровня. Определяет, где будут располагаться различные объекты и декоративные элементы, например, мебель, растения, возможно, освещение и другие объекты, создающие атмосферу. Иногда управление освещением отдают специальному человеку - Light Designer. Через выбор и распределение объектов дизайнеры уровней формируют атмосферу, чтобы она соответствовала общему замыслу или стилю игры, подчеркивая определенные пути прохождения. К моменту завершения этого этапа на уровне не остается простой геометрии, которая была сформирована на предыдущих этапах; все модели существуют в том виде, как они пойдут в релиз.
Художник по окружению приступает к размещению на уровне мелких объектов: ваз, телефонов, книг и других мелких объектов. А также следит за тем, чтобы объекты были непохожи друг на друга, а одинаковые ассеты были разнесены на значительное расстояние. Человеческий мозг тысячами лет тренировался в поиске подобий на картинке, чтобы быстро реагировать на возникшую угрозу: узнать, оценить, испугаться и убежать. Так что появление одинаковых объектов рядом, даже если они повернуты и испачканы, но имеют одинаковую позу, очень легко читается игроком, и конечно играет не на пользу атмосфере игры. Например мишка из Fallout 4, который в одной той же позе разложен по всей игре. Что неоднократно ставили игре в пример плохого дизайна окружения.
Level Design: Visual + Narrative Points
Если у игры нет выделенного в штате человека, выполняющего роль Narrative Designer, то на левел-дизайнера возлагаются также задачи по размещению точек интереса. Это могут быть уникальные объекты мебели, украшения или другие элементы, которые выделяются среди общего окружения. Обычно имеется список таких уникальных объектов и точек интереса, которые должны постоянно находиться в поле зрения игрока или появляться достаточно часто.
Отдельно может быть дизайнер, ответственный за оптимизацию уровней и визуальную нагрузку. Он учитывает влияние различных объектов на геймплей и друг друга, следит, чтобы на уровне не было прозрачных стен, препятствий или скрытых зон. Если использование прозрачных стен, препятствий или скрытых зон неизбежно, то они маскируются под стиль уровня, например, создаются завалы, размещаются сильные противники, внедряются сюжетные решения и так далее. Создание явных препятствий или скрытых зон стараются избегать, поскольку они могут разрушать атмосферу игры и напомнить игроку, что это всего лишь программа с условностями и ограничениями. Если игрок добрался до невидимой стены, это может быть признаком того, что левел-дизайнер выполнил свою работу неудачно. Если игрок бродит вокруг дома полчаса, пытаясь в него попасть и выражает недовольство "криворукими разработчиками", это упущения со стороны наративщика.
80-lvl designer
Есть студии, которые требуют, чтобы дизайнер уровней одновременно был и художником, и наративщиком и немного сценаристом. Другие ожидают, что гейм-дизайнеры будут прежде всего дизайнерами уровней, с небольшим вкраплением в разработку сюжета. Например, если вы захотите устроиться в Arkane (работающей над серией Redfall/Dishonored), тестовое задание для старшего гейм-дизайнера включает 60% дизайна уровней и 20% разработки сюжета и 20% игровых механик. Это включает создание блок-аута или грейбокса в редакторе Dishonored, полноценного игрового уровня, с вертикальным геймплеем, ловушками и секретами. Также в отдельном документе кандидат должен создать небольшой сценарий, несколько действующих лиц, места для паркура и стелса, вписать все линии прохождения уровня в события на уровне. В общем, очень высокие требования. Время на создание тестового левела отводят месяц.
Или же вот реальное тестовое задание из другой игровой студии (я немного поменял имя и сеттинг)
Надо рассказать о судьбе Амонахема - обычного египтянина, живущего у входа в пирамиду, который ночью отдыхает в своей скромной хижине, половину дня стоит в дозоре у входа в туннель, другую половину дня заботится о святых кошках, которые живут возле храма. Когда в случайное время, из туннеля раздается громкий звук, Амонахем бросает текущие дела, бежит в свою хижину и начинает молиться, после чего сидит в хижине произвольное время и возвращается к той задаче, которую бросил. Необходимо создать небольшой тестовый уровень с реализацией поведения Амонахема с использованием Behavior Trees. Обязательно учесть, что еду для святых кошек Амонахему следует брать в кладовке неподалеку, и еда там может быть – а может и не быть. Еда респаунится сама по себе раз в определенный промежуток времени (предполагаем, что её будут приносить другие персонажи). Если Амонахем не находит еды для кошек, он какое-то время грустит, а затем проверяет опять. Визуальное разнообразие занятий Амонахема будет достаточно просто сымитировать с помощью черновых анимаций – но обязательно должно быть визуально понятно, какой именно активностью занят персонаж в произвольный момент времени. Можно использовать любой легально доступный движок или инструментарий по своему вкусу. Мы бы предпочли, если бы Вы использовали Event Driven Behavior Trees второго поколения, но это не строгое требование – главное, чтобы какие-то Behavior Trees были задействованы в Вашей реализации.
Level Design: Breadcrumbs + Landmarks
Финальным этапом разработки уровня считается расстановка "хлебных крошек" или цветовая кодировка объектов на сцене. Все важные элементы goldenpath выделяются из окружения: светятся, звенят, мерцают. Было много исследований, показывающих, что желтый и зеленый-люминесцентный цвета привлекает внимание игроков лучше всего. Такие объекты стараются разместить в доступных или всегда видимых для игрока местах. Почему этому уделяется столько дополнительного внимания в играх? Потому что игры стали сложными и визуально перегруженными разными объектами, и чтобы скомпенсировать эту перегруженность разработчиками приходится идти на такие трюки с оформлением.
Вот например кадр из Horizon: Forbidden West, goldenpath всегда выделены желтым: цветы, перила и балки - все что поможет Элойке продвинуться по уровню:
Ну про лэндмарки, думаю, объяснять не нужно. Не знаю насколько это критично современным игрокам, лично я предпочитаю отключать такие подсказки, если есть возможность. Исследовать мир самому намного интереснее, чем идти по кем-то разложенным хлебным крошкам.
Level Design: Water
Вода была и остается одной из самых неудобных частей на уровне, если делать воду нормально, то никаких ресурсов консоли не хватит. Если же снижать качество и упрощать алгоритмы просчета, то это сразу видно игрокам, которые жалуются, что криворукие разработчики не смогли нормально сделать воду. Идеальная вода, когда её немного и она крутая или приходится мириться с компромиссами.
Полноценную симуляцию на частицах игры могут позволить себе только на заранее просчитанных небольших объемах, например для стаканов или бутылок. Или в катсценах, когда физический объем заранее просчитан, записан и его нужно только показать как в кино. А остальное время будет работать упрощенная модель и взаимодействие будет больше частью визуальное, с кучей брызг, эффектов, и каплями на виртуальной камере, чтобы скрыть мелкие огрехи упрощенной физмодели.
Level Design: Profiling
Когда уровень готов, то он подвергается профилированию. Это процесс включает в себя многократные бенчмарки и замеры производительности в разных точках, чтобы она везде была равномерной, а FPS не снижался ниже допустимого лимита во всех сценах. Собирается информация сколько модели потребляют ресурсов и времени при отрисовке. Далее эта информация используется для создания лодов (LODs, Level of details, уровни детализации) объектов. Это позволяет отображать объекты в приемлемом качестве на удалении от камеры меньшим числом полигонов, вплоть до двумерных плоских тайлов на большом удалении (Impostors). Этот лимит прописан в документах платформодержателей (TRC) Sony/Microsoft/Nintendo и сейчас составляет 45FPS. По результатам профилирования уровень или объекты дорабатывают, чтобы уложиться в ограничения. Но бывает и так, что движок "не вывозит" и тогда, одним из возможных решений будет снижение физического разрешения при рендеринге кадра (если причина в большой нагрузке на видеокарту) с последующим апскейлом полученного результата до нужного разрешения в тяжелых сценах. В большинстве случаев, особенно в движении и когда работают другие алгоритмы улучшения картинки, это не заметно игрокам, или заметно по легкому мылу картинки.
Level Design: Metrics
В процессе разработки уровня дизайнеры формируют метрики уровня, чтобы можно было стандартизировать типо-размеры объектов, иначе они будут выглядеть вразнобой и выбиваться из общего стиля. Также делают стандартный размер для проходов, пролазов, дверных проемов, проломов - тех мест где, игрок может перемещаться и не застревать в геометрии, прятаться или забираться на вертикальные объекты. Часто для периодической проверки выделяется один из дизайнеров, который следит за соблюдением этих правил на уровне.
Level Design: Telemetry
С самых первых этапов создания уровня с него постоянно снимается телеметрия. Это делается для более равномерного распределения ресурсов на уровне: аптечек, патронов, монстров, чтобы какая-то часть уровня не выглядела пустой или заброшенной. Вся телеметрия собирается с игровых машин дизайнеров, тестировщиков и фокус-групп, чтобы потом быть проанализированной и исправить ошибки, которые были допущены при создании. Не секрет, что и после выхода игры разработчики также продолжают получать эти данные уже с реальных игроков. Так что запрещая своей игре отсылать телеметрию вы оставите дизайнера Василия без аналитики и он не сможет починить баг. Если раньше это не играло такой роли в процессе разработки и пост-продакшене, то с развитием интернета телеметрия стала представлять собой ключевой инструмент для сбора и анализа данных, понимать поведение игроков и оптимизировать игровой процесс. Собирается любая информация до которой игра может получить доступ: клики по UI, вектора движения по уровню, тепловые карты действий, время стояния на месте, поведение НПС и многое другое.
Есть идеи как могут пригодиться точки попадания и траектория пуль?
Это к вопросу почему почти не осталось игр без телеметрии в современной игровой разработке, игры конечно не стиральные машины, но пару десятков мегабайт за сессию отдают легко.
Sound
Звукоинженеры, саунд-программеры, дизайнеры, композиторы, актеры озвучки и sound-maintainers (инженеры, занимающиеся созданием специфичных эффектов) – все эти люди создают и поддерживают библиотеку звуковых эффектов. В их работе много общего с созданием озвучки для фильмов. Создание звуков для игры самостоятельно может занять много времени, но, на мой взгляд, это абсолютно стоит усилий, поскольку только авторы лучше всех знают свою игру, понимают атмосферу, желаемые эмоции и настроение локаций.
Импорт сторонних библиотек с [бес]платными лицензиями, или получение оных от третьей стороны также необходим, потому что записывать вообще все общие звуки не хватит никаких ресурсов. Но учтите, что никакая библиотека звуков не сможет удовлетворить всех потребностей – и все равно придется обрабатывать звуки и сочетать их между собой.
Sound designer должен уметь расставлять звуковые эффекты ну уровне так, чтобы игроки не обращали на них внимания. Звук воспринимается как должное, и если игрок начинает замечать отдельные звуки, то это может привести к диссонансу между происходящим на экране и восприятием звука во время игры. А еще звуковики обычно классные ребята, умеющие играть на двух-трех инструментах, пишут свою композиции или диджеят на вечеринках.
Звуковые эффекты в игре должны захватывать и поддерживать атмосферу, в нужные моменты переключая настроение игрока под происходящее на экране. Звуки делятся на много типов, основные из них такие:
Atmospheric: продолжительные звуки в фоне. Игрок слышит шум шевеления листьев, пение птиц и скрип деревьев в лесу, кроме естественных и записанных семплов, в последнее время появились мат алгоритмы способные их создавать в хорошем качестве.
Music: музыка подчеркивает определенное настроение конкретной сцены, биома или части уровня и создается, чтобы вызывать эмоциональный отклик у игроков. Часто саунд дизайнеры специально создают контраст между картинкой и музыкой, чтобы привлечь внимание. Например, игрок идет через лес и по направлению к логова босса, музыка может менять тональность, чтобы игрок начал оглядываться.
Voices: типичные примеры - это простые диалоги между персонажами. Тем не менее звуковые дизайнеры также могут использовать сгенерированные звуки для игрового общения между нпс, например чтобы передать тревогу, положение игрока, или место для укрытия. Причем для игрока это будет звучать как паттерн в пересвистывании птиц, или рычании монстров. Это также делается для формирования сцены вокруг игрока. При работе с голосовой озвучкой каждый звук должен затрагивать не только слух, но и душу игрока (ну так считает наш саунд дизайнер)! Актеров озвучки подбирают с тембром и комплекцией, которые соответствуют персонажам. Игроки очень тонко почувствуют фальшивость и реальность озвучки в каждой фразе, произнесенной NPC.
SFX: различные звуки для того, чтобы привлечь внимание игрока. Это может быть звук какого-то заклинания, выстрелов, крики или программно генерируемые звуки, на основе окружения или ситуации.
Foley: отдельный тип звуков, которые должны соответствовать тому, что видит игрок. Например анимация перезарядки оружия должна четко попадать в моменты звуковой дорожки, этого нельзя добиться без тегов синхронизации как в анимации, так и в звуковом файле.
При добавлении любых звуков в виртуальный мир учитывают их положение на уровне и дистанцию до игрока. Общие звуки присутствуют приглушают или наоборот делают более громкими, чтобы они всегда четко воспринимались. У всех объектов есть зона действия (звучания), в пределах которой свойства звука меняются в соответствии с заданными настройками. Это называется аттенюацией.
Также звуковые дизайнеры должны хорошо знать теорию звука и правила распространения звуков в пространстве. Наличие звуковой ямы (эхоямы) можно не предсказывать, но как распространяются высокие и низкие частоты через объекты и в пределах прямой видимости, и примерное взаимодействие при наложении разных типов звуков дизайнер точно знает. Чем более крупный объект, тем более низкочастотная характеристики ему подходят. Множество подобных деталей познаётся только с опытом, причем опыт это уникальный для каждого игрового движка или отдельной игры.
Sound Engines
Для работы со звуком в играх существуют специализированные аудиодвижки, FMOD — доступный, недорогой (лицензия стоит менее 50К$ на игру) и понятный звуковой движок. В нём есть аудиодорожки, таймлайн, 3D-позиционирование, банки эффектов, real-time обработка и возможности интеграции с современными игровыми движками. Его использовали в Starcraft II, Witcher 2, и почти всех инди.
Игры: Hades, Untitled Goose Game, Forza 7, Dead Rising, Dino Squad
Wwise (Audiokinetic) — профессиональный аудиодвижок (но и цена годовой лицензии начинается от 20K$), который больше ориентирован на программистов, но даёт частичный доступ к исходникам и позволяет реализовать бОльшие хотелки дизайнеров. Например имеет встроенную поддержку lipsync — синхронизацию анимации движения губ по тексту и звуковому файлу.
Игры: Dirt Rally, Overwatch, Lucky’s Tale, Death Stranding, God of War
Один звуковой файл эффекта спокойно может занимать порядка 40-50мб, а если в игре будет десяток и больше звуков? Звук в несжатом виде занимает очень много оперативной памяти, разработчики с переменным успехом решают эту задачу. И если проблема места на жестком диске мало кого волнует, то оперативная память не бесконечна, тогда на помощь приходят кодеки и потоковый звук.
Но опять же, сторонние аудиодвижки помимо помимо явных удобств вроде быстрого подключения и большого числа фич, имеет ряд не менее крупных недостатков. Ограниченный контроль над исходным кодом затрудняет оптимизацию и доработку, а ограничения лицензий могут включать сборы с продаж для крупных проектов или дополнительной уплаты лицензионных сборов при достижении определенного уровня дохода или количества проданных копий. Поэтому крупные проекты используют свои решения, которые развиваются вместе с проектом.
Programmers
Когда игровой ассет попадает в игру, его надо оживить, сделать играбельным. Занимаются этим программисты, свой личный опыт разработки игровых движков и подсистем я описал в небольшой статье про будни игрового программиста.
Любой алгоритм начинается с его реализации на бумаге, не верьте тому, кто говорит что пишет код из головы. Еще больше не верьте коду, который так написан, потому что человек просто напишет первое придуманное решение, а старая добрая тетрадка позволяет подумать и выбрать хорошее решение. Сначала создаются визуальные схемы, которые описывают алгоритмы или процессы, где каждый шаг расписан и уточнен. Сам процесс кодирования занимает меньше 20% от всего времени разработки. При разработке игр придется очень много программировать, как в классическом понимании, используя ЯП (C/C++/C#) так и в визуальных средах и специализированных редакторах. У нас тут не очень много выделенных типов разработчиков, которые занимаются только своей областью, в небольших компаниях так и вовсе все делают всё. Но основные направления все же можно выделить. Программисты - это люди, которые адаптируют контент к игре, или игру к контенту, выбирайте кому как больше нравится:
Gameplay – основная задача - придумывание и реализация механик, которые пришли от дизайнеров. Руками этих людей сделано на уровне кода всё, начиная от лежащего гвоздя на уровне, до расчета аэродинамики самолетов. Они создают видимую часть игры, чтобы из отдельных элементов получалась цельная картина, очки начислялись, квесты засчитывались, а враги убивались. Сюда часто приходят из дизайнеров, и наоборот.
Engine – некоторые наши коллеги, которые так и не поиграли в билд и релиз, хотя написали для игры не один километр кода. Без них игра вообще бы не смогла запуститься на пк или консолях. Эти люди сутками думают, как бы еще ускорить итерацию по массиву, и иногда у них это получается
Animation – обеспечивает плавность снимания очков, перезарядки оружия и неправильный поворот кватерниона. Через руки Animation программиста проходят все объекты в игре. Его код - это не просто байты слов, а невидимые нити, которые заставляют персонажей игры танцевать так, словно завтрак из пикселей был особенно вдохновляющим. Он знает такие слова, как ключевые кадры, теги, матчинг анимаций и кватернионы. Еще он знает, что даже у анимаций бывают трудные дни.
Data Analitics - занимается тем, что пьет утром кофе, потом полдня тупит в графану, а вечером пишет баг, что возле вышки снайпера не хватает аптечек. И мы ему конечно верим, как можно не верить человеку, который защитил докторскую по численным методам?
DevOps – организуют нам пятиминутные созвоны, поднимают упавшую графану и умеют ловко уходить от ответа, если закрашилась рабочая машина. Быстрее всех создают внутренней сервер для контры и дальше всех кидают флешку. Обычно приходят раньше всех, а уходят... тоже раньше всех.
Tools – разработчики специализированных программ. Все что не сделал engine программист доделает tools. Обычно у них самый большой беклог.
UI – классные ребята, делают интерфейсы и еще немного вокруг него. Основная задача – создание понятного меню из того, что надизайнил дизайнер, умеют в настройки и периодически прячут кнопку выхода из игры. У этих ребят есть даже отдельный сайт, где они выкладывают свои творения после релиза (https://www.gameuidatabase.com/)
Audio – про них было выше, объяснят на пальцах почему звук не может ходить через портал, но может повиснуть на реверберации. Отвечают за наложение звуковых дорожек, диалоги персонажей, звучание анимационных вставок. Часто хорошо знают асм.
Physics - если персонаж ходит по воде, цепляется за листики и застревает в текстурах это вам сюда. Знают асм, windbg и physx debugger.
AI - про своих плохо не буду, нам еще работать дальше вместе. Но расскажу анекдот, старый, еще с баша:
Ошибка: робот погибает при попадании в него гранаты (именно от попадания, а не от взрыва) Д - дизайнер, П - программист.
Д: программисты всё сломали! почему так получается?!
П: естественно так получается! потому, что у гранаты масса 100 кг! зачем вы это сделали?
Д: да?! а чтобы граната в воде тонула!
П: а почему она с нормальной массой не тонет?
Д: а потому что у воды плотность большая! (прим.: больше, чем у ртути)
П: а почему плотность такая большая?!
Д: а чтобы ящики деревянные плавали!
П: а почему они иначе не плавают?!
Д: а потому что у них масса 50 кг!
П: а зачем такая масса?!
Д: а иначе они некрасиво разваливаются!
Graphics – программисты качественной графики для создания максимально интересной картинки. Когда им нужно добавить детали в модель, просто шепчут какие-то заклинания на высоком эльфийском, и вуаля - вся игра превращается в карнавал, блин, пикселей. Очень уязвимы к слову шейдер. Когда кто-то говорит "А что если мы добавим еще один шейдер?", могут запульнуть мышкой. А еще могут сделать из игры сумасшедший сон художника-экспериментатора, но чаще конечно чинят баги рендера. Сначала сделают, а потом чинят.
Unreal C++ proger - cо времен первых игр мы все больше уходим в сторону специфичного для движков и визуального программирования. Сейчас Unreal C++ программист выделился в отдельную профессию, уже не плюсовик, но еще и не полностью дизайнер. Умеет собрать уровень в редакторе, сделать АИ на блупринтах, завести физику, если сильно тормозит перенести часть логики в "плюсы", но не знает почему надо писать ++it, а не постфикс форму. Знания из областей высшей математики, численных методов, алгоритмов или теории игр все еще требуют на собеседованиях, но с каждым годом все меньше.
Milestone(s)
Когда определенная часть уровня или игры логически готова, делают специальный билд, чтобы показать заказчикам и инвесторам. Это такие демо версии, где собирается и полируется доступный на данный момент контент игры, в них уже можно играть, но на многое приходится закрывать глаза или додумывать как оно будет работать ближе к релизу. К тестированию игры привлекается вся студия, от девопс до директора, и все потом пишут фидбек о том насколько игра вписывается в диздок. На какой-то итерации команда понимает, что игра получится. Пусть даже не хватает 80% процентов контента и работают не все механики, но сама игра ощущается как единое целое. Этап препродакшена может затянуться на до достаточно долгий срок. Как у любого произведения, где присутствует большая доля творческой работы проекту нужно набрать массу и оформиться, чтобы стать законченным. Здесь заканчивается этап препродакшена, и начинается самый долгий, но менее интересный период в разработке игры.
Production
Продакшн это основной этап разработки игры, который легко может растянуться на 4-5 сроков относительно всех предыдущих этапов вместе взятых. У большинства проектов продакшн начинается с очередного убирания возможностей и механик (Features Cut). Опять проводят ревизию всего, что можно убрать, упростить или заменить. Замораживается процесс добавления новых больших фич и механик, существующие прорабатываются новыми элементами и разделаются на более простые. Начинается наполнение игры контентом, левел дизайнеры прорабатывают новые уровни, 3D моделеры выкладывают в репозиторий модели для всех объектов в игре, конечно это только звучит в двух словах, а на деле растягивается на достаточно долгий срок. Ну и конечно самая большая нагрузка ложится на дизайнеров, которым весь этот контент приходится принимать и адаптировать на игровых уровнях. Обычно об этапе продакшена вспоминают, когда когда говорят о кранчах и переработках.
Также в это время наблюдается самый большой приток новых людей в студию, но что намного печальнее самый большой процент ухода старичков. Люди приходят и уходят на другие позиции, это естественно и нормально, но по-человечески тяжело расставаться с коллегами, когда проработал за соседним столом два-три и больше лет. Если вы не станете друзьями за это время, то хорошими знакомыми на годы вперед точно. Естественно, что на этапе продакшена начинают уделять больше внимания доработке мелких систем и уже критически относятся к созданным. Так уже не выйдет протащить в билд глупых ботов или незаполненные локации. К этому времени уже складываются полноценные группы внутри отделов разработки, и точно можно сказать кто за какие элементы gameplay отвечает, какие моменты и кому можно доверить.
Большинство пайплайнов разработки элементов игры за долгие годы развития отрасли обособились до такого состояния, что почти перестали мешать друг другу при параллельной работе. Так контент от моделеров, вполне может жить в игре в виде низполигональной версии, не иметь звуков и части анимаций, или анимации могут быть драфтовые: собранные из кусочков других анимаций, и это не будет мешать при тестировании. Эмбиент звуки и музыка тоже будут появляться на уровне, когда станут готовы. Каждая команда в итоге прикручивает свою часть к игре независимо от других, относительно конечно.
Майлстоуны в процессе продакшена никуда не деваются, они только становятся все короче с каждый итерацией и приходят к 2-1 месячному циклу, чтобы менеджмент мог управляемо контролировать процесс разработки игры. Как и в случае с окончанием этапа преполдакшена, в определенный момент команда понимает, что готов весь функционал который был заявлен и утвержден в диздоке. Игра получает условную приставку гамма-бета-альфа и, как вы наверное догадались, наступает очередная необходимость отрезать что-нибудь.
"Как же так? Вы уже порезали половину игры, там что-нибудь вообще осталось?" Спросит читатель, и будет конечно прав. Увы, такая вот она разработка игр, две из трех добавленных механик до релиза не доживают. Два из трех новых существ не получают своего дизайнера, половина контента игры остается только на машинах разработчиков. Половина студии меняется за время разработки.
Polishing + QA
И вот игра добирается до альфа-бета-гамма версии, все больше усилий участников команды переносится на выявления и исправление ошибок. В отделах появляются люди или целые группы, задачей которых будет только исправлять ошибки и играть в билд. Тестировщики начинают больше обращать на возможность пройти игру по существующим правилам и особенно без них, чем на мелкие ошибки и недочеты. Да-да, вы не ослышались, игру спидранят задолго до того, как она выйдет. У некоторых компаний для этого даже есть отдельные позиции в QA отделах. А опытного тестироващика, да еще знающего игровые механик через тесты, так и вообще мало что остановит. На полишинге ребята из отдела тестирования раскрываются на полную и становятся видны их core-качества. Опишу с какими особыми людьми я встречался на разных проектах.
QA: Nodo-Man
Это, блин, супергерой от мира тестирования игр, который посвятил свою жизнь борьбе с багами. Их также можно назвать "качественными ковбоями", потому что они всегда в первых рядах поиска багов, будь то дикий АИ или невидимая стена. Они даже готовы предложить свое решение бага, когда никто не спрашивает, потому что для них качество - это не просто работа, это страсть! Человека-Nodo нельзя пускать в релиз, потому что вы его никогда не сдадите, всегда найдется новая бага, которую не заметили другие, или переоткроется старая с уточненным описанием. Они берутся за тестирование уровней, которые уже были тщательно протестировано и находят там новые блокеры. Оружие массового поражения отдела разработчиков. Лучше посадите его ментором к новичкам или лидом, где он не сможет нести добро направо и налево в больших масштабах.
QA: Actor
Актер по-жизни, которого случайно занесло в отдел тестирования, проявляет чрезмерные эмоции к любой найденной ошибке, будь то пропавший стул под персонажем или сломанный квест. Часто можно увидеть, как он ходит к программистам с кипой бумаг, громко машет руками и ловит их в курилке: "Шеф, все пропало, гипс снимают, игра не играет!". В конечном итоге часто оказывается, что это лишь очередная "мелочь", которую исправляют на следующий день. Из-за таких людей на двери разработчиков может появиться такой оберег.
На самом деле, тестировщик он отличный, въедливый и наблюдательный, главное давать ему поменьше контактировать напрямую с разработчиками
QA: Joker
Этот персонаж пишет интересные и забавные тесты. Он пришел не столько ради работы, но чтобы от души повеселиться. Причем он и реальности обычно такой, способен шутить и смеяться, даже после 14-часового рабочего дня. Причем вы уже еле шевелите пальцами по клаве, допивая третью кружку кофе, а шутник придумал новый забавный тест и заставил персонажа приседать 1000 раз, и на 1001 игра скрашилась. Успевай только баг-репорты ловить. Они, кстати, у Шутника тоже веселые и зачастую заставляют разработчиков плакать: толи от смеха, толи от бессилья перед вселенной.
QA: Wizard
Мой самый любимый тип тестировщиков, они всегда оказываются в нужном месте уровня в нужное время бага. Но кроме этого они знают, как его повторить, даже если до этого никто не додумался три раза подпрыгнуть, один раз присесть, а потом убить лягушку за полкилометра на уровне. Как они это делают непонятно, я же говорю волшебники. Но у них у всех скверный характер, что неудивительно, если ты с такой легкостью находишь ошибку, а другим требуется время чтобы её зафиксить.
Marketing
И вот мы подходим ко второму важному событию в судьбе игры - релизу, первый был, когда команда понял что игра "дышит". За некоторое время до релиза, обычно за год для крупных игр, в игру вступает издатель, который выполняет свою часть "разработки" игры. Страны бывшего союза, да и Европы тоже, не очень избалованы игровым маркетингом и рекламными кампаниями. А вот американский континент издавна был ареной для битвы маркетологов за сердца и кошельки игроков. Включаешь телик, а там крутят рекламу по твоей любимой метроидвании. На улицах развешаны баннеры с артами из новой части Fallout, огромные - во все здание под двадцать этажей. Не только там конечно, но в Америке к рекламе игр издатели давно подходят с любовью и размахом.
Началось это еще в 90-е: рынок консольных видеоигр был очень перенасыщенным, когда выходила новая игра, то издатели не стеснялись вбухивать в рекламу огромные деньги. Зачастую затраты на маркетниг превышают стоимость самой разработки. А еще это привело к перекосу в продажах консольных версий, отчего сами разработчики уже стараются сделать и отполировать версию игры сначала для консолей, и только потом уже на ПК. На приставках все должно работать идеально, а пк - ну должно работать, не крашится часто и хорошо! По этой же причине ранние игры на ПК получали не очень хорошие оценки, это не редкость и сейчас, особенно для изначально консольных тайтлов. Ну и конечно пираты, игры с удовольствием пиратили всегда, во всех странах и континентах, любая защита со временем ломалась. Консоли в этом плане больше защищены малой доступностью инструментов для анализа. Но смысл защиты есть только первые пару месяцев, в период активных продаж, а дальше и сами разработчики часто убирают её из игр. Тем меньше смысла становится в защите, при движении модели получения прибыли в сторону игр-сервисов.
Аудитория игр все время растет и в неё постоянно привлекаются новые группы. С одной стороны это снижает финальную цену, которая размывается большим числом продаж. С другой это привело к тому, что растет цена за привлечение покупателя, поэтому и появляются разные трюки с выходом популярных актеров на презентациях, вездесущей агрессивной рекламе на автобусах, и всплывающей рекламе где только можно.
Ну и конечно веяние последних лет, когда нечестная реклама выдает желаемое за действительное, причем делает это так красиво, что аж слюньки текут, а рука тянется к бумажнику. Рекламные кампании игр в Америке охватывают всю медийку, до которой могут дотянуться. Как там говорил классик? На что только не пойдет бизнесмен ради прибыли в триста процентов? А за 600%? ЕА в свое время потратили на рекламу третьей батлы в ФБ больше 3М$ и получили буст продаж на 18М$, согласитесь овчинка стоит выделки. Про грустное, вроде покупных рецензий, блогеров и хвалебных отзывов... не будем.
Реклама всегда была и никуда не денется, не станет правдивей или менее навязчивой, причиной этому люди. Чтобы Иван не забыл купить новый BG, ему надо постоянно об этом напоминать, чем больше раз напомнишь тем больше вероятность что купит.
Conclusion
Благодарю, что дочитали эту небольшую статью до этого момента и надеюсь вам понравилось. Сожалею, что не все темы получилось раскрыть достаточно полно, эта статья все же больше обзорная. Создание персонажа и уровней настолько объемно и интересно, что спокойно тянет на пару отдельных статей по объему едва ли меньше этой. А настройка и дизайн игровых звуков, поверьте, тоже очень увлекательно и отнимает у разработчиков не меньше сил. Или игровой AI, еще одна очень большая и интересная тема по которой на GDC каждый год выкатывают доклады от топ студий, и рамками даже десятка статей не уложиться.
7.5М * 35 == 35M!
Как и обещал в начале статьи, расскажу про Nier: Automata и её распределение финансов. Игра использует рендер Enlighten и inhouse движок, на котором делались предыдущие игры студии. Рендер известен достаточно лояльными требованиями к лицензированию, что составляет 1% для игр, которые заработал до 1М$, и 2% если заработали больше. От 10 до 30% забирают платформодержатели - для крупных и известных серий игр условия обычно легче, так что в среднем считаю выйдет около 18%. НДС тоже сильно гуляет от страны к стране, а в штатах и от штата к штату, но тоже в итоге сходится гдето к 20%. Львиную долю забирают издатель и инвесторы, от 20% до 50% с продаж: издателю нужно покрыть расходы на маркетинг, выплатить дивиденды и покрыть операционные расходы, инвесторы рассчитывают получить иксы к тому, что вложили, им тоже надо кормить менеджмент и отчитываться перед акционерами. Возьмем по среднему пусть будет 35%. Если бы движок у студии был лицензированный, роялти откусило бы еще от 5 до 15%, но движок был свой, поэтому эта графа 0%.
Посчитаем что получилось. 0%(Engine) + 2%(Enlighten) + 20%(Stores) + 18%(НДС) + 35%(Investors + Publisher) = 75% * 262M = 65M$. Из этой суммы уберем налоги в странах, где были зарегистрированы офисы компании, что в среднем тоже составляет от 12% до 25% ~16% = 55М$ и вычтем общие затраты студии на разработку, это еще 20М$, по итогу получается в плюсе на 35М$. Такая вот высшая игровая математика.
