Полная версия
Игра как бизнес. От мечты до релиза
Арт-дирекшен
Cуществует достаточно большое количество игр, которые цепляют исключительно арт-дирекшеном, вокруг которого выстроены минималистичные сюжет, несколько механик и простая, но эффективная режиссура, подчеркивающая эстетику процесса. Опять же, здесь не стоит путать с контентом, которого может быть там мало или много. Речь идет о целостной арт-концепции, которую проект или содержит, или нет. Тут третьего не дано.
Анимация
Тоже аспект, который часто принято считать прикладным или просто необходимым, но не ключевым. Что, в целом, ошибочная точка зрения. Вы можете сделать игру, в которой игрок просто вовремя жмет кнопки, и на экране круто танцуют персонажи. Визуально-эстетический фактор крутых анимаций способен затащить продукт как убер-фича даже при относительно простом контенте.
Музыка и SFX[8]
Чудовищно недооцененный фактор в куче игровых продуктов (особенно отечественных). И этот подход часто выходит боком даже тем играм, которые хороши во всем остальном. При этом существует целая ниша игр, посвященная как исключительно музыке, так и играм просто про музыку и OST. Эта музыка и саундтреки могут потом еще и продаваться лучше и дольше, чем сама игра.
Режиссура и презентация
В некоторых случаях это абсолютно необходимый фактор (скажем, в сюжетно-ориентированных играх), в других – некий над-фактор, способный вытащить в большом количестве случаев практически любой производственный косяк и сэкономить кучу ресурсов (особенно контента и анимации).
Этот список можно дополнять разными штуками (если вы знаете, как сделать игру исключительно про богоподобные спецэффекты, то вы тигр и молодец) и учитывать не концептуальные вещи, а совершенно необходимые, затронутые выше – такие как доступ к серверной экспертизе (в случае онлайна).
Каждый пункт мы оцениваем по десятибалльной шкале. Берем свои навыки и навыки имеющихся в наличии единомышленников. Если вы можете нарисовать как минимум семь напротив хотя бы трех-четырех пунктов этого списка – вам надо сконцентрироваться на них, а остальные прятать (или не акцентировать). Или наращивать экспертизу.
Кроме того, держите в голове то, что было сказано ранее в этой главе. И, скажем, если вы супер в нарративном сюжете, анимации, режиссуре и арт-дирекшене, но зачем-то планировали делать свою игру как бесплатный онлайн-проект на мобильные платформы (потому что вчера Федор с Иваном, работающие в большой успешной корпорации, в баре после десятого пива сказали, что надо делать только такие игры), ну, возможно, вы уже делаете что-то не так.
Если же вы четко понимаете, что у вас явные проблемы, и совсем непонятно, как получить доступ к некоторым экспертным полям (например, левел-дизайн в запланированной игре про пятьдесят пространственных головоломок), наверное, стоит тоже как-то сесть, задуматься и переосмыслить текущие планы.
Промежуточные итоги
В идеале, все взвесив, вы должны прийти к какому-то стройному видению игры с точки зрения продукта. Которое и станет вашим фокусом, предопределяющим примерно половину действий. Например, вот в таком виде.
Title XОднопользовательская игра для ПК, распространяется за деньги, дальнейшие перспективы развития на консоли PS4, Xbox ONE, Switch.
Команда сильна в нарративном сюжете, музыке, режиссуре и неплоха в арт-дирекшене (и вообще вы раньше занимались видеопроизводством и рекламными роликами, но свалили из своих бывших компаний).
Команда страдает от недостатка экспертиз в системном дизайне, левел-дизайне, UI/UX.
Это все в целом неплохо ложится на картину красивого, идейного walking sim с прекрасным сюжетом.
Или может быть картина принципиально другая, и у вас сложилась вот такая композиция.
Title YМногопользовательская игра для мобильных платформ, распространяется бесплатно, изначально выпуск на Apple Store, потом Android, если все будет хорошо, то еще и Switch.
В команде есть крутейший дизайнер-математик, UI/UX чемпион, понимание серверной экспертизы, неожиданно режиссер.
Команда вообще ничего не знает про нарративные сюжеты, музыку считает ненужным элементом, с арт-дирекшеном история тоже так себе.
Вы хотите делать футбольный менеджер для мобильных платформ, режиссер хотел бы еще добавить в игру офигенные сценки повтора моментов, когда мячик влетает в ворота – да, славно.
Или же вдруг у вас вот такая история.
Title ZОднопользовательская игра для ПК с такими вкраплениями онлайна, как рейтинговые таблицы и повторы видео. Игра ввиду своей специфики свободно может быть портирована на мобильные платформы и даже веб, а при определенном развитии событий – вообще на все платформы.
В команде есть очень крутой звукорежиссер, режиссер, прекрасный аниматор и идейный вдохновитель, средней руки программисты, которые, впрочем, еще и чуть-чуть знают про игровые субсистемы.
Игра представляет собой танцевальный соревновательный сим, в котором можно кастомизировать персонажа и выкладывать ролики успешных матчей в онлайн.
В общем, вы поняли основной принцип.
Также все три примера – это существующие игры, на данный момент успешно разработанные или подписанные с издателем и находящиеся на стадии пре-релиза.
Сотрудники и их роли
Так как у нас зашла речь о доступах к трудовым ресурсам и степени их компетентности, стоит очень кратко обрисовать, какие роли и какие специальности вообще существуют на рынке.
Я это делаю не только в порядке ликбеза, но и для того, чтобы зафиксировать некоторые термины. Дело в том, что в индустрии есть определенные проблемы с терминологией и одни и те же слова порой интерпретируются по-разному. Определение одной и той же специальности может гулять от компании к компании. Как в силу сложившихся практик в конкретном месте в конкретное время, так и из-за въевшихся в мозг ошибочных представлений – причем даже на уровне руководящего состава, а не только среди HR-менеджеров. Я допускаю, что с некоторыми моими определениями согласятся далеко не все. Но как минимум мы их проговорим и обозначим. И не будем путаться в ролях. Это как, например, можно услышать: «У нас команда из трех человек, нам не нужен продюсер, зачем он вообще». Нет, один из вас принимает на себя роль продюсера – просто он об этом почему-то не знает. А вот нужен ли вам кто-то еще на эту роль – это уже совсем другой вопрос. И тут как минимум стоит понимать, что это вообще такое и как это может выглядеть на практике.
Ниже возможные роли на производстве.
Геймдизайнер (Game Designer)
Возможно написание «гейм-дизайнер» (и оно вполне корректно). Придумывает и описывает игровые механики (или детализирует на основе брифов/указаний сверху), отлаживает их, выстраивает баланс, в некоторых случаях может писать скрипты.
Во free-to-play проектах такой человек может иметь сильный математический уклон. Вплоть до того, что является не столько геймдизайнером, сколько узкоспециализированным математиком.
В рамках структуры могут быть свои градации, например: Lead Game Designer, Senior Game Designer или Junior Game Designer. И может быть разное приложение усилий геймдизайнера: от высокоуровневого дизайна до низкоуровневого. Низкоуровневый – это когда человек руками настраивает, скажем, параметры выстрела с точностью до тысячной доли. А потом тестирует. А потом меняет одну цифру. И снова тестирует.
Левел-дизайнер (Level Designer)
Хотя многие считают эту специализацию родственной или вспомогательной по отношению к геймдизайну, на самом деле это отдельная, важная роль, основным полем деятельности которой является аспект взаимодействия игрока (напрямую или же через героя/действующее лицо/протагониста) с игровым окружением и все закладываемые в этот процесс принципы и механики. Если очень сильно упростить, то левел-дизайнер создает дизайн уровней/локаций (потому он и называется левел-дизайнером). То есть он, как правило, руками копается в редакторе и расставляет объекты.
Программист / Разработчик / Developer
Будет безумием запихивать сюда словарное определение программиста – вы и так понимаете, о чем идет речь. Но нужно сделать пару важных пояснений. Программист работает не в вакууме и не является знатоком всех языков мира. У него есть специализация – и возможность ее изменить и расширить. Самые распространенные языки в игровой индустрии – это C++ и C#. Можно еще упомянуть Java, но в целом это все производные от С.
Программисты работают в программной среде и – если не пишут собственный движок – то внутри какой-то конкретной технологии. И, соответственно, владеют инструментарием этой технологии. Во-многом поэтому их зачастую и называют девелоперами – их работа сводится не только к написанию кода. Более того, существуют девелоперы, которые, строго говоря, не совсем программисты. Например, они хорошо понимают Unreal Engine 4, но скриптуют на Blueprints, а C++ не просто не используют, но даже и не умеют.
Как уже будет отмечено далее по тексту, если вы ищете программиста, то вам следует учитывать конкретную специфику и нюансы. Например, если у вас Unreal Engine 4, то может быть целесообразнее искать программиста на C++, а не «UE4-программиста». С технологией, если что, познакомится, освоит.
Вкратце упомяну, что существуют еще backend-программисты (они же «серверные программисты»), но это тема для отдельного разговора (да и его стек может быть разным), и вообще у них там своя атмосфера.
Технический директор
Может называться CTO (Chief Technical Officer). Как правило, сам является программистом/разработчиком высокого уровня (ну или как повезет). Хорошо знает технологический стек и, собственно, формирует его. Это главный «технический» человек на вашем проекте.
Product Owner
В случае Product Owner и Project Manager используется, в общем-то, терминология методологии SCRUM (и производных от нее). Product Owner (условный «владелец продукта») формирует задания (фичи, user stories[9], называйте как хотите) и отдает их человеку-функции с названием Project Manager («проектный менеджер» или «управляющий проектом»). Тот рубит это все на мелкие куски, ставит в план и раздает задания конкретным специалистам.
Должности Product Owner почти никогда и нигде не существует. Это именно роль. Ее в том или ином виде почти всегда принимает главный идеолог проекта.
Проджект-менеджер (Project Manager)
См. выше. В голом виде является прорабом. Или ответственным секретарем редакции газеты. От него требуется понимать пайплайн производства – кто чем вообще занимается. В стандартной конфигурации от него совершенно не требуется что-то выдумывать или во что-то играть. Он реально может быть человеком со стройки, которого хорошо проинструктировали по поводу специфики отрасли. В некоторых IT-компаниях вам могут рассказать, что это не совсем так, и вообще ему желательно иметь техническое образование и сертификаты PMBOK или типа того. В целом это неправда.
В реальности многие компании подразумевают под проджект-менеджером что-то свое, иногда уходящее в мультикласс. Или даже называют этих менеджеров как-то по-другому. Зафиксированы случаи, когда издатели мобильных игр называли проджекта с элементами аналитика «продюсером оперирования».
Продюсер (Producer)
Загадочная специальность, функционал которой бывает очень разным в зависимости от компании и даже конкретного проекта. Упрощенно – это арбитр в спорах между всеми другими специалистами/отделами на проекте или же в конкретном секторе проекта. Человек, который говорит, «что такое хорошо, а что такое плохо».
На практике внутри физического человека-продюсера может быть зашито еще несколько ролей. Например, он очень часто (а в маленьких студиях – всегда) бывает в той или иной степени геймдизайнером. Обычно высокоуровневым. Вплоть до совмещения в своем лице должности главного геймдизайнера. Он может быть носителем vision (видения) и, соответственно, нести на себе функционал описанного выше Product Owner и описанного ниже креативного директора. Отчасти он может заниматься работой арт-директора (или человека, который корректирует работу арт-директора). Во многих случаях он может превращаться в персонажа «в каждой бочке затычка». Иногда это хорошо и удобно, потому что быстро устраняет проблемы. Иногда это очень плохо, потому что он попросту начинает мешать людям работать, вместо того чтобы периодически их направлять и вообще поменьше отсвечивать.
Сразу оговоримся, что речь идет в первую очередь о внутреннем продюсере – то есть о члене вашей команды. Потому что продюсеры еще бывают внешними (см. ниже).
Внешний продюсер
Как правило, это вообще не совсем продюсер, а скорее разновидность аккаунт-менеджера. Отличается тем, что он не входит в вашу команду. Обычно это специалист, которого к вам прикрепляет издатель (если он у вас есть). Как правило (по уму) он взаимодействует с вашим внутренним продюсером. Скидывает фидбек и что-то предлагает. У него есть начальство, и он перед ним отчитывается и утверждает планы и финансирование. В случае чего он может начать продавливать свои «хотелки» с помощью аргумента «пока не сделаете, денег не пришлем».
На практике вашим внешним продюсером может оказаться как студент, так и человек, который работал на производстве, спродюсировал пару десятков игр и в разы квалифицированнее любого из ваших сотрудников. Ну или (чаще) какая-то промежуточная стадия между этими двумя крайностями. Причем так сразу и не скажешь, какой из этих вариантов лучше лично для вас.
Линейный продюсер
Термин в игровой индустрии встречается редко, но его нужно упомянуть. Понимается по-разному, но это что-то вроде ассистента продюсера с функционалом (или кусками функционала) проджект-менеджера.
Исполнительный продюсер (Executive Producer)
Часто используется как vanity-должность. Например, если человек – соучредитель компании и да, имеет какое-то высокоуровневое отношение к производству конкретной игры. Например, сказал, что «делаем про человека с ружьем». Тогда (барабанная дробь!) он может вписать в должность вот что-то такое.
Помимо этого интересного случая, такая должность может также обозначать, что продюсеров на проекте больше одного и этот, в целом, главный. Но просто основную часть текучки сваливает на подчиненных.
Креативный директор
Крайне редко используется как название должности. В наших широтах очень часто так называют, представьте себе, людей, которые придумывают «креативы». Баннеры, короче, делают. Но вообще это носитель ви́дения продукта.
В большинстве случаев если главный продюсер на проекте не является креативным директором, то есть вопросы, как так могло получиться.
Арт-директор
Иногда может называться Lead Artist. Формирует арт-стиль. Следит, чтобы его придерживались. Модифицирует его. Проверяет весь арт в игре. В некоторых случаях может иметь не только «хороший вкус», но и быть техническим специалистом, который руками полезет в движок выставлять свет (т. е. немножко техартистом). В небольших (и даже средних размеров) командах роль арт-директора зачастую делят между собой (или даже полностью поглощают) люди, у которых должности называются как-то по-другому. Например, лид-артист и продюсер. Или жена инвестора, которая попросит перед сдачей этапа переделать трех персонажей, потому что ей не нравится, и поэтому денег в следующем месяце не будет.
3D-моделлер (3D Artist)
Делает 3D-модели в одном (или нескольких сразу) графических пакетах. Зачастую он же их и текстурирует.
Возможны частные случаи, указывающие на конкретную специальность. Например, Environment Artist – т. е. он тоже моделлер, но по окружению (а персонажей не делает и, возможно, толком и не умеет).
2D-художник (2D Artist)
Рисует двухмерные картинки в одном (или нескольких) графических пакетах. Это может быть промо-арт, атмосферный арт (для производственных целей), концепт-арт, 2D-ассеты для игры, скетчи для моделлеров, куски интерфейса. По-разному, в зависимости от проекта.
VFX Artist (художник по визуальным эффектам)
Делает визуальные эффекты. Все ваши красивые взрывы, дымок, шлейфы от ракет и так далее. Вероятно, он же их интегрирует.
Нарративный дизайнер / Сценарист
Пишет текст. И этот текст может быть очень разным в зависимости от того, что за игру вы разрабатываете. Он может разрабатывать сюжет (если он у вас есть – потому что в половине игр его таки нет), писать диалоги, сопроводительные тексты, описания предметов и так далее.
В крупных проектах, вроде Red Dead Redemption 2, это могут быть серьезные профессиональные сценаристы.
Аниматор
Работает в курортных городах Турции и Египта. В остальное время анимирует 3D-модели и экспортирует и настраивает анимации в движке. Разумеется, есть еще и 2D-аниматоры. Но это ближе к 2D-художнику, и такой функционал обычно идет через дробь.
Дизайнер интерфейсов (UI/UX Designer)
Тут есть интересный момент, что, как правило дизайном интерфейса занимается не только специальный человек с должностью «дизайнер интерфейсов» (или внешний человек), но и члены основной команды (например, геймдизайнер). Во многих случаях дизайнер, отвечающий за отрисовку элементов UI и вообще usability[10], знает об игре достаточно мало. И черновое проектирование (на уровне кривых – или не очень – мокапов[11]) за него сделает кто-то другой, понимающий игру и ее фичи. Поверх обрисует красиво, подвинет элементы, предложит что-нибудь.
Интегрирует все художества в движок программист. И за ним нужно проверять, потому что с первого раза он нормально не сделает. Со второго – тоже.
Композитор/звукоинженер
Это, строго говоря, две разные роли. Но если команда небольшая, то зачастую это один человек. И во многих случаях человек внешний.
Чем занимается композитор – очевидно. Звукоинженер делает SFX (звуковые эффекты). Шаги персонажа, скрип двери, падение гильзы и так далее. И – что особенно важно – во многих случаях он же и настраивает все аудио в движке.
В зависимости от ситуации (и бюджета), это может выглядеть немного по-разному. Например, звуки выстрелов (их больше одного) можно смастерить, опираясь на бесплатные (или платные) библиотеки звуков. А можно арендовать стрельбище и бегать там со звукозаписывающей техникой. А потом все это обрабатывать.
QA/Тester
Отвечает за тестирование игры. Цели тестирования могу быть разными. Это и банальный отлов багов в геймплее, и общая работоспособность продукта, и формальное техническое соответствие определенным параметрам (например, гайдлайнам[12] платформ). Много вариантов, и не имеет смысла вдаваться совсем уж в детали.
Как правило, многие члены команды в той или иной степени принимают на себя роль неформального тестера. То есть они запускают билды[13] и что-то говорят по поводу увиденного. Есть и формальное тестирование, и, в зависимости от ситуации, для него может работать отдельный специалист, который занимается только тестами. Или целый отдел со своей методологией. Очевидно, что QA может быть (и зачастую бывает) внешним. Есть огромное количество контор, которые специализируется именно на разных видах тестирования. Начиная от упомянутого «отлова багов» (это первое, что людям приходит в голову, когда они слышат про QA) и заканчивая организацией фокусных групп.
Business Development Manager / Business Development Director
Менеджер/директор по развитию бизнеса (он же «биздев»). Термин по-разному трактуется в разных компаниях и покрывает собой пространство от человека, который приводит сделки, до девочки, раздающей на выставке визитки со словами «мы можем локализовать вашу игру» или «у нас есть трафик».
Аналитик (Analyst)
Ковыряется в метриках. Если это онлайн-проект. Изучает рынок. Если у вас нарративный шутер для ПК, то вы сам себе аналитик.
PR-менеджер (PR Manager)
Абстрактно занимается «продвижением продукта» (и/или компании). В реальности конкретные действия сильно зависят о компании, от ее места на рынке и кучи разных факторов. Может быть человеком с сетью контактов с инфлюенсерами, может быть копирайтером, может быть человеком, который разводит болтологию на выставках, рассказывая об игре. Зачастую – все сразу. В маленьких командах кусок функционала PR-менеджера почти всегда валится на главного идеолога проекта. При условии, что он умеет читать, писать и говорить хотя бы на среднем уровне. (Если не может, то это трагедия.)
Комьюнити-менеджер (Community Manager)
Работает с комьюнити. Постит в фейсбучек. Зачитывает тосты, проводит конкурсы. Может трактоваться как своеобразный подвид PR-менеджера.
Как уже было сказано, терминология немного гуляет по индустрии, и конкретная должность может вмещать в себя даже достаточно неочевидные роли. При этом и сами роли иногда трактуются самым экзотическим образом. Но основу нужно знать и не путаться. И – если вы ищете специалиста – понимать, что вы вообще от него хотите (вы удивитесь, но многие представляют это достаточно смутно). Набор скиллов у человека может быть разным, но стоит понимать какие-то, казалось бы, очевидные вещи. Например, что продюсер всегда кое-что смыслит в геймдизайне, что не очень рационально требовать от левел-дизайнера умения составлять питчи проекта, а от геймдизайнера – опыта работы комьюнити-менеджером. Этот слегка шизофренический ряд звучит как шутка, но каждый из примеров – реальный случай.
Кроме того, старайтесь использовать терминологию корректно и не лепить детских ошибок. И вообще, перечитывайте, что написали. Не размещайте вакансию «гей-дизайнера», если не хотите получить вот прямо гей-дизайнера – ну или глуповатые улыбки. (Да, это тоже реальный пример, а не просто избитая шутка, построенная на созвучии двух слов.) Это же касается не только ролей/должностей, но и специализированной лексики вообще. Она не такая сложная, ее можно освоить. Нельзя писать «фит бэк» вместо «фидбек», нельзя называть моделлеров «модельерами», не нужно называть сеттинг «сейтингом». Этим вы отпугнете людей и сообщите, что у вас проблемы с использованием сложившейся терминологии (т. е. у вас мало опыта), у вас не очень хорошо с грамотностью, вы небрежны и у вас плохо с английским.
Не стоит недооценивать этот момент и сваливать все на «и так поймут». Да, поймут (см. выше). И, вероятно, разорвут коммуникации. Если человек из банковской сферы будет в переписке оперировать терминами «кридит», «ре-фенансированье» и «каш баг», с ним тоже перестанут разговаривать. По очевидным причинам.
Резюмируя главу
Подводя итоги главы, исходя из представленных данных, алгоритм примерно понятен. Автор и команда разработчиков проекта могут успешно использовать его на уровне идеи и изначального понимания картинки запланированной игры.
Несколько раз на протяжении этой главы мы также проговаривали, что решение о том, что за игру вы разрабатываете, – это примерно половина данных для планирования. И, вероятно, у пытливого читателя возник вопрос, какой же второй фактор, влияющий на этот процесс.
Это не то, что вы собрались разрабатывать, а как именно вы собрались это делать. Об этом наша следующая глава, посвященная типу компании, которую вы собрались построить вокруг разработки игры.
1.3. Кем вы хотите быть?
Большинство начинающих разработчиков склонны недооценивать фактор типа компании, которую они хотели бы построить в долгосрочной перспективе, концентрируясь вокруг продукта и стартовой команды. Это может показаться разумным на начальных этапах, однако недостаток планирования в этом поле запросто может в ближайшей перспективе, как говорят наши американские друзья, выстрелить им в ногу.
Причин тут несколько, но основная заключается в том, что, если отпускать развитие компании на самотек, концепция будет формироваться «как придется». И на момент открытия юридического лица это будет делаться исходя из сугубо внешних факторов. Что практически всегда не на руку разработчику.
Результаты такого отношения – спешка и ошибки в момент предстоящего подписания сотрудничества с партнером, фрустрация и потеря мотивации основателями компании (игра вроде та, но хотелось семейного дружественного коллектива, а приходится масштабировать команду на десятки человек или, наоборот, хотелось крутую компанию, а мы не растем). И, что самое основное, – отсутствие правильного целеполагания в таком важном вопросе, как развитие занимающего ощутимую часть жизни занятия.
