Работа в геймдеве — это не только про креатив и любовь к играм. Иногда это — микроменеджмент, стресс и борьба за качество. В этой статье я расскажу, как чуть не угробила инди-игру в духе Slime Rancher, когда пыталась делегировать геймдизайн в своей команде, работая на Unreal Engine 5.
Как всё начиналось — идея, команда, жанр
Наша идея родилась как смесь фермы и tower defense. Представьте Slime Rancher, где милые монстры не просто прыгают, а регулярно атакуют ваше ранчо. Вы не только выращиваете их, но и защищаете ферму от них же. Эта двойственность казалась нам свежей. Unreal Engine 5 мы выбрали, так как участники команды (в том числе я, кодерка) имели годовой опыт работы в этом движке. Команда собралась быстро, скажем так, у нас была общая цель — получить опыт в длительной разработке игры, а не на джемах.
Ошибка лида — геймдизайнер без системы
Почему я решила доверить геймдизайн
На мне уже был код и лидерство, а тут ещё и пришлось на себя геймдизайн взять, так как наша геймдизайнерка не смогла выполнять свою работу из-за внешних обстоятельств. Когда в команде появился человек, который хотел взять на себя геймдизайн — мы обрадовались. Я знала, что у него есть опыт в разработке НРИ, да и геймдизайну он уже два года учился, так что решила довериться.
Что пошло не так: фичи без фундамента
Поначалу казалось, что всё идёт хорошо. Он предлагал идеи, улучшал документацию, «оживлял» геймдизайн. Но быстро стало понятно: он не видел системных проблем. Его подход был точечным: придумать интересную механику — и ждать, что кто-то её проверит. Например, он заменил систему ресурсов на множество построек с уникальными эффектами. Это выглядело свежо, но сломало автоматизацию и связь между фермерством и защитой. В итоге наш игрок просто стоял у точки, которую нужно защищать, и не отходил от неё, так как автоматизировать борьбу с врагами могла только одна из построек — самая дорогая. В итерации, придуманной мной, такой проблемы не было, так как там все здания стреляли во врагов автоматически.
Чем закончился эксперимент
Я пыталась вводить правила: просила писать ТЗ, предлагать план тестов. Но он выполнял это формально. Итог — перегруз задач у меня, рост фрустрации у команды и провисание баланса. Мы не смогли полноценно переделать весь билд, и пришлось отдать ключевые задачи мне.
Как я изменила подход — правила найма и процессы
Тесты и стресс-кейсы вместо разговоров
Теперь я буду давать кандидатам кусок прототипа и просить найти проблемы. Это покажет, умеет ли человек думать системно, а не только генерировать идеи. Вопросы типа: «Как ты поймёшь, что твоя механика работает?» стали обязательными.
Чек-листы и «нет теста — нет билда»
Любая новая механика теперь должна проходить тест на черновом прототипе или на бумаге. Без обратной связи — она не попадает в билд. Геймдизайнер сам отвечает за проверку, не ждёт, пока кто-то заметит ошибку.
Трудные разговоры
Разговаривать и давать шансы — нормально, но стоит проверять, действительно ли разговоры что-то изменили. Если о вещах, обсуждённых в разговоре, всё ещё приходится постоянно напоминать — человек ничего не усвоил.
Умение работать в движке
Одним из аргументов нашего геймдизайнера было то, что он не тестил механики, так как не умеет работать в движке. Поэтому при найме нужно либо требовать опыт работы в движке, либо предупредить, что придётся научиться программировать черновые механики, так как это реально В РАЗЫ ускоряет процесс разработки.
Что теперь — мой подход к геймдизайну
Почему я снова делаю всё сама
После перераспределения ролей я взяла весь геймдизайн на себя. Да, это больше работы. Но теперь я могу быстро внедрять идеи и сразу видеть, как они влияют на билд — потому что я же и кодерка.
Как ускорился темп разработки
Раньше мы неделями обсуждали, теперь — делаю прототип за вечер и тестирую. Не потому что я лучше, а потому что путь стал короче.
Что бы я сказала себе в начале пути
Не надейся, что человек сам догадается, как быть полезным. Прозрачные ожидания, чёткие задачи, и — самое главное — ответственность за результат, а не просто за участие.
Заключение
В геймдеве «участие» не заменяет результат. Лучше один человек с критическим мышлением, чем трое без ответственности. Если после месяца работы ты не видишь изменений в геймплее — значит, работа не сделана.
Теперь я знаю: не тестируешь — не геймдизайнер. Не думаешь о балансе — не системный разработчик. А если тебя не волнует, как игрок будет играть — ты не часть команды.