Анимация: кадры по времени

Кадры ebiten получают из одной строки: frame := (g.tick / framesPer) % numFrames. Здесь g.tick — счётчик, который вы сами увеличиваете на единицу в каждом вызове Update, framesPer — сколько тиков длится один кадр, а numFrames — общее число кадров анимации. Деление целое, поэтому кадр держится framesPer тиков подряд, а остаток замыкает цикл: дошли до последнего кадра — вернулись к первому. При TPS 60 из урока про движение счётчик растёт ровно шестьдесят раз в секунду независимо от монитора, и анимация идёт с одной и той же скоростью у всех игроков.

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

Детерминизм — не абстракция, а рабочая привычка. Представьте баг-репорт: «на тридцать второй секунде герой дёргается». С таймером реального времени воспроизведение зависит от машины, загрузки и момента запуска; со счётчиком тиков тридцать вторая секунда — это тик 1920, и формула говорит точно, какой кадр был на этом тике. Юнит-тест анимации тоже становится тривиальным: подали тик — получили кадр, без окна и рендера.

Своё поле не единственный вариант: движок ведёт глобальный счётчик сам. Функция ebiten.Tick() возвращает число тиков — оно стартует с нуля и растёт на единицу на каждом вызове Update, тип int64, вызов потокобезопасен. Именно на нём держится пример из таблицы ниже. Но глобальный тик нельзя ни сбросить, ни отложить, ни завести второй параллельно — а для смешения ходьбы и удара нужен именно свой счётчик у каждого типа анимации.

Скорость анимации выражается одним целым числом — тиками на кадр — и вся её настройка сводится к подбору этого числа. При TPS 60: framesPer 2 даёт тридцать кадров в секунду — бешеная вертлявость, годится для мелких эффектов; framesPer 4 — пятнадцать кадров, бодрая ходьба; framesPer 8 — семь с половиной, тяжёлая поступь большого монстра; framesPer 15 — четыре кадра в секунду, расслабленный Idle-покачивание. Пиксель-арт традиционно живёт на низких частотах: шесть-двенадцать кадров в секунду для ходьбы — норма, а не экономия.

Пара практических следствий из целочисленного деления. Первое: частота анимации привязана к TPS, и если вы поднимете тики через SetTPS для точной физики, все анимации ускорятся во столько же раз — держите framesPer рядом с TPS в конфиге, а не размазанным по коду. Второе: скорость не дрожит. Формулы на вещественном времени — elapsed * fps с накоплением дробей — дают рывки при пропущенных кадрах; целочисленная схема нечувствительна к пропускам Draw вообще: кадр вычисляется из номера тика, а тик по контракту движка приходит ровно TPS раз в секунду.

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

Анимация спрайтов с видом сверху или сбоку почти всегда хранится рядами: каждый ряд листа — одно направление ходьбы, кадры внутри ряда — фазы шага. Первый ряд — шаг вниз, второй — влево, третий — вправо, четвёртый — вверх: раскладка, к которой привыкли редакторы и готовые паки спрайтов. Формула кадра дополняется выбором ряда: sprite := rows[row][frame], где rows — срез срезов кадров, нарезанных из атласа при загрузке. Направление выбирает ввод — клавиши из урока про клавиатуру и курсор из урока про мышь, а фаза шага по-прежнему считается по тикам.

Здесь проявляется выгода нарезки кадров один раз при загрузке: заготовьте rows при старте, и переключение направления станет сменой индекса среза — ноль работы в кадре. Внутри ряда анимация циклится модулем по числу кадров ряда, а не по общему числу ячеек: у направления может быть шесть кадров, у удара — четыре, у стойки — два. Если лист разрезан с зазорами, формулы margin и spacing из атласного урока добавляют по слагаемому в вырезание, но анимационная арифметика не меняется.

Две категории анимаций живут по разным правилам. Циклические — ходьба, стойка, взмахи крыльев — замыкаются модулем и крутятся бесконечно: последний кадр перетекает в первый, и разрыва не видно, если художник нарисовал петлю аккуратно: поза на последнем кадре обязана логически продолжаться в первом, иначе на стыке виден скачок, который лечится рисунком, а не формулой. Однонаправленные — удар, взрыв, вспышка смерти — проигрываются ровно один раз: взмах меча не должен повторяться сам по себе, пока игрок не нажал кнопку ещё раз. Для них формула другая: кадр растёт до последнего и остаётся на нём — f := tick / framesPer; if f > last { f = last }.

Однонаправленной анимацией управляет флаг: нажатие кнопки атаки заводит отдельный счётчик с нуля, Update прокручивает кадры удара, а по достижении последнего возвращает героя к ходьбе. Пока удар играет, ввод движения обычно игнорируется или копится — это уже игровое решение, но механика кадров от него не зависит. И держите числа в данных: таблица анимаций вида «имя, первый кадр, число кадров, framesPer» превращает добавление новой анимации в строку конфига вместо копирования формулы — пригодится, когда героев станет больше одного.

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

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