«Свой проект», большой издатель и тысячи строк боли
Когда мне было 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, психология, планирование. Если ты хочешь сделать игру, в которую будут играть — развивай себя, а не только свой проект.
Не бойся делать маленькие игры. Не бойся быть слабее. Бояться стоит только одного — остаться на месте.