> 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/unreal.md).

# Unreal

If you've built games with Unreal, there are some key differences you'll need to know to get started on All Out!

***

This guide is for Unreal Engine developers (Blueprints / C++) transitioning to **All Out** and **CSL** (All Out’s custom scripting language).

## The big shift (mental model)

In Unreal you often think in terms of:

* **Actors in a World** (spawned, replicated, owned)
* **Components** attached to Actors
* **Blueprint graphs / C++** driving gameplay
* **RPC + Replication** you author explicitly

In All Out you’ll usually think in terms of:

* **Entities in a Scene** (with Components)
* **Components** (engine-provided + your own CSL components)
* **Abilities** for player actions (mobile-first UI + cooldown + aiming)
* **Shared predicted gameplay** where state sync is automatic (no custom RPC plumbing for most gameplay)
* **2D transforms** using `v2` position and scale plus one rotation angle

## Quick mapping: Unreal → All Out / CSL

| Unreal                                    | All Out / CSL                                               | Notes                                                                             |
| ----------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------- |
| `UWorld` / Level                          | `Scene`                                                     | Entities exist in the scene; you can also create/destroy them at runtime.         |
| `AActor`                                  | **Entity**                                                  | Entities have 2D transforms and components.                                       |
| Actor location                            | `Entity.local_position` / `world_position`                  | Decide how Unreal X/Y/Z maps into the game's 2D X/Y plane.                        |
| Actor rotation                            | `Entity.local_rotation`                                     | All Out uses one rotation angle in degrees.                                       |
| Actor scale                               | `Entity.local_scale`                                        | All Out uses `v2`; there is no gameplay Z scale.                                  |
| `UActorComponent`                         | `Component`                                                 | You author gameplay by writing CSL components and attaching them to entities.     |
| `BeginPlay`                               | `ao_start`                                                  | Component lifecycle entry point.                                                  |
| `Tick(float DeltaTime)`                   | `ao_update(dt)` / `ao_late_update(dt)`                      | Use late update for UI/input patterns used by the engine (e.g., ability buttons). |
| Blueprint graphs                          | CSL code                                                    | Text-based, compiled as part of your project.                                     |
| Pawn/Character                            | `Player_Base` subclasses                                    | Your player logic usually lives on a `Player` component/class.                    |
| Input mappings                            | Abilities + keybinds                                        | Mobile-first: prefer ability buttons over raw input.                              |
| Replication (`Replicated` vars)           | Automatic state sync                                        | Write one predicted gameplay path instead of separate client/server versions.     |
| RPCs (`Server`, `Client`, `NetMulticast`) | Usually not needed                                          | Use engine facilities (e.g., notifications) instead of custom RPC sprawl.         |
| Actor spawning                            | `Scene.create_entity()` / `Scene.instantiate(Prefab_Asset)` | Prefabs are assets and can be instantiated.                                       |
| `UAsset` references                       | `get_asset(...)`                                            | Assets live under `/res` and are referenced by path.                              |

## Your first CSL file (imports)

CSL uses a single “root” import pattern: import in `main.csl`, and don’t sprinkle imports across every file.

```go
// main.csl
import "core:ao"
import "ui"   // if you create a /ui folder and want it in scope
```

## Entities & components (vs Actors & Components)

### Creating an entity at runtime

```go
entity := Scene.create_entity();
entity.set_local_position({10, 20});
entity.set_local_scale({2.0, 2.0});
entity.set_local_rotation(0);
```

### Adding and accessing components

```go
my := entity.add_component(My_Component);
sprite := entity.get_component(Sprite_Renderer);

// Destroy entity (and its components)
entity.destroy();
```

### Writing a custom component (life cycle)

```go
Spinner :: class : Component {
    speed: float;

    ao_start :: method() {
        speed = 1.0;
    }

    ao_update :: method(dt: float) {
        entity.set_local_rotation(entity.local_rotation + speed * dt);
    }
}
```

Global lifecycle procs run in each participating scene simulation; they are not server-only. Late-joining clients may receive a component whose start lifecycle already ran, so rebuild presentation from synchronized state in `ao_on_state_sync` when needed. See [Game/Frame Lifecycle](/scripting/game-frame-lifecycle.md).

### Iterating entities/components

```go
for e: entity_iterator() {
    // ...
}

for p: component_iterator(Player) {
    // ...
}
```

## Player actions: use Abilities (instead of raw input)

Unreal projects often start with input bindings (Enhanced Input) and then build UI/UX on top. In All Out, **Abilities** are the default way to implement player actions with:

* A consistent **mobile-friendly** button UI
* Cooldowns
* Optional aiming (drag-to-aim on mobile, mouse aim on PC)

Draw ability buttons from `Player.ao_late_update` inside `is_local_or_server()`:

```go
Player :: class : Player_Base {
    ao_late_update :: method(dt: float) {
        if this.is_local_or_server() {
            draw_ability_button(this, Shoot_Ability, 0);
            draw_ability_button(this, Dodge_Roll, 1);
        }
    }
}
```

See: [Abilities](/core-engine-concepts/abilities.md) for the full API and patterns.

## Networking: “replication” is not your job (most of the time)

### What’s different from Unreal replication

* Normal gameplay runs on the predicting client and authoritative server.
* You generally **do not write RPCs** for standard gameplay flows.
* You must still design with **multiple players** in mind: avoid global state; store per-player state on the player instance.
* Do not guard normal gameplay with `Game.is_server()` or you'll disable prediction.

### Player UI vs local visual overrides

Use these patterns:

* `is_local_or_server()` for a player's **inputs + gameplay UI**
* `is_local()` only for **player-specific visual overrides**

```go
Player :: class : Player_Base {
    ao_late_update :: method(dt: float) {
        if this.is_local_or_server() {
            // inputs + gameplay UI
        }
        if this.is_local() {
            // visual overrides only this player should see
        }
    }
}
```

See [Networking Fundamentals](/scripting/networking-fundamentals.md).

## Assets, prefabs, and paths

### The `/res` folder

Assets are in `/res`. When referencing assets, **omit `/res`** from the path.

```go
button := get_asset(Texture_Asset, "ui/button.png");
click := get_asset(SFX_Asset, "sfx/click.wav");
font := get_asset(Font_Asset, "$AO/fonts/Barlow-Black.ttf"); // engine assets
```

### Prefabs

Prefabs are assets and can be instantiated through `Scene`:

```go
prefab := get_asset(Prefab_Asset, "Enemies/Slime.prefab");
enemy_entity := Scene.instantiate(prefab);
```

## Collision & overlap events (common Unreal pitfall)

An enabled collider with `is_trigger` set can call `on_trigger_start`, `on_trigger_stay`, and `on_trigger_end`. Each callback receives the trigger collider and other collider. A `Movement_Agent` is not required.

CSL does not expose a general solid-hit callback equivalent to `OnHit`. Use a trigger for gameplay overlap behavior. For broad sensing, query nearby components:

```go
nearby: [..]Pickup;
Scene.get_all_components_in_range(player_pos, 2.0, ref nearby);
for p: nearby {
    // ...
}
```

See: [Navmesh and collision](/core-engine-concepts/navmesh-and-collision.md).

## UI differences (UMG vs CSL UI)

All Out games are **mobile-first**, so avoid building keyboard-only UX. Use the engine’s UI utilities and ability buttons.

For custom UI, start with [UI Fundamentals](/ui/fundamentals.md) or [UIDoc Quick Start](/ui/uidoc-quick-start.md).

## Match flow, inventory, interactables

If you’re looking for equivalents to common Unreal gameplay systems:

* **Interactables**: [Interactables](/core-engine-concepts/interactables.md)
* **Inventory**: [Inventory](/core-engine-concepts/inventory.md)
* **Matchmaking / hub games**: [Matchmaking / hub games](/core-engine-concepts/matchmaking-hub-games.md)
* **Movement agents / NPCs**: [Movement agents / NPCs](/core-engine-concepts/movement-agents-npcs.md)
* **Spine animations** (if you used Paper2D / flipbooks): [Spine](/core-engine-concepts/spine.md)

## Unreal-to-CSL “gotchas”

* **Don’t build a custom RPC/replication layer**: start with the shared predicted gameplay path and let the engine sync state.
* **Don't guard gameplay with `Game.is_server()`**: normal gameplay must also run on the predicting client.
* **Avoid global singletons for gameplay state**: multiple players connect; store state on the player or the relevant component instance.
* **Imports are centralized**: import folders once from `main.csl`, not per-file.
* **Prefer Abilities for actions**: it solves mobile UX + cooldowns + aiming consistently.
* **Map 3D designs into 2D**: use renderer layers instead of a Z transform.

## Next steps

* Read [Abilities](/core-engine-concepts/abilities.md)
* Read [Navmesh and collision](/core-engine-concepts/navmesh-and-collision.md)
* Skim [Interactables](/core-engine-concepts/interactables.md) and [Inventory](/core-engine-concepts/inventory.md)