> 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

***

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)
* **Server-authoritative gameplay** where **state sync is automatic** (no custom RPC plumbing for most gameplay)

## 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 transforms and components.                                          |
| `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                                  | Avoid building your own replication/RPC patterns unless you truly need them.      |
| RPCs (`Server`, `Client`, `NetMulticast`) | Usually not needed                                    | Use engine facilities (e.g., notifications) instead of custom RPC sprawl.         |
| Actor spawning                            | `Scene.create_entity()` / `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);
    }
}
```

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

* **Gameplay state is automatically synced** from server → clients.
* 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.

### Client-only vs server/shared logic

Use these patterns:

* `is_local_or_server()` for **inputs + gameplay UI** (runs on server + local client)
* `is_local()` for **purely cosmetic UI/effects** (runs only on the local client)

```go
Player :: class : Player_Base {
    ao_late_update :: method(dt: float) {
        if is_local_or_server() {
            // inputs + gameplay UI
        }
        if is_local() {
            // cosmetic-only UI/effects
        }
    }
}
```

## 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 (folders ending in `.prefab`) and can be instantiated:

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

## Collision & overlap events (common Unreal pitfall)

If you’re used to Unreal’s overlap/hit callbacks (`OnComponentBeginOverlap`, `OnHit`), note that CSL gameplay often uses **queries** rather than event callbacks.

Common pattern: query nearby components and check distance:

```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.

If you need custom UI, reference the UI documentation and follow the standard patterns (don’t invent a UMG-like widget tree unless the docs say so).

## 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 from server-authoritative logic and let the engine sync state.
* **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.
* **Cosmetics vs gameplay**: keep cosmetic-only effects local; keep gameplay state server-authoritative.

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


---

# 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/unreal.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.