10 советов как довести свою первую игру до релиза

Моя первая игра вышла в Steam. Рассказываю, как это получилось и делюсь полезными ссылками.

Я часто читаю на DTF истории про то, как инди-разработчики после долгой и мучительной работы над игрой забрасывают её. Потом с новыми силами начинают новый проект… и забрасывают его тоже.

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

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

Пару лет назад я задумал сделать свою первую игру. Даже не так: пару лет назад я задумал сделать свою первую игру целиком. Мне было очень важно пощупать всё самому — всё придумать, написать, накодить, нарисовать, санимировать и зарелизить. То есть с самого начала я воспринимал свою будущую игру скорее как образовательный проект: не спеша познакомиться с Unity, C#, Github, Steamworks, itch.io и ещё десятком разных штук мне было важнее, чем всё остальное. Опыта непосредственной разработки игр у меня до этого не было, хоть я и работал к тому времени уже около пяти лет менеджером в геймдеве.

В итоге получилась игра Not Anyone’s Business But My Own. Она доступна в Steam бесплатно и запускается на Windows и MacOS.

Так, с контекстом разобрались, погнали к советам:

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

А что получилось в итоге?

Такое не очень амбициозное ТЗ, поставленное мною мне самому, во многом и помогло мне закончить игру. Конечно же, мне хотелось сделать игру мечты с корованами, открытым миром, боёвкой как в God of War и аниматиками как у Blizzard. Но ещё я понимал, что моих скиллов на это не хватит, и что в итоге игру мечты я заброшу, расстроюсь и скорее всего потеряю интерес к разработке игр вообще. Игру мечты я ещё сделаю, она от меня никуда не денется.

Разобравшись со спецификациями проекта, я приступил к написанию истории. Логика здесь проста:

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

Для написания нелинейной истории я использовал Twine (все ссылки в конце статьи). Это бесплатный инструмент как раз для таких случаев, простой в навигации и сильно экономящий время. К тому же, если ты решишь сдаться на этом этапе, у тебя хотя бы будет текстовый квест.

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

Что я там насочинял?

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

Знаю, звучит зануднее некуда, но это, правда, помогает. Вот пример: я довольно слабый программист (художник, дизайнер — нужное подчеркнуть) — много чего не понимаю и много чего не умею. Поэтому чтобы как-то компенсировать недостаток знаний, я стараюсь удерживать себя в состоянии потока, когда тебя «прёт» и ты работаешь лучше и быстрее. Главная хитрость здесь — не позволить себе выпасть из потока, а учитывая, что у большинства из нас жизнь, дети, сессия, нетфликс, думскроллинг и прочие неотложные вещи, выпасть очень легко. И тут я такой: «а я всё равно найду хотя бы 5 минут и посмотрю на свой код / сцену в редакторе / документ со сценарием перед сном — просто чтобы не забыть, над чем я тут работаю». Если есть не 5, а 15 минут — вообще шикарно. За 15 минут можно не только освежить в памяти прогресс, но и продвинуть его.

Этот совет — дитя двух предыдущих. В теории, ты будешь работать каждый день, но на практике, лишь небеса ведают, когда ты там сподобишься сесть за игру в следующий раз. И вот когда этот следующий раз настанет, ты откроешь блокнот и прочитаешь что-то вроде «Cнести Facepunch, приделать Steamworks. NET» или «Починить тот смешной коллайдер у воднапорной башни». И сразу станет тебе хорошо и ты поблагодаришь себя из прошлого за то, что не забыл оставить заметки себе из будущего.

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

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

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

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

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

В моём первом игровом проекте с дизайн-документами было всё жалко, поэтому со временем он оброс новыми механиками и даже поменял жанр. Хорошо это или плохо? В моём случае — скорее хорошо, потому что по дороге я навострился новым штукам в Unity и C#, но мне просто повезло. Если бы я работал в команде или если бы у меня были хоть сколько-нибудь жёсткие сроки, завершение проекта оказалось бы под угрозой.

Кстати, следующий свой проект я уже начал с дизайн-документа.

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

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

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

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

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

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

Вместо того, чтобы придумывать что-то своё странное, гугли проблему и ищи ответ в интернете. И да, извини за вульгарно-некорректный заголовок, но в плане количества и качества информации Unity/C# выигрывает у Unreal/C++. Stack overflow, Reddit, форум Unity, документация Unity, YouTube, наконец. Выбирай, что вылезает в поисковике первым и смотри готовый ответ.

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

Этот совет звучит крайне не логично, знаю: «вместо того, чтобы решать проблему, не решай проблему», Но практика много раз показывала, что такой подход работает.

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

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

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

Twine - бесплатный вэб-редактор для создания и редактирования нелинейных историй. Самое то для прототипирования.

GitHub Desktop - бесплатный репозиторий с дружелюбным интерфейсом

https://desktop.github. com

Библиотеки с royalty free материалами:

Zapsplat - саунд-дизайн, всякие бесплатные «вжух» и «кабам» лежат здесь.

Fontesk - всякие прикольные шрифты

Fesliyan Studios - музыка, разбитая по категориям и жанрам

Супер-полезные обучающие YouTube-каналы про разработку игр (Unity) :

Brackeys

Официальный канал Unity

Dapper Dino

https://www. youtube.com/c/dapperdinocodingtutorials

Code Monkey

https://www. youtube.com/@CodeMonkeyUnity

Auro Dev

Инструменты для интеграции функций Steam (ачивменты, списки друзей…)

Facepunch - попроще в освоении, но не работает с современными версиями MacOS.

Steamworks.NET - чуть-чуть посложнее, но работает с MacOS без проблем.