> 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/coming-from-other-tools/unity.md).

# Unity

***

If you're coming from Unity, you'll feel at home with **entities + components**, a **hierarchy**, an **inspector**, and reusable **prefabs**. The biggest mindset shift is that All Out games are **multiplayer-first**: gameplay state is synced for you, and you write most logic as if it were server-authoritative by default.

## TL;DR: What’s different vs Unity

* **Multiplayer is the default**: gameplay state is automatically replicated from server to clients. You generally **do not** write RPCs, SyncVars, or Netcode spawning logic.
* **Be intentional about where code runs**:
  * Use gameplay inputs/UI that affect state on **server + local client** (see `is_local_or_server()` patterns in the CSL authoring guidelines).
  * Use purely cosmetic logic **local-only**.
* **Avoid global singleton state**: multiple players connect to the same session. Prefer storing state on the player or on world components.
* **Mobile-first**: avoid keyboard-only assumptions unless your game explicitly targets PC.

## Concept mapping (Unity → All Out)

| Unity                     | All Out                                         |
| ------------------------- | ----------------------------------------------- |
| Scene                     | Scene (world)                                   |
| GameObject                | Entity                                          |
| Transform                 | Entity transform (position/rotation/scale)      |
| Component / MonoBehaviour | Component (CSL class deriving from `Component`) |
| Prefab                    | Prefab asset (created in-editor)                |
| Hierarchy window          | [Hierarchy](/using-the-editor/hierarchy.md)     |
| Inspector window          | [Inspector](/using-the-editor/inspector.md)     |
| `Instantiate(prefab)`     | `instantiate(prefab_asset)`                     |
| `Start()` / `Update()`    | `ao_start` / `ao_update(dt)` lifecycle          |

## Project layout: where “scripts” and “assets” live

* **Scripts**: Your game code lives in `.csl` files. New projects start with a `main.csl` that imports the engine and defines lifecycle entry points. See [Getting Started with CSL](/scripting/syntax.md).
* **Assets**: Game assets live under your project’s `/res` directory and are referenced by path **without** the `/res` prefix (example: `"ui/button.png"`). See [Assets and Resources](/core-engine-concepts/assets-and-resources.md).

### Imports (important difference)

In Unity, each C# script is compiled and can use its own `using` directives. In All Out, keep imports centralized:

* Import `"core:ao"` in `main.csl`
* If you add a folder (like `ui/`), import the folder **once** in `main.csl`
* Avoid adding imports in other files

Example:

```go
// main.csl
import "core:ao"
import "ui" // optional: brings all files under /scripts/ui into scope
```

## Lifecycle: MonoBehaviour → CSL

In Unity you typically attach a `MonoBehaviour` to a GameObject and implement:

* `Start()` / `Awake()`
* `Update()` / `LateUpdate()`
* `OnDestroy()`

In CSL, you’ll commonly use:

* Global procs in `main.csl` (for game-level setup)
* Component lifecycle methods on your components

Example component:

```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);
    }
}
```

For more context on the lifecycle model, see [Game/Frame Lifecycle](/scripting/game-frame-lifecycle.md).

## Prefabs: Unity Prefabs → All Out Prefabs

All Out prefabs are created in the editor and can be reused or spawned at runtime.

* **Create**: see [Prefabs](/using-the-editor/prefabs.md)
* **Spawn at runtime**:

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

{% hint style="info" %}
The prefab system is evolving. See the limitations section in the Prefabs doc.
{% endhint %}

## “Serialized fields” (Inspector-exposed variables)

Unity uses `[SerializeField]` and public fields to expose values in the Inspector. In CSL, use `@ao_serialize` to expose a field to the editor.

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

Then add your component to an entity in the [Inspector](/using-the-editor/inspector.md) and tweak values per entity.

## Spawning and querying: Instantiate/Find → Scene APIs

Unity patterns:

* `new GameObject()` / `Instantiate()`
* `FindObjectOfType<T>()`, `GetComponentsInChildren<T>()`

All Out patterns:

```go
// Create and destroy entities
e := Scene.create_entity();
e.set_local_position({0, 0});
e.destroy();

// Iterate entities (when you truly need "everything")
for e2: entity_iterator() {
}

// Iterate components of a specific type
for player: component_iterator(My_Player) {
}
```

## Collision & triggers: “no callbacks” by default

If you’re used to `OnTriggerEnter` / `OnCollisionEnter`, note that CSL does not rely on collision callbacks for gameplay scripting. A common pattern is to query for nearby components and check distances.

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

for p: nearby {
    // check distance / apply effect / etc.
}
```

## Multiplayer mindset: inputs, UI, and “where code runs”

In Unity you can often assume “my client owns my character”. In All Out, think server-authoritative:

* **Gameplay-affecting input/UI**: run where it can affect authoritative state (commonly server + local client)
* **Cosmetics**: local-only

See the CSL authoring guidelines for examples using `is_local_or_server()` vs `is_local()`.

## Common Unity-to-All-Out gotchas

* **Singleton managers**: prefer per-player or per-entity state instead of global `GameManager` style singletons.
* **Import habits**: import engine and folders from `main.csl` (don’t scatter imports across many files).
* **Assuming singleplayer**: always think “what happens with 10 players connected?”
* **Hardcoded desktop input**: avoid requiring keyboard/mouse unless intentional.

## Where to go next

* [Getting Started with CSL](/scripting/syntax.md)
* [Hierarchy](/using-the-editor/hierarchy.md)
* [Inspector](/using-the-editor/inspector.md)
* [Prefabs](/using-the-editor/prefabs.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.allout.game/coming-from-other-tools/unity.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.