Статья удалена

Неудачный опыт — тоже опыт.

Привет. Меня зовут Артём, днём я работаю разработчиком игр, а вечером — тоже работаю разработчиком игр. Последние три года мы с командой делали свою первую инди-игру — мобильную hack 'n slash Ancient Rivals. В этой статье я хочу описать наш опыт и некоторые выученные за это время уроки.

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

В качестве нового проекта я решил делать мобильный Diablo-подобный слэшер. В то время казалось, что конкурировать на этом рынке проще, чем на рынке ПК-игр, который заполнен ААА-релизами. Чтобы сделать игру, нужно либо научиться программировать, либо собрать команду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По мере развития ваших навыков может появиться ещё одна проблема, которая понижает мотивацию: это то, что я называю skill cap. Рано или поздно ваши навыки упираются в потолок. Вы способны делать более качественную и значительно более комплексную работу, чем требует текущий проект. Конечно, вы можете переделать всю графику и переписать весь код, но будете ли? Скорее вы решите, что «и так сойдёт», главное ведь, что работает. Чем дольше длится разработка, тем более явно проявляется skill cap. Причём интересно, что это происходит как в инди, так и в коммерческой разработке.

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

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

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

На мой взгляд, использовать этот контент вполне нормально, если вы привносите туда что-то своё, а не берёте и используете всё «как есть». В этом нет вашего труда и вашей индивидуальности. В разработке Ancient Rivals был момент, когда мы осознали, что сами не справляемся с созданием всего необходимого 3D-контента. Мы решили закрыть вопрос путём покупки персонажей и наборов моделей окружения в магазинах. Это сильно помогло нам, иначе бы просто не справились.

У магазинных ассетов, между тем, есть известная особенность — действительно готовый к употреблению контент почти никогда не встречается. Примеры того, что мне приходилось чинить: UV и lightmap UV, скиннинг персонажей, чудовищная полигональная сетка с дырами и артефактами, префабы, материалы, параметры импорта и прочее. Здесь надо быть готовым к чему-угодно. Всё становится в два раза хуже, когда вы делаете «мобилочку», и каждая мелочь имеет значение в свете требований к производительности.

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

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

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

Крутая графика может вытянуть игру в отдельных случаях, но если ваша игра про геймплей, то без хорошего прототипа вы обрекаете себя на муки. Разумеется, ситуация может быть обратной: если ваша игра текстовая, или вы работаете с жанром, ставящим красивую картинку выше геймплея, например, walking simulator. Иными словами, не надейтесь, что осилите крутой арт для бродилки а ля Firewatch, если в вашей команде одни программисты.

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

Иллюстраторам хуже поддаётся изобретение сложных дизайнов с нуля. В качестве примеров сложных сеттингов я могу привести Horizon Zero Dawn (раннее Средневековье и роботы-динозавры) и Destiny (комплексный бленд средневековья, современности и научной фантастики). Если руководитель разработки не является концепт-художником, который затащит графику и стиль, я бы остерёгся этого пути — провал практически гарантирован.

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

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

Вторая проблема — технические ограничения. Оптимизировать требовательную к железу игру под устройства на базе Android — это сущее наказание, если вам важна красивая картинка. Вполне может оказаться, что добрые 50% работы — это оптимизация. У меня на основной работе примерно столько времени на неё и уходит. Это скучно, муторно, но за такую работу платится зарплата. Трудно представить человека, которому интересно по вечерам на инди-проекте заниматься тем же самым.

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

За редким исключением мобильная игра — это free-to-play. Более того, нельзя просто так взять и прикрутить f2p к готовой игре. С самого начала вы должны проектировать игру под выбранную бизнес-модель.

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

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

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

В нашей мобильной игре мы допустили эту ошибку. Итого: у нас нет возможности нормально монетизировать игру как f2p, и в то же время она не дотягивает до уровня paid-игры, за которую игрок готов выложить хотя бы доллар.

Если вы всё же решаете делать free-to-play и смирились с необходимостью потратить время на присущий этой бизнес-модели функционал и механики, то стоит поговорить о маркетинге. Существует мнение, что на него следует тратить 30-50% бюджета (в случае инди — вашего времени). Таким образом, у вашей команды остаётся ещё меньше времени на саму игру. Маркетинговую стратегию тоже следует продумать как можно раньше. А начинаете вы с анализа рынка.

Вам важно понять, для кого вы делаете игру, нужна ли она этим людям, будут ли они в неё играть и как именно (спойлер: в Dark Souls и в Flappy Bird играют по-разному). По большому счёту, на этом анализе строится вся ваша игра, её геймплей и графика. Львиная доля времени уйдёт на работу с коммьюнити и на маркетинговые материалы, будь то статьи, видео, интервью, смешные гифочки и прочее.

Мы же практически не вкладывались в маркетинг, и у нас нет фолловеров. Вкупе с тем, что наш f2p не способен окупить вложения в рекламу — никакие деньги вливать туда нет смысла. Закономерный итог: вряд ли нам удастся собрать большее 100 инсталлов органического траффика.

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

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

Сроки разработки — больная тема для инди-разработчика ввиду сильно ограниченного свободного после основной работы времени. Чем дольше вы работаете над проектом, тем сложнее заставить себя что-то делать, какая бы у вас ни была сила воли. Я уже писал, что мотивация к работе начинает резко падать после примерно полутора лет работы, в зависимости от вашей индивидуальности.

Последние 10-15 месяцев разработки у нас в среднем было 3-7 коммитов в месяц. Собираешь волю в кулак и через «не хочу» делаешь что-то несколько дней, пока есть энтузиазм. Как только он выдыхается, нужна ещё пара недель, чтобы снова собрать критическую массу силы воли для следующего рывка. Это действительно сложно и ни разу не продуктивно, и уж тем более в этом нет никакого удовольствия.

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

Во время создания игры зачастую возникает необходимость в программировании инструментов, так или иначе помогающих в разработке. В своё время мы потратили много времени на создание набора тулзов, позволяющих запекать лайтмапы во внешнем 3D-редакторе и возвращать в Unity. Результат был хорош, но стоило ли оно того? Скорее нет, чем да. К тому же, вскоре вышло обновление движка с новым рендерером Enlighten, который в целом уже устраивал нас. Если вы хотите делать игру — делайте игру.

К созданию любых тулзов подходите с осторожностью. Убедитесь, что вам по-настоящему нужны эти инструменты, что их никто ещё не написал (на Asset Store и в свободном доступе находится огромное количество всевозможных полезностей — пробуйте!). Если вам действительно нужен какой-то сравнительно сложный инструментарий, я бы даже рекомендовал по возможности изменить вашу игру так, чтобы избежать этой необходимости. Создание и поддержка инструментария отъедает много времени, которого у вас и так очень мало.

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

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

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

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