Fundamentos de redes

All Out es principalmente multijugador, 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 del servidor a los clientes. No necesitas escribir RPCs ni cosas de “aparición en red”.

Autoridad (¿quién decide qué?)

Como regla general:

• Servidor: decide el estado de la jugabilidad (daño, recompensas, apariciones, victoria/derrota, colisiones mediante consultas, etc.)

• Cliente: renderiza y reproduce elementos cosméticos (interfaz, 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 proteges qué trabajo se ejecuta dónde.

Comprobaciones locales frente a servidor

Dos comprobaciones que usarás constantemente:

• is_local_or_server(): para la interfaz de jugabilidad y el manejo de entradas (se ejecuta en el servidor + el 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) {
        // Usa para la interfaz de jugabilidad y las entradas (se ejecuta en el servidor + el cliente local)
        if is_local_or_server() {
            // draw_ability_button(this, Shoot_Ability, 0);
            // Manejar entradas que afectan al estado del juego
            // El movimiento se maneja automáticamente
        }

        // Usa 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, interfaz cosmética, etc.
        }
    }
}

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

Estado específico del cliente

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

• alternar abrir/cerrar la interfaz

• temporizadores de sacudida de cámara

• “último elemento sobre el que se pasó el cursor” en una interfaz de inventario

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

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

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

        // Alternar interfaz (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 del servidor. El cliente debe reaccionar al estado del servidor, no inventarlo.

Depuración de problemas de red

• Añade un componente derivado de log_info(...) en las rutas del servidor (no solo local) para que puedas ver las decisiones autorizadas.

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

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

  • una variable global sobrescrita por varios jugadores.

Documentación relacionada

• Añadir lógica de jugador

• Ciclo de vida del juego/fotograma