> 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/docs-es/programacion/game-frame-lifecycle.md).

# Ciclo de vida del juego/frames

A diferencia de la programación basada en eventos como en Roblox, los juegos en All Out usan un modelo de ciclo de vida por frames que te permite ejecutar código cuando comienza el juego, en cada frame y al final de una sesión.

Los juegos de All Out se ejecutan con un ciclo de vida simple: algunos callbacks ocurren una vez al inicio y algunos ocurren en cada frame.

Implementarás estos callbacks de una de estas dos maneras:

* **Globalmente** (de nivel superior `ao_*` procs en `main.csl`), o
* **En componentes** (métodos como `ao_update` dentro de `Player` o tus propias `Component` subclases)

{% hint style="info" %}
Si buscas la “plantilla” `main.csl`, consulta [Primeros pasos con CSL](/all-out-docs/docs-es/programacion/syntax.md).
{% endhint %}

## Ciclo de vida global (para toda la escena)

Son procs de nivel superior en `main.csl`:

### `ao_before_scene_load`

Se ejecuta después de que la `Escena` se crea, pero antes de que se carguen sus entidades y componentes serializados. Aquí es donde normalmente registras las definiciones necesarias mientras se carga la escena:

* Definiciones de objetos (sistema de inventario)
* Monedas (sistema económico)
* Valores/constantes de configuración global

### `ao_start`

Se ejecuta una vez cuando la escena comienza.

Usos comunes:

* Generar entidades/prefabs en tiempo de ejecución
* Inicializar sistemas globales
* Leer datos de guardado de todo el juego

### `ao_update(dt)`

Se ejecuta en cada frame.

Usos comunes:

* Temporizadores del juego, gestores de oleadas
* Lógica de generación que depende del tiempo
* Reglas de jugabilidad

### `ao_late_update(dt)`

Se ejecuta en cada frame después de `ao_update`.

Usos comunes:

* Trabajo de toda la escena que depende de las posiciones/estado finales del frame
* Trabajo de “limpieza” después de las actualizaciones

La interfaz de usuario del jugador va en `Player.ao_late_update`, no en este callback global.

### `ao_draw(dt)`

Solo cosmético; se ejecuta en las submissions que pueden renderizar y omite la resimulación. `dt` es el delta de simulación enviado; usa `get_time()` para tiempo absoluto.

Nunca pongas aquí jugabilidad ni interfaz interactiva. Usa `ao_update`/`ao_late_update` (normalmente `Player.ao_late_update` para la UI).

## Ciclo de vida de componentes (por entidad)

Los componentes (incluido `Player`) pueden implementar:

* `ao_start()`
* `ao_update(dt)`
* `ao_late_update(dt)`
* `ao_draw(dt)` (solo cosmético; frames renderizables)
* `ao_end()`
* `ao_on_state_sync()` (se llama cuando el estado de red se sincroniza)

{% hint style="warning" %}
`ao_start()` no se reproduce para cada cliente. Cuando un cliente se une después de que un objeto ya haya comenzado en el servidor, el componente sincronizado puede llegar con su ciclo de vida de inicio ya completado. No uses `ao_start()` para la configuración de presentación local del cliente que cada cliente que se une debe ejecutar; reconstruye esa presentación a partir del estado sincronizado en `ao_on_state_sync()` en su lugar.
{% endhint %}

Ejemplo:

```go
Orbiter :: class : Component {
    ao_start :: method() {
        // init
    }

    ao_update :: method(dt: float) {
        // comportamiento por frame
    }

    ao_end :: method() {
        // limpieza (cuando se destruye)
    }
}
```

## Dónde poner el código: una regla general

* **Estado/lógica por jugador**: ponlo en `Player` (ver [Añadir lógica de jugador](/all-out-docs/docs-es/programacion/player-model.md))
* **Comportamientos reutilizables de entidades**: póngalos en componentes personalizados (ver [Entidades y componentes](/all-out-docs/docs-es/programacion/entities-and-components.md))
* **Coordinación/reglas globales**: ponlo en el ciclo de vida global (`ao_*` procs)

## Servidor vs local

Los callbacks globales y de componentes de jugabilidad se ejecutan tanto en el cliente que predice como en el servidor. No protejas la jugabilidad con `Game.is_server()`.

Dibuja toda la UI del jugador desde el `ao_late_update` pila de llamadas, envuelta en `is_local_or_server()`. Usa `is_local()` solo para anulaciones visuales específicas del jugador. El estado cambiado solo bajo `is_local()` se reemplaza por la siguiente sincronización del servidor.

Estos son métodos en `Player_Base`. Llámalos sobre una referencia de jugador, o como `is_local_or_server()` / `is_local()` dentro de un `Player` método (implícito `this`).