Tres problemas de rendimiento medidos en el cliente. Se pueden atacar por separado, están juntos porque comparten archivo.
1. Se instancian los sprites del mapa 100x100 completo
Tras el primer render de la ventana visible (21x21 tiles), un setTimeout completa el mapa entero: capas 1 y 2 primero, después 3 y 4 más los objetos.
Un mapa de 100x100 con 2 a 4 capas son del orden de 20.000 a 40.000 sprites vivos. Hay culling (marca visible = false fuera de cámara) pero los objetos siguen existiendo en memoria.
Es el pico que hace que un teléfono de gama media se quede sin memoria.
Propuesta: dividir el render diferido en chunks con requestIdleCallback, y no instanciar las capas superiores fuera de un radio en dispositivos de gama baja.
2. No hay límite de FPS
No existe app.ticker.maxFPS en ningún lado del repo. El juego corre al refresh nativo de la pantalla.
En un monitor de 60 Hz da igual. En un celular de 120 Hz significa el doble de trabajo de GPU y de batería para un juego cuya lógica de movimiento va a pasos de 200 ms: no hay ninguna ganancia visual.
Propuesta: app.ticker.maxFPS = 60, con opción de 30 en un modo de ahorro.
3. El prefetch de mapas vecinos no tiene tope
Al terminar de cargar un mapa se precargan los vecinos. Los vecinos salen de recorrer todos los tiles buscando salidas, sin límite de cantidad. Por cada vecino se descarga el JSON del mapa (unos 85 KB), se descomprime a 10.000 tiles en memoria, y se precargan los PNG de sus capas 1 y 2.
Un mapa de ciudad con 6 a 10 salidas dispara varios MB de descarga y varios mapas de 10.000 tiles en RAM, sin que el jugador haya ido a ninguno.
Propuesta: tope de vecinos concurrentes (2 es razonable), y saltear el prefetch si navigator.connection.saveData está activo o el tipo de conexión es lento.
Bonus, barato
El texto del HUD dibujado con Pixi (FPS, ping, seguro) usa resolution = 1 mientras el renderer usa hasta 2. En pantallas de alta densidad se ve borroso. Igualar la resolución del texto a la del renderer es una línea.
Criterios de aceptación
Archivos relevantes
frontend/components/game/core/useRendererBootstrap.ts (init de Pixi, render diferido del mapa completo)frontend/components/game/core/useAssetPipeline.ts (prefetch de vecinos)frontend/components/game/rendering/sceneRenderer.ts (renderMap)
Tres problemas de rendimiento medidos en el cliente. Se pueden atacar por separado, están juntos porque comparten archivo.
1. Se instancian los sprites del mapa 100x100 completo
Tras el primer render de la ventana visible (21x21 tiles), un
setTimeoutcompleta el mapa entero: capas 1 y 2 primero, después 3 y 4 más los objetos.Un mapa de 100x100 con 2 a 4 capas son del orden de 20.000 a 40.000 sprites vivos. Hay culling (marca
visible = falsefuera de cámara) pero los objetos siguen existiendo en memoria.Es el pico que hace que un teléfono de gama media se quede sin memoria.
Propuesta: dividir el render diferido en chunks con
requestIdleCallback, y no instanciar las capas superiores fuera de un radio en dispositivos de gama baja.2. No hay límite de FPS
No existe
app.ticker.maxFPSen ningún lado del repo. El juego corre al refresh nativo de la pantalla.En un monitor de 60 Hz da igual. En un celular de 120 Hz significa el doble de trabajo de GPU y de batería para un juego cuya lógica de movimiento va a pasos de 200 ms: no hay ninguna ganancia visual.
Propuesta:
app.ticker.maxFPS = 60, con opción de 30 en un modo de ahorro.3. El prefetch de mapas vecinos no tiene tope
Al terminar de cargar un mapa se precargan los vecinos. Los vecinos salen de recorrer todos los tiles buscando salidas, sin límite de cantidad. Por cada vecino se descarga el JSON del mapa (unos 85 KB), se descomprime a 10.000 tiles en memoria, y se precargan los PNG de sus capas 1 y 2.
Un mapa de ciudad con 6 a 10 salidas dispara varios MB de descarga y varios mapas de 10.000 tiles en RAM, sin que el jugador haya ido a ninguno.
Propuesta: tope de vecinos concurrentes (2 es razonable), y saltear el prefetch si
navigator.connection.saveDataestá activo o el tipo de conexión es lento.Bonus, barato
El texto del HUD dibujado con Pixi (FPS, ping, seguro) usa
resolution = 1mientras el renderer usa hasta 2. En pantallas de alta densidad se ve borroso. Igualar la resolución del texto a la del renderer es una línea.Criterios de aceptación
saveDataactivo no hay prefetchArchivos relevantes
frontend/components/game/core/useRendererBootstrap.ts(init de Pixi, render diferido del mapa completo)frontend/components/game/core/useAssetPipeline.ts(prefetch de vecinos)frontend/components/game/rendering/sceneRenderer.ts(renderMap)