> For the complete documentation index, see [llms.txt](https://docs.allout.game/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.allout.game/all-out-docs/ru/skripting/game-frame-lifecycle.md).

# Жизненный цикл игры/кадра

Игры All Out работают по простому жизненному циклу: некоторые колбэки вызываются один раз при запуске, а некоторые — каждый кадр.

Эти колбэки вы реализуете либо:

* **Глобально** (на верхнем уровне `ao_*` процедурах в `main.csl`), или
* **На компонентах** (методы вроде `ao_update` этого игрока `Player` или ваших собственных `Component` подклассов)

{% hint style="info" %}
Если вы ищете «шаблон» `main.csl`, см. [Начало работы с CSL](/all-out-docs/ru/skripting/syntax.md).
{% endhint %}

## Глобальный жизненный цикл (для всей сцены)

Это процедуры верхнего уровня в `main.csl`:

### `ao_before_scene_load`

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

* Определения предметов (система инвентаря)
* Валюты (экономическая система)
* Глобальные значения/константы конфигурации

### `ao_start`

Запускается один раз при старте сцены.

Типичные случаи использования:

* Создание сущностей/префабов во время выполнения
* Инициализация глобальных систем
* Чтение общих данных сохранения игры

### `ao_update(dt)`

Запускается каждый кадр.

Типичные случаи использования:

* Игровые таймеры, менеджеры волн
* Логика спавна, зависящая от времени
* Правила геймплея

### `ao_late_update(dt)`

Запускается каждый кадр после `ao_update`.

Типичные случаи использования:

* Работа на уровне всей сцены, зависящая от итоговых позиций/состояния кадра
* Работа по «очистке» после обновлений

Интерфейс игрока должен находиться в `Player.ao_late_update`, а не в этом глобальном колбэке.

## Жизненный цикл компонента (для каждой сущности)

Компоненты (включая `Player`) могут реализовывать:

* `ao_start()`
* `ao_update(dt)`
* `ao_late_update(dt)`
* `ao_end()`
* `ao_on_state_sync()` (вызывается, когда сетевое состояние синхронизировано)

{% hint style="warning" %}
`ao_start()` не воспроизводится для каждого клиента. Когда клиент подключается после того, как объект уже был запущен на сервере, синхронизированный компонент может прийти уже с завершённым жизненным циклом запуска. Не используйте `ao_start()` для локальной на клиенте настройки отображения, которую должен выполнить каждый подключающийся клиент; воссоздавайте это отображение из синхронизированного состояния в `ao_on_state_sync()` вместо этого.
{% endhint %}

Пример:

```go
Orbiter :: class : Component {
    ao_start :: method() {
        // инициализация
    }

    ao_update :: method(dt: float) {
        // поведение каждый кадр
    }

    ao_end :: method() {
        // очистка (при уничтожении)
    }
}
```

## Куда помещать код: правило большого пальца

* **Состояние/логика для каждого игрока**: размещайте это на `Player` (см. [Добавление логики игрока](/all-out-docs/ru/skripting/player-model.md))
* **Повторно используемое поведение сущностей**: размещайте их в пользовательских компонентах (см. [Сущности и компоненты](/all-out-docs/ru/skripting/entities-and-components.md))
* **Глобальная координация / правила**: размещайте это в глобальном жизненном цикле (`ao_*` процедуры)

## Сервер vs локально

Глобальные и компонентные игровые колбэки выполняются и на предсказывающем клиенте, и на сервере. Не защищайте игровой процесс с помощью `Game.is_server()`.

Рисуйте весь UI игрока из `ao_late_update` стека вызовов, обёрнутых в `is_local_or_server()`. Используйте `is_local()` только для визуальных переопределений, специфичных для игрока. Состояние, изменённое только под `is_local()` заменяется следующей серверной синхронизацией.

Это методы в `Player_Base`. Вызывайте их у ссылки на игрока или как `is_local_or_server()` / `is_local()` внутри `Player` метода (неявно `this`).