«Свой проект», большой издатель и тысячи строк боли

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

Центром команды был парень, наш старший разработчик. Ему было 23, и на тот момент он уже 7 лет программировал. Я смотрел на него как на пример: уверенный, самостоятельный, всё знает. Для 16-летнего меня он был почти легендой.

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

— Почему у нас 6000 строк в одном скрипте?

— Где архитектура? Почему переменные называются a, b1, mainLogic?

— Почему мы дублируем код, а не выносим общие части?

Тогда я впервые понял: человек с «7 годами опыта» может оказаться на уровне, лишь немного превышающем мой, новичковый. Просто потому что все эти годы он писал только свои проекты — без критики, без роста, без окружения, которое тянет вверх.

Игра не взлетела. Хотя был издатель

Да, у нас был издатель. Большой, уважаемый, с контактами в индустрии. Мы дошли до стадии открытого теста, но игра не зашла аудитории. Почему?

• Механики были не до конца продуманы

• Баланс — почти случайный

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

• Новый контент добавлялся вручную, через копипаст

• И всё это писалось в духе «я так чувствую, значит правильно»

Проект буквально задохнулся от неструктурности. Люди старались, но система не тянула. Всё рушилось при попытке внести малейшие изменения.

6000 строк боли

Я до сих пор помню файл MainGameScript.cs. Это был единый скрипт, в котором хранилось всё: логика спавна, атаки, анимации, сохранения, работа с сетью, даже музыка. Один класс. Несколько тысяч строк. Всё связано между собой через глобальные переменные, флаги, костыли.

Менять там что-либо было как обезвреживать мину.

— «Главное — не трогай там сверху», — говорили. — «Оно как-то работает».

Это был учебник антипаттернов. flagImportant, bool superFix = true; // костыль, не трогать, CheckChecker() и другие монстры, порождённые отсутствием структуры и контроля. Всё это существовало потому, что никто не знал, как нужно. А тот, кто должен был знать — просто не знал сам.

«Пусть побудет, вдруг пригодится»

Отдельное веселье — гигантские закомментированные блоки. 300, 500, иногда тысяча строк. Иногда вложенные /* */, иногда просто Ctrl + K, C.

Спрашиваешь:

— Зачем оно здесь?

Ответ:

— Ну, пусть побудет. Вдруг пригодится.

Никогда не пригодилось.

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

В профессиональной разработке так не делают. Нужен старый код? Git всё помнит. Ненужный код? Удаляй. Всё, что работает «на авось» — это технический долг, который однажды сожрёт проект.

Мораль

Ты можешь писать код 7 лет — и остаться на уровне джуна.

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

Ты можешь думать, что знаешь лучше всех — и стать тормозом своего же проекта.

Если ты не учишься — ты не растёшь. А если не растёшь — начинаешь деградировать, даже не замечая этого.

Делать своё — это классно. Но если ты всё время работаешь только на свой вкус, без фидбэка, без ориентиров, без среды, где кто-то умнее тебя — ты просто ходишь по кругу.

Что делать вместо этого

• Иди в команды, где ты не самый умный

• Разбирай чужой код — особенно тот, который тебя бесит

• Учись архитектуре, не только на собственных ошибках

• Делай мелкие проекты на 1–2 недели, а не один долгострой на годы

• Показывай свой код, проси фидбэк

• Не бойся сказать: «я не знаю, как лучше» — это нормально

Заключение

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

Не бойся делать маленькие игры. Не бойся быть слабее. Бояться стоит только одного — остаться на месте.