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.
Estos son procedimientos de nivel superior en main.csl:
ao_before_scene_loadSe 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_startSe 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.
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)
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.
Ejemplo:
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)
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
Orbiter :: class : Component {
ao_start :: method() {
// init
}
ao_update :: method(dt: float) {
// comportamiento por fotograma
}
ao_end :: method() {
// limpieza (cuando se destruye)
}
}