Unity

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

---

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
Inspector window	Inspector
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.

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

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:

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

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

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

• Spawn at runtime:

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

The prefab system is evolving. See the limitations section in the Prefabs doc.

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

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

Then add your component to an entity in the Inspector and tweak values per entity.

Spawning and querying: Instantiate/Find → Scene APIs

Unity patterns:

• new GameObject() / Instantiate()

• FindObjectOfType<T>(), GetComponentsInChildren<T>()

All Out patterns:

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

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

// Iterate components of a specific type
foreach 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.

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

• Hierarchy

• Inspector

• Prefabs