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.

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

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

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)

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.

Iterating entities/components

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():

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

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.

Assets, prefabs, and paths

The /res folder

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

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:

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:

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

See: Navmesh and collision.

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 or UIDoc Quick Start.

Match flow, inventory, interactables

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

• Interactables: Interactables
• Inventory: Inventory
• Matchmaking / hub games: Matchmaking / hub games
• Movement agents / NPCs: Movement agents / NPCs
• Spine animations (if you used Paper2D / flipbooks): Spine

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
• Read Navmesh and collision
• Skim Interactables and Inventory