5 советов по разработке игр от соло-разработчика

Полтора года я занимаюсь разработкой игр, а последние несколько месяцев посвятил созданию своего первого полностью самостоятельного проекта. У меня не было подобного опыта, так как ранее я участвовал в создании игр на должности Unity‑разработчика, и объём моих задач был ограничен. А теперь мне необходимо всё делать самостоятельно. Хоть я и делаю игру для мобильных устройств и веба, но чётко ощущаю, что её разработка затянулась.

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

Не пренебрегайте документацией

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

Поэтому, неважно насколько у вас большой проект, не поленитесь написать дизайн‑документ. Даже если вы хотите «слепить на коленке» за неделю игру под какой‑нибудь тренд. Уделите немного времени, чтобы тезисно набросать главные фичи — в дальнейшем это значительно упростит вам разработку.

Предположим, мы хотим сделать игру «Покатай шары», упрощённый клон популярной Going Balls, небольшой «диздок» можно написать где угодно: в том же Rider или VSCode, хоть на листе бумаги.

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

Будем ли мы делать альтернативный вариант управления, например, джойстиком или гироскопом? Как мы будем определять проигрыш — падением шара ниже определённых координат в пространстве или будем использовать коллайдеры под платформами? Для чего нам собирать монеты? Может, за собранные монеты игрок будет открывать следующие уровни? По какой системе игроку будут начисляться очки за пройденный уровень? Какие цвета мы будем использовать? Будем ли мы создавать тематические уровни?

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

Плотно работайте с референсами

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

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

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

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

Не бойтесь отказываться от некоторых идей

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

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

В итоге, за следующие 3 дня я отрисовал 90% всей необходимой мне графики, и конечный результат мне нравится гораздо больше.

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

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

Начинайте как можно раньше показывать свою игру

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

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

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

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

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

Например, моя жена помогла мне нащупать визуальный стиль игры. Я рассказал ей о сути проекта, какие эмоции он должен вызывать, после чего спросил, как она себе это представляет. Справедливости ради, стоит упомянуть, что она уже несколько лет работает UX/UI‑дизайнером. Да‑да, знаю, я использовал чит‑код. Но не спешите обесценивать опыт своих друзей и близких — даже если они никак не вовлечены в геймдев, они всё ещё смогут вас удивить отличными идеями.

Тем не менее, важно помнить одну единственную вещь — все ключевые решения в проекте должны принимать ТОЛЬКО ВЫ. Мнения людей могут быть противоречивы, профессиональные разработчики могут давать кардинально противоположные советы. Ваша задача — научиться грамотно работать с этим фидбэком.

Не бойтесь просить помощи

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

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

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

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

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

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