Как упростить разработку игры в одиночку — несколько полезных советов для новичков

В основном они связаны с организацией процесса.

Создатель инди-игры Svarog's Dream под ником Lynxbird опубликовал на Reddit список советов для соло-разработчиков. В основном они касаются организационных вопросов, которые помогают упростить рабочий процесс. Выбрали из текста главное.

A Short Hike. Все игры, упомянутые в этом тексте, сделаны соло-разработчиками
A Short Hike. Все игры, упомянутые в этом тексте, сделаны соло-разработчиками

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

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

VVVVVV
VVVVVV

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

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

Stardew Valley
Stardew Valley

Используйте систему управлениями версиями. Можно использовать стандартный Git — он бесплатный и имеет неограниченное пространство для хранения. Если ваш проект занимает больше, чем несколько гигабайт, то стоит подключить Git Large File Storage. Это позволит вам без проблем экспериментировать со своей игрой, и в случае ошибки вы сможете легко вернуться к предыдущей версии.

Оставляйте комментарии. Можно это делать в специальном сервисе, например, Jira, Azure Devops Backlog, или же просто записывать на бумаге. Фиксируйте там новые идеи, отмечайте, чем занимались в последний раз, чтобы потом было проще разобраться. Если вы столкнулись с ошибкой и не хотите исправлять её сейчас, опишите её и продолжайте заниматься текущей задачей.

Papers, Please
Papers, Please

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

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

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

Undertale
Undertale

Занимайтесь продвижением одновременно с разработкой. До релиза у вас есть время, чтобы собрать лояльную аудиторию и показать игру как можно большему числу людей. Попытайтесь привлечь внимание: например, опубликуйте гифку с милым существом из вашей игры. Используйте Imgur, Discord, Twitter, Instagram, Facebook и другие соцсети. Чаще всего на полноценный маркетинг у вас не хватит денег, поэтому придётся проявить творческий подход.

Не гоняйтесь за новейшими технологиями. Вышла новая версия движка? Появилась новая версия IDE, новые 3D-инструменты, новая языковая библиотека, доступен новый пайплайн для рендеринга? Не спешите переходить на них. Оцените ресурсы, которые вам придётся вложить, чтобы разобраться в новом инструменте. Если выгода перевесит затраты, то оно того стоит. Если нет, то не тратьте на это время.

Не доверяйте всему, что вы читаете. Люди могут ошибаться, какие-то решения и советы могут не подойти конкретно вам. Относитесь ко всему критически.

А какие советы можете дать вы? Поделитесь ими в комментариях.

306306
106 комментариев

Хотите реально нормальные советы, а не эту воду)? Это связано в первую очередь с корованами на UE4 в одиночку, если уж вы решили делать какой - нибудь клон готики или упаси боже соулс лайк (ведь у вас не получится сделать нормальную боевку, многие пытались)
-Разбейте разработку механики на этапы и тестите после каждого микроизменения кода (так можно мгновенно пофиксить новообразованный баг или перебирать галки/функции пока не получится запилить что - то рабочее)
-Меню, выбор уровня и настройки делайте в последнюю очередь перед релизом т.к отнимает время от тестирования сцены.
-Создайте для себя простую модульную структуру для проекта которую можно расширять.Наследование тоже не забывайте, например у предметов в инвентаре должен быть общий класс (item) в который забиваются данные с бдшки, у персонажей общий контроллер который включает базовые вещи типо ходьбы и т.д.
-Ядро и интерфейс всегда должны быть отдельно (например инвентарь).
-Как можно больше данных забивайте в БДшки чтоб не грузить гиперклассом движок и быстро менять кучу данных без крашей от зависимостей (например предметы в инвентаре, классы персонажей, описания, тексты и т.д).
-Сделайте свою абилити систему, если планируется больше 3-5 способностей/интерактов/пасивок в игре, разбивать код на абилки удобнее чем держать все в одном гиперклассе / полотне блупринтов.
-Никогда не юзайте ассеты с кодом (если они не модульные), потому что они написаны индусским говнокодом и переделать их будет невозможно.
-По той же причине никогда не юзайте плагины если можно обойтись без них, потому что апдейты на плагины выходят раз в год (если вообще выходят), а чтобы их переделать нужно ещё и знать как паковать плагины, если вообще получится в этом разобраться.
-Тестите ассеты в "йохохо" версиях перед покупкой, потому что нельзя быть уверенным что подойдет игре, а что нет, вполне вероятно придется с пяток вариантов перебрать прежде чем поймешь что реально подходит и может интегрироваться в проект без конфликтов.

101
Ответить

спасибо, полезные советы! Будет классно, если вы дополните этот комментарий и превратите в полноценный пост. Уверен, что это поможет многим начинающим разработчикам

8
Ответить

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

1
Ответить

Respect. Сам до таких же выводов дошёл, но потребовалось время

1
Ответить

Не, ну это статья должна быть, пусть и короткая :)

1
Ответить

Совет мега полезный

Ответить