For the complete documentation index, see llms.txt. This page is also available as Markdown.

Ciclo de vida del juego/fotograma

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

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)

Si buscas la «plantilla» main.csl, consulta Primeros pasos con CSL.

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)

Ejemplo:

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

  • Estado/lógica por jugador: ponlo en Player (ver Añadir lógica de jugador)

  • Comportamientos reutilizables de entidades: ponlos en componentes personalizados (consulta Entidades y componentes)

  • 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).

Última actualización