> 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/fotograma

Los juegos de All Out funcionan con un ciclo de vida sencillo: algunas devoluciones de llamada ocurren una vez al inicio y algunas ocurren en cada fotograma.

Implementarás estas devoluciones de llamada ya sea:

* **Globalmente** (de nivel superior `ao_*` procedimientos en `main.csl`), o
* **En componentes** (métodos como `ao_update` interior de ese jugador `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)

Estos son procedimientos de nivel superior en `main.csl`:

### `ao_before_scene_load`

Se ejecuta después de que el vacío `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 fotograma.

Usos comunes:

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

### `ao_late_update(dt)`

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

Usos comunes:

* Trabajo de toda la escena que depende de las posiciones/estado finales del fotograma
* Trabajo de «limpieza» después de las actualizaciones

La interfaz del jugador pertenece en `Player.ao_late_update`, no en esta devolución de llamada global.

## Ciclo de vida de componentes (por entidad)

Los componentes (incluidos `Player`) pueden implementar:

* `ao_start()`
* `ao_update(dt)`
* `ao_late_update(dt)`
* `ao_end()`
* `ao_on_state_sync()` (se llama cuando el estado de red está sincronizado)

{% hint style="warning" %}
`ao_start()` no se repite 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 fotograma
    }

    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**: ponlos en componentes personalizados (consulta [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_*` procedimientos)

## Servidor vs local

Las devoluciones de llamada de juego globales y de componentes 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 la actualización tardía de ese jugador `ao_late_update` pila de llamadas, envuelto 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 con 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`).