cubeUnity

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


Si vienes de Unity, te sentirás como en casa con entidades + componentes, un jerarquía, un inspector, y reutilizables prefabs. El mayor cambio de mentalidad es que All Out se centra en multijugador-primero: el estado de juego se sincroniza por ti, y escribes la mayor parte de la lógica como si fuera con autoridad del servidor por defecto.

TL;DR: Qué es diferente respecto a Unity

  • El multijugador es el predeterminado: el estado de juego se replica automáticamente del servidor a los clientes. Generalmente no escribes RPCs, SyncVars, o lógica de generación de red (Netcode spawning).

  • Sé intencional sobre dónde se ejecuta el código:

    • Usa entradas/UI de juego que afectan el estado en servidor + cliente local (ver is_local_or_server() patrones en las directrices de autoría de CSL).

    • Usa lógica puramente cosmética solo local.

  • Evita el estado singleton global: múltiples jugadores se conectan a la misma sesión. Prefiere almacenar el estado en el jugador o en componentes del mundo.

  • Móvil-primero: evita suposiciones solo de teclado a menos que tu juego apunte explícitamente a PC.

Mapeo de conceptos (Unity → All Out)

Unity
All Out

Escena

Escena (mundo)

GameObject

Entidad

Transform

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

Componente / MonoBehaviour

Componente (clase CSL que deriva de Component)

Prefab

Recurso prefab (creado en el editor)

Ventana de jerarquía

Ventana del inspector

Instantiate(prefab)

instantiate(prefab_asset)

Start() / Update()

ao_start / ao_update(dt) ciclo de vida

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

  • Scripts: Tu código del juego vive en .csl archivos. Los proyectos nuevos comienzan con un main.csl que importa el motor y define puntos de entrada del ciclo de vida. Ver Introducción a CSL.

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

Importaciones (diferencia importante)

En Unity, cada script C# se compila y puede usar sus propias using directivas. En All Out, mantén las importaciones centralizadas:

  • Import "core:ao" en main.csl

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

  • Evita agregar importaciones 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, comúnmente usarás:

  • Procedimientos 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:

Para más contexto sobre el modelo de ciclo de vida, ver Ciclo de vida del juego/frame.

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: ver Prefabs

  • Generar en tiempo de ejecución:

circle-info

El sistema de prefabs está en evolución. Ver la sección de limitaciones en el documento de Prefabs.

"Campos serializados" (variables expuestas en el Inspector)

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

Luego añade tu componente a una entidad en el Inspector y ajusta valores por entidad.

Generación y consultas: Instantiate/Find → APIs de Escena

Patrones de Unity:

  • new GameObject() / Instantiate()

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

Patrones de All Out:

Colisiones y triggers: “sin callbacks” por defecto

Si estás acostumbrado a OnTriggerEnter / OnCollisionEnter, ten en cuenta que CSL no depende de callbacks de colisión para el scripting de gameplay. Un patrón común es consultar componentes cercanos y comprobar distancias.

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

En Unity a menudo puedes asumir “mi cliente posee mi personaje”. En All Out, piensa en autoridad del servidor:

  • Entradas/UI que afectan al gameplay: ejecutarse donde pueda afectar el estado autoritativo (comúnmente servidor + cliente local)

  • Cosméticos: solo local

Consulta las directrices de autoría de CSL para ejemplos que usan is_local_or_server() vs is_local().

Errores comunes al pasar de Unity a All Out

  • Gestores singleton: prefiere estado por jugador o por entidad en lugar de global GameManager estilo singleton.

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

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

  • Entrada de escritorio codificada: evita requerir teclado/ratón a menos que sea intencionado.

A dónde ir después

Última actualización