> 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/si-vienes-de-otras-herramientas/unity.md).

# Unity

***

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       | [Jerarquía](/all-out-docs/docs-es/uso-del-editor/hierarchy.md) |
| Ventana del inspector      | [Inspector](/all-out-docs/docs-es/uso-del-editor/inspector.md) |
| `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](/all-out-docs/docs-es/programacion/syntax.md).
* **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](/all-out-docs/docs-es/conceptos-basicos-del-motor/assets-and-resources.md).

### 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:

```go
// main.csl
import "core:ao"
import "ui" // opcional: trae todos los archivos bajo /scripts/ui al alcance
```

## 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:

```go
// orbiter.csl
Orbiter :: class : Component {
    center: v2;
    radius: float;
    speed: float;
    angle: float;

    ao_start :: method() {
        center = entity.local_position;
        radius = 2.0;
        speed = 1.0;
        angle = 0.0;
    }

    ao_update :: method(dt: float) {
        angle += speed * dt;
        offset := v2{cos(angle) * radius, sin(angle) * radius};
        entity.set_local_position(center + offset);
    }
}
```

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](/all-out-docs/docs-es/programacion/game-frame-lifecycle.md).

## 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](/all-out-docs/docs-es/uso-del-editor/prefabs.md)
* **Generar en tiempo de ejecución**:

```go
spawn_enemy :: proc() {
    prefab := get_asset(Prefab_Asset, "Enemies/BasicEnemy.prefab");
    e := Scene.instantiate(prefab, {10, 5});
}
```

{% hint style="info" %}
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](/all-out-docs/docs-es/uso-del-editor/prefabs.md).
{% endhint %}

## “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.

```go
Damage_On_Touch :: class : Component {
    damage: int = 10 @ao_serialize;
}
```

Luego agrega tu componente a una entidad en el [Inspector](/all-out-docs/docs-es/uso-del-editor/inspector.md) 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:

```go
// Crear y destruir entidades
e := Scene.create_entity();
e.set_local_position({0, 0});
e.destroy();

// Iterar entidades (cuando realmente necesitas "todo")
for e2: entity_iterator() {
}

// Iterar componentes de un tipo específico
for player: component_iterator(Player) {
}
```

## 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:

```go
nearby: [..]Pickup;
Scene.get_all_components_in_range(entity.local_position, 2.0, ref nearby);

for p: nearby {
    // comprobar distancia / aplicar efecto / etc.
}
```

Ver [Navmesh y colisión](/all-out-docs/docs-es/conceptos-basicos-del-motor/navmesh-and-collision.md).

## 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](/all-out-docs/docs-es/programacion/networking-fundamentals.md).

## 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

* [Primeros pasos con CSL](/all-out-docs/docs-es/programacion/syntax.md)
* [Jerarquía](/all-out-docs/docs-es/uso-del-editor/hierarchy.md)
* [Inspector](/all-out-docs/docs-es/uso-del-editor/inspector.md)
* [Prefabs](/all-out-docs/docs-es/uso-del-editor/prefabs.md)