Работа в геймдеве: мои ошибки как лида инди-команды

Работа в геймдеве — это не только про креатив и любовь к играм. Иногда это — микроменеджмент, стресс и борьба за качество. В этой статье я расскажу, как чуть не угробила инди-игру в духе Slime Rancher, когда пыталась делегировать геймдизайн в своей команде, работая на Unreal Engine 5.

Наша идея родилась как смесь фермы и tower defense. Представьте Slime Rancher, где милые монстры не просто прыгают, а регулярно атакуют ваше ранчо. Вы не только выращиваете их, но и защищаете ферму от них же. Эта двойственность казалась нам свежей. Unreal Engine 5 мы выбрали, так как участники команды (в том числе я, кодерка) имели годовой опыт работы в этом движке. Команда собралась быстро, скажем так, у нас была общая цель — получить опыт в длительной разработке игры, а не на джемах.

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

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

Я пыталась вводить правила: просила писать ТЗ, предлагать план тестов. Но он выполнял это формально. Итог — перегруз задач у меня, рост фрустрации у команды и провисание баланса. Мы не смогли полноценно переделать весь билд, и пришлось отдать ключевые задачи мне.

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

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

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

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

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

Раньше мы неделями обсуждали, теперь — делаю прототип за вечер и тестирую. Не потому что я лучше, а потому что путь стал короче.

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

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

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