Fundamentos de Redes

All Out es multijugador por defecto, pero CSL está diseñado para que puedas escribir la jugabilidad casi como si fuera para un solo jugador.

La idea clave es:

Todo el estado de la jugabilidad se sincroniza automáticamente desde el servidor a los clientes. No necesitas escribir RPCs ni “spawnear” cosas en la red.

Autoridad (¿quién decide qué?)

Como regla general:

• Servidor: decide el estado de la jugabilidad (daño, recompensas, spawns, victoria/derrota, colisiones por consulta, etc.)

• Cliente: renderiza y reproduce elementos cosméticos (UI, partículas, sacudida de pantalla, sonido)

En la práctica, la mayor parte de tu código se ejecutará tanto en el servidor como en los clientes: solo debes proteger qué trabajo se ejecuta en dónde.

Comprobaciones local vs servidor

Dos comprobaciones que usarás constantemente:

• is_local_or_server(): para UI de jugabilidad y manejo de entrada (se ejecuta en el servidor + cliente local)

• is_local(): para efectos puramente cosméticos (se ejecuta solo en el cliente local)

Ejemplo:

Player :: class : Player_Base {
    ao_late_update :: method(dt: float) {
        // Usar para UI de jugabilidad e inputs (se ejecuta en el servidor + cliente local)
        if is_local_or_server() {
            // draw_ability_button(this, Shoot_Ability, 0);
            // Manejar entradas que afectan el estado del juego
            // El movimiento se maneja automáticamente
        }

        // Usar para efectos puramente cosméticos (se ejecuta solo en el cliente local)
        if is_local() {
            // UI.text(..., "Esperando a que el anfitrión inicie el juego...");
            // Efectos de partículas, UI cosmética, etc.
        }
    }
}

Si ejecutas trabajo solo cosmético en el servidor, estás desperdiciando CPU (y potencialmente haciéndolo varias veces). Mantén los cosméticos locales.

Estado específico del cliente

A veces necesitas estado local que no debe afectar la jugabilidad y que no necesita replicación:

• Alternadores de abrir/cerrar UI

• Temporizadores de sacudida de cámara

• “último elemento sobre el que se pasó el ratón” en una UI de inventario

Mantén estos como campos, pero solo léelos/escríbelos detrás de is_local() comprobaciones.

Player :: class : Player_Base {
    // Estado de UI solo local
    inventory_open: bool;

    ao_late_update :: method(dt: float) {
        if !is_local() return;

        // Alternar UI (ejemplo)
        // if UI.button(...) inventory_open = !inventory_open;
    }
}

Reglas de seguridad para multijugador

• Evita variables globales para el estado del jugador. Si cada jugador necesita su propio valor, guárdalo en Player.

• Ten cuidado con los “singletons”. Si realmente necesitas un gestor global, asegúrate de que no almacene accidentalmente datos por jugador.

• Prefiere estado determinista en el servidor. El cliente debe reaccionar al estado del servidor, no inventarlo.

Depuración de problemas de red

• Agregar log_info(...) en las rutas del servidor (no solo local) para que puedas ver decisiones autorizadas.

• Si algo “funciona localmente” pero no para otros jugadores, generalmente es:

  • código protegido por is_local() que debería ser autoritativo en el servidor, o

  • una variable global que está siendo sobrescrita por varios jugadores.

Documentación relacionada

• Agregar Lógica de Jugador

• Ciclo de vida del juego/cuadro