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

Unity

Si has creado juegos con Unity, hay algunas diferencias clave que necesitarás conocer para empezar en All Out.


Si vienes de Unity, te sentirás como en casa con entidades + componentes, una jerarquía, un inspector, y prefabs reutilizables. El mayor cambio de mentalidad es que los juegos de All Out son centrados en multijugador: el juego normal se ejecuta en el cliente con predicción y en el servidor con autoridad, mientras que el motor sincroniza por ti el estado compatible.

TL;DR: Qué cambia frente a Unity

  • El multijugador es el valor predeterminado: por lo general no escribes RPCs, SyncVars ni lógica de aparición de Netcode.

  • Escribe una sola ruta de jugabilidad: no protejas el juego normal con Game.is_server() o desactivarás la predicción.

  • Sé intencional con la UI del jugador:

    • Dibuja la UI de juego de un jugador desde el ao_late_update interior de ese jugador is_local_or_server().

    • Usa is_local() solo para invalidaciones visuales específicas del jugador.

  • Evita el estado global de singletons: varios jugadores se conectan a la misma sesión. Preferiblemente, almacena el estado en el jugador o en componentes del mundo.

  • El juego de All Out es en 2D: la posición y la escala usan v2, mientras que la rotación es un solo ángulo en grados.

  • Prioridad móvil: evita suposiciones de solo teclado a menos que tu juego se dirija explícitamente a PC.

Mapeo de conceptos (Unity → All Out)

Unity
All Out

Escena

Escena (mundo)

GameObject

Entidad

Transform

Transformación de entidad 2D (posición/rotación/escala)

Componente / MonoBehaviour

Componente (clase CSL que deriva de Component)

Prefab

Activo prefab (creado en el editor)

Ventana de jerarquía

Ventana del inspector

Instantiate(prefab)

Scene.instantiate(prefab_asset)

Start() / Update()

ao_start / ao_update(dt) ciclo de vida

Estructura del proyecto: dónde viven los “scripts” y los “assets”

  • Scripts: El código de tu juego vive en .csl archivos. Los proyectos nuevos comienzan con un main.csl que importa el motor y define los puntos de entrada del ciclo de vida. Consulta Primeros pasos con CSL.

  • Recursos: Los assets del juego viven dentro del /res de tu proyecto y se referencian por ruta sin el prefijo /res (ejemplo: "ui/button.png"). Consulta Assets and Resources.

Imports (diferencia importante)

En Unity, cada script C# se compila y puede usar sus propias directivas using . En All Out, mantén los imports centralizados:

  • Importa "core:ao" en main.csl

  • Si agregas una carpeta (como ui/), importa la carpeta una vez en main.csl

  • Evita agregar imports en otros archivos

Ejemplo:

Ciclo de vida: MonoBehaviour → CSL

En Unity, normalmente adjuntas un MonoBehaviour a un GameObject e implementas:

  • Start() / Awake()

  • Update() / LateUpdate()

  • OnDestroy()

En CSL, normalmente usarás:

  • Procs globales en main.csl (para la configuración a nivel de juego)

  • Métodos de ciclo de vida de componentes en tus componentes

Ejemplo de componente:

Los procs globales del ciclo de vida se ejecutan en cada simulación de escena participante; no son solo para el servidor. Los clientes que se unan tarde pueden recibir un componente cuyo ciclo de vida de inicio ya se ejecutó, así que reconstruye la presentación a partir del estado sincronizado en ao_on_state_sync cuando sea necesario. Consulta Ciclo de vida del juego/fotograma.

Prefabs: Prefabs de Unity → Prefabs de All Out

Los prefabs de All Out se crean en el editor y pueden reutilizarse o generarse en tiempo de ejecución.

  • Crear: consulta Prefabs

  • Generar en tiempo de ejecución:

Las instancias vinculadas conservan las propiedades raíz, pero los cambios en los campos del componente dentro de una instancia no son reemplazos independientes. Consulta Prefabs.

“Campos serializados” (variables expuestas en el Inspector)

Unity usa [SerializeField] y campos públicos para mostrar valores en el Inspector. En CSL, usa @ao_serialize para exponer un campo al editor.

Luego agrega tu componente a una entidad en el Inspector y ajusta los valores por entidad.

Generación y consulta: Instantiate/Find → APIs de Scene

Patrones de Unity:

  • new GameObject() / Instantiate()

  • FindObjectOfType<T>(), GetComponentsInChildren<T>()

Patrones de All Out:

Colisiones y disparadores

Un collider habilitado con is_trigger establecido puede llamar a on_trigger_start, on_trigger_stay, y on_trigger_end. Cada callback recibe el collider del disparador y el otro collider. Un Movement_Agent no es necesario.

CSL no expone un callback general de contacto sólido equivalente a OnCollisionEnter. Usa un disparador para comportamiento de entrada/salida. Para detección amplia, consulta componentes cercanos:

Ver Navmesh y colisión.

Mentalidad multijugador: entradas, UI y “dónde se ejecuta el código”

En Unity, a menudo puedes asumir “mi cliente controla mi personaje”. En All Out, escribe el juego una sola vez para la ruta compartida con predicción:

  • Entrada/UI de juego: dibújala desde el jugador en ao_late_update interior de ese jugador is_local_or_server().

  • Anulaciones visuales específicas por jugador: usa is_local().

Ver Fundamentos de redes.

Errores comunes al pasar de Unity a All Out

  • Administradores singleton: prefiere estado por jugador o por entidad en lugar de un GameManager tipo singleton.

  • Hábitos de importación: importa el motor y las carpetas desde main.csl (no disperses imports entre muchos archivos).

  • Protecciones del servidor: no envuelvas el juego normal en Game.is_server().

  • Transformaciones 3D: decide cómo se mapea el diseño en una escena 2D y usa capas del renderizador para el orden de dibujo.

  • Asumir un solo jugador: piensa siempre “¿qué pasa con 10 jugadores conectados?”

  • Entrada de escritorio codificada: evita requerir teclado/ratón salvo que sea intencional.

Adónde ir después

Última actualización