Сцены и переходы между ними

Первая модель — конечный автомат: у игры есть поле state с конечным набором значений, и каждый тик она выполняет ветку текущего состояния. Значения объявляются через iota — классический перечислимый тип Go: stateMenu, statePlay, statePause. Обновление и отрисовка зеркалят друг друга: switch в Update вызывает логику активной сцены, switch в Draw рисует её картинку. Это и есть ebitengine state в чистом виде — никакой магии движка, только дисциплина ветвления.

Сила автомата — в его честности: невозможно выполнить логику паузы, пока state равен statePlay, потому что ветка просто не выбрана. Движок не вмешивается: Update и Draw приходят с той же частотой, что и раньше, а решение, что делать в этом тике, принимает switch. Для игр курса — две-четыре сцены, переходы по клавишам — автомат закрывает вопрос целиком, и переусложнять его интерфейсами раньше времени нет причин. Порог входа минимальный: одно поле, две функции, ноль новых типов.

Для отладки автомату полезен метод String() на типе gameState: свитч по константам возвращает имя состояния, и лог выводит не ноль и единицу, а menu и play. Ещё одна честность компилятора: switch без default не заставит покрыть все состояния — пропущенная ветка ловится только тестом. В интерфейсной модели ниже компилятор требовательнее: сцена без Draw просто не соберётся.

Когда сцен становится больше пяти, switch превращается в простыню, а новые сцены заставляют править два метода сразу. Вторая модель переносит ветвление в типы: объявляется интерфейс Scene с двумя методами — Update() error и Draw(screen *ebiten.Image), и каждая сцена становится структурой, которая их реализует. У Game остаётся одно поле current Scene, и Update выглядит тривиально: return g.current.Update(). Сцена меню держит свои кнопки, сцена боя — свой мир, и каждая отвечает только за себя.

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

Смена сцены — обычная операция присваивания, но вокруг неё есть три правила, сберегающие нервы. Первое: менять сцену можно только в Update. Draw обязан быть чистой отрисовкой — изменение состояния в ней делает картинку причиной логики, и предсказать поведение становится невозможно; это та же дисциплина, что и в движении: логика в тиках, картинка в кадрах. Второе: переходы — по JustPressed, а не по зажатым клавишам, иначе пауза мерцает. Третье: в момент перехода новая сцена должна быть готова к первому же Update — инициализация живёт на входе в сцену, а не разбросана по её методам.

Присваивание вроде g.state = statePause — единственная точка перехода, и её видно в поиске по коду: наберите имя константы в grep, и все переходы в состояние найдутся мгновенно. Автомат даёт дешёвую трассируемость, которой нет у размазанных флагов isPaused, isMenuVisible и прочих булевых крошек: у автомата состояние одно, и оно всегда актуально.

Для входа и выхода сценам полезны явные хуки: OnEnter при попадании в сцену сбрасывает уровень, обнуляет счётчик анимации, готовит переменные; OnExit сохраняет то, что понадобится после. Автомату хуки дают две строчки рядом с присваиванием состояния, интерфейсу — методы структур. Без хуков типовая болезнь — меню, которое при втором входе помнит старые значения, и бой, начинающийся с того места, где игрок умер в прошлой жизни. Переход — это не только смена ветки, но и договор о чистом старте.

Загляните в Draw паузы из примера выше: сначала drawPlay, потом оверлей. Пауза — не полноценная сцена со своим миром, а слой поверх текущей: игрок должен видеть, где остановился, иначе пауза превращается в телепорт в пустоту. Технически это два вызова отрисовки в правильном порядке — мир рисуется как обычно, поверх идёт затемнение и надпись PAUSED, собранная текстом из прошлого урока. Тот же приём строят и меню, когда хочется живого фона: за стеклом меню крутится демо-режим игры.

Отдельный плюс слоя — стоимость: пауза ничего не хранит и ничего не умеет, поэтому её невозможно сломать логикой. Затемнение рисуется полупрозрачным прямоугольником — примитивы курса делают это без картинок, и оверлей остаётся парой вызовов даже в большом проекте.

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

Рано или поздно сцене нужны данные чужой: экран поражения хочет показать счёт, меню — лучший результат. Правило передачи простое: данные едут в сцену при входе, а не вытаскиваются из глобальных переменных. Автомату достаточно полей Game — счёт уже лежит в структуре, и ветка stateGameOver его читает; интерфейсу — параметр конструктора сцены: NewGameOverScene(score int). Глобальные переменные для передачи состояния соблазнительны и расплата отложена: гонки при будущих горутинах, невозможность тестировать сцену отдельно, невидимые связи между сценами. Урок про игровое состояние разложит, какие данные вообще обязаны жить в структуре, а какие — нет.

К концу урока у игры появляется скелет, который переживёт всё остальное развитие: конечный набор сцен, явные переходы, чистый старт на входе и слои для паузы. Именно этот скелет станет каркасом итогового проекта курса — мини-аркады, где меню, бой, пауза и поражение собираются в один играбельный цикл, и урок про итоговый проект начнёт не с нуля, а с автомата из этого урока. Если архитектура сцен кажется скучной бюрократией, вспомните последний проект, где меню появлялось в последнюю очередь: именно без сцены он и не добрался до конца.