Saltar a contenido

Elegir un game loop

El game loop técnico gobierna la captura de entradas, el avance de la simulación y el render. Conviene distinguirlo del gameplay loop, que describe el ciclo de decisiones y recompensas que juega una persona.

Un error frecuente es permitir que la tasa de frames determine por accidente los resultados de la simulación. Un monitor rápido podría entonces cambiar el resultado de las colisiones, del daño o del movimiento.

Tres responsabilidades

flowchart TB
  T["Medir tiempo real"] --> I["Capturar input"]
  I --> Q["Encolar intenciones"]
  Q --> S["Actualizar 0..N ticks"]
  S --> P["Interpolar representación"]
  P --> R["Renderizar frame"]
  R --> T

El render puede ser variable y la simulación fija. Un paso fijo es especialmente relevante para físicas, replay, networking o reglas sensibles al tiempo; no es obligatorio para una interfaz sencilla.

Comparación de estrategias

Estrategia Cuándo conviene Compromiso
Delta variable Juegos pequeños y simulación tolerante Los picos alteran la integración
Tick fijo Física, sincronización, simular sin render Hay que gestionar ticks atrasados
Híbrida Render fluido con simulación estable Mantener estados para interpolación

Un bucle de tiempo fijo

accumulator += min(realDelta, maximumFrameDelta)
readInputIntoCommands()

steps = 0
while accumulator >= fixedDelta and steps < maxSteps:
    simulation.tick(fixedDelta)
    accumulator -= fixedDelta
    steps += 1

alpha = accumulator / fixedDelta
presentation.render(interpolate(previous, current, alpha))

La cantidad máxima de pasos evita una espiral de retraso. Pero descartar tiempo, conservarlo o ralentizar la simulación son decisiones diferentes. Documentá esa política; para juegos de red o replays deterministas puede cambiar la corrección del sistema.

Orden, frecuencia y escalabilidad

El scheduler debe definir qué sistema produce datos y cuál los lee. Un ejemplo es: validar intenciones → movimiento/físicas → aplicar efectos → actualizar decisiones → publicar estado observable. El orden exacto depende del juego.

No todo debe ejecutarse en cada tick. Podés actualizar planificación estratégica, comercio y NPC distantes a menores frecuencias. Si hay concurrencia, declarás qué datos lee/escribe cada sistema antes de paralelizarlo.

Verificar

Medí tiempo por tick, p95, pasos por frame y deuda acumulada. Ejecutá una simulación headless durante una cantidad conocida de ticks. Si necesitás determinismo, controlá seeds, orden de iteración, puntos de lectura y fuentes externas: usar un delta fijo no es suficiente por sí solo.

Relacionado: Núcleo de simulación y scheduler, Intenciones, acciones y eventos, Probar la simulación y medir antes de optimizar y Tres topologías: local, host-and-play y servidor dedicado.

Referencia: Glenn Fiedler — Fix Your Timestep!.

Mencionado desde