Автор разбирает провал своего первого серьёзного инди-проекта — Coregrounds, многопользовательской PvP-игры в духе MOBA/TD, вышедшей в Steam в апреле 2018 и закрытой в конце того же года.
Хронология проекта
Старт в 2013: более года на концепт, затем полгода на прототип, опубликованный на сайте. После плейтестов с друзьями и семьёй автор основал компанию, улучшил графику и геймплей, собрал более качественную бета-версию и начал активно заниматься маркетингом и показами на ивентах (Talk & Play, A MAZE, Quo Vadis). Денег становилось меньше, Kickstarter не собрал нужную сумму, но автор был эмоционально привязан к игре и продолжил.
Он привлёк разработчика из комьюнити для серверной части, нанял художника и почти два года команда из двух программистов и художника доводила версию для релиза в Steam (апрель 2018). Запуск оказался неудачным: спешка привела к техническим и геймплейным проблемам, из-за которых большая часть стима-трафика быстро отвалилась. В течение 2018 года команда пыталась улучшать игру и маркетинг, но не смогла набрать критическую массу игроков, необходимую для PvP-проекта. Планы по мобильной версии упёрлись в серьёзные проблемы с производительностью, и команда решила закрыть сервера и открыть исходный код.
Ключевые уроки
1. Слушать советы. Опытные разработчики и статьи предупреждали: сложная мультиплеерная игра — слишком большой объём для одного человека. Автор проигнорировал это, что стало фундаментальной ошибкой.
2. Знать свои ограничения. Игра делалась «под себя», а не под реальные ресурсы. MOBA-подобный мультиплеер — огромный объём работы: сетевой код, баланс, контент, поддержка. Даже вдвоём программисты были перегружены и тратили непропорционально много сил именно на код, забывая, что это лишь часть разработки игры.
3. Не делать всё самому. Автор сознательно отказался от фреймворков и хотел писать максимум с нуля. Это было полезно для его личного роста, но вредно для проекта: использование готовых решений (например, PixiJS для canvas) могло бы избежать проблем с производительностью и сорванных мобильных планов. Вывод: изобретение велосипеда удорожает и замедляет сложные игры.
4. Маркетинг критичен. Ожидание, что «хорошая игра сама найдёт аудиторию», не оправдалось. Даже хорошие игры могут остаться незамеченными. Без бюджета и компетенций в маркетинге игра не набрала аудиторию. Для мультиплеерного проекта это смертельно: без онлайна игра не работает.
5. Не влюбляться в игру слишком сильно. Сильная эмоциональная привязанность мешала автору увидеть фундаментальные продуктовые проблемы: нишевый жанровый микс, сделанный в основном одним человеком, — рискованная комбинация. Он верил, что всё исправят «ещё немного работы, лучше графика, тонкая настройка», вместо того чтобы признать, что сама продуктовая постановка может быть ошибочной.
6. Комьюнити — и поддержка, и ловушка. У игры сформировалось ядро из нескольких десятков фанатов, которые много играли, теоретизировали, приводили новых игроков. Это создавало ощущение, что проект «вот-вот выстрелит» и мотивировало продолжать, даже когда рационально стоило бы остановиться. Позитивное ядро сообщества может искажать восприятие реального состояния продукта и рынка.
7. Важность обучения. Несмотря на коммерческий провал, автор отмечает, что получил огромный опыт: прошёл полный цикл разработки и релиза мультиплеерной игры, что помогло ему в карьере. Следующий проект он делает иначе: не мультиплеер, не на полную ставку и без ставки на окупаемость — как хобби без давления.
Выводы
- Оценивайте масштаб игры трезво: мультиплеер и сложные жанровые миксы редко подходят для первого инди-проекта.
- Используйте существующие фреймворки и инструменты, чтобы не тратить ресурсы на второстепательные задачи.
- Маркетинг нужно планировать и делать системно: без него даже хорошая игра не найдёт аудиторию.
- Эмоциональная привязанность к проекту и активное ядро фанатов могут мешать вовремя признать провал.
- Даже неудачный проект ценен как источник опыта — но цену этого опыта стоит осознанно ограничивать.
