For the complete documentation index, see llms.txt. This page is also available as Markdown.

Adding Player Logic

In All Out, the player is a first-class gameplay object. Your Player :: class : Player_Base is where you put per-player state (health, loadouts, cooldowns, UI toggles, progression, etc).

Per-player state

Store gameplay state on the player or objects owned by the player.

Player :: class : Player_Base {
    health: int;
    inventory_open: bool;
}

Server + client: what runs where?

All Out automatically syncs gameplay state from the server to clients. Gameplay methods run on both the predicting client and the server, so do not guard them with Game.is_server().

Two common checks:

  • is_local_or_server(): all player UI and the input it produces

  • is_local(): player-specific visual overrides only

Player :: class : Player_Base {
    ao_late_update :: method(dt: float) {
        if is_local_or_server() {
            // Draw all player UI and handle its input here.
        }

        if is_local() {
            // Apply player-specific visibility here, but do not change fields.
        }
    }
}

Draw all player UI from Player.ao_late_update under is_local_or_server(). Fields changed only inside is_local() are replaced during reconciliation.

Player identity and profile data

Player_Base exposes identity fields you’ll use often:

  • p.get_username() -> string

  • p.get_user_id() -> string

  • p.avatar_color

  • p.device_kind (.PHONE, .TABLET, .PC)

  • p.is_admin(), p.is_vip(), p.is_moderator(), p.is_youtuber()

  • p.is_chat_open() and UI rect helpers such as p.get_chat_rect()

Persistence: where to store player progress

  • Economy: currencies (coins/gems/xp) with automatic persistence + creator portal editing See Economy.

  • Save: general key/value persistence (settings, quest state, unlock lists, etc) See Save System.

  • Inventory: item stacks/instances in a player inventory (optionally auto-saved) See Inventory.

Common pattern: load saved values in ao_start

Best practices

  • Keep per-player state on Player. Avoid globals for anything player-specific.

  • Run gameplay in the shared predicted path. Draw player UI under is_local_or_server() and reserve is_local() for player-specific visual overrides.

  • Prefer the built-in persistence APIs instead of rolling your own (Economy/Save/Inventory).

Player_Base reference

See api_references/core/ao/core.csl_engine in the project folder for the complete Player_Base API.

Last updated