Структура игрового проекта

Скелет игры на Ebitengine умещается в шесть пакетов, и у каждого — одна причина существования. main — единственная задача: создать Game и вызвать ebiten.RunGame, обработав ошибку; никакой логики, ввода или отрисовки. internal/game — сердцевина: структура Game, её State и сцены из урока про сцены, включая переходы и хуки входа. internal/world — мир как он есть: игрок, враги, коллизии, тайлмап — всё, что существует независимо от того, как нарисовано. internal/entities — типы сущностей и поведение: структуры с методами шага, поиска цели и анимационных фаз. internal/ui — всё, что видно поверх мира: HUD, меню и счёт из урока про игровое состояние. internal/assets — чтение и раздача ресурсов: спрайты, шрифты, звуки. Названия в схеме не случайны: их стоит вводить один раз на проект и не переименовывать между играми — единый словарь экономит переключение контекста при возврате к старому коду. Зависимости идут в одну сторону: main ведёт к game, game — к world, world — к entities, а ui смотрит на мир через узкий интерфейс и не заглядывает в поля. Как только появляется стрелка в обратную сторону — сущность тянет шрифт, мир знает про меню, — скелет болен, и лечить надо границу, а не симптом.

Каталог internal в Go — не договорённость, а правило компилятора: пакеты внутри него импортируются только кодом того же модуля. Для библиотеки это способ ограничить публичный API, для игры — гарантия автономности: чужой проект не сможет импортировать ваши сцены и мир, а значит, их можно перестраивать, не думая о внешних потребителях. Вторая причина практичнее — самоограничение. Когда пакеты лежат в internal, «временно» утащить зависимость в соседний репозиторий не получится: компилятор не выпустит импорт наружу, и граница работает даже против автора. Границу ставят в корне модуля — mygame/internal/… — чтобы она покрывала все пакеты сразу, а имена внутри держат короткими и строчными: game, world, ui, assets. Один пакет — одна ответственность, и как только в имени просится союз «и», это сигнал, что пакет пора делить. Если появится настоящий повод показать часть кода наружу — обёртка для другого проекта — её выносят в отдельный публичный пакет, а не открывают internal. Ещё одна выгода границы — скорость сборки и чтения: пакеты компилируются независимо, а новый участник команды открывает не весь проект, а тот слой, который ему нужен. Бонус достаётся тестам: тест мира собирается без окна и шрифтов, потому что мир не тянет ничего, кроме собственных типов.

Самая частая каша начинается там, где HUD берёт данные: дешевле написать world.Player.Score прямо в drawHUD — и вот ui знает про мир всё, а переименовать поле в мире значит сломать отрисовку. Правило курса другое: ui объявляет интерфейс StatusSource с методами Score() int и LivesLeft() int, а world реализует его своим состоянием. Стрелка зависимости разворачивается: ui ничего не знает про мир, мир просто оказывается пригоден для отрисовки. Второй механизм — события. Вместо опроса каждого тика игра рассылает факты: монета собрана, враг уничтожен, уровень пройден, — и HUD обновляет числа. Опрос для игр курса допустим, но события масштабируются лучше, когда слушателей несколько: звук взрыва, частицы и счётчик комбо подписываются на один факт. Плата за правило — пара строк на интерфейс, выигрыш проверяется быстро: HUD тестируется с фейкой вместо мира, пауза и меню не тянут за собой коллизии, а мир переиспользуется с другим экраном. Маленький контракт вместо знания о чужих полях — тот же принцип, что в любом сервисном коде. Проверка направления проста: откройте файл internal/ui и посмотрите список импортов — там не должно быть ни одного пакета мира; если он есть, границу протекло, и чинить надо сегодня, пока протечка одна.

Компилятор Go запрещает циклы импорта: если world импортирует entities ради типа Enemy, а entities захотел вызвать метод мира, сборка падает с сообщением import cycle not allowed — и это лучший момент для исправления, потому что ошибка поймана до запуска. Лечат цикл переносом: спорный тип уезжает в третий пакет, который импортируют оба. Практика курса — общий пакет внутренних типов, например internal/gamedata: структуры сущностей без поведения, которые мир, сцены и UI согласны использовать. Важно не превратить лекарство в болезнь: gamedata держит только данные без зависимостей, и как только в него просятся методы с вводом или отрисовкой, это сигнал, что граница проведена не там. Правильнее вообще не доводить до цикла: поведение сущностей описывается внутри entities, а мир лишь владеет коллекцией сущностей и вызывает их методы. Тогда стрелки остаются деревом, компилятор не получает шанса на жалобу, и структура игрового проекта переживает любое пополнение без перелопачивания импортов. Стоит запомнить порядок исправления: сначала поискать, кому на самом деле нужен тип, потом двигать его к владельцу, и только в крайнем случае создавать общий пакет — не наоборот.

Сцены из урока про архитектуру — первый кандидат на правильное распределение: каждая сцена — структура со своими полями, Game хранит только current, а данные едут при входе через конструктор. Меню держит пункты и лучший результат, бой — мир, счёт и частицы, экран поражения — финальную статистику. Сцена боя владеет миром, но не рисует HUD: цифры на экране делает internal/ui, которому бой отдаёт себя как StatusSource. Типовая ошибка — сделать Game складом всего: поле score рядом с state рядом с world, и вот переходы между сценами снова обмениваются через глобальное хранилище, а тест сцены требует собрать всю игру. Проверка простая: если поле нужно только одной сцене, оно живёт в этой сцене; если двум — между ними контракт, а не общий доступ. Так структура игрового проекта остаётся направленной на всём пути к итоговому проекту, где пакеты курса собираются в одну аркаду и любое нарушение границы видно по импортам. Отдельный приз — переиспользование: экран паузы из урока про сцены подключается к любому миру, который умеет StatusSource, и вы пишете его один раз на весь курс.