Del prototipo al juego web publicado
Hay una distancia larga entre un prototipo que funciona en tu ordenador y algo que un desconocido puede abrir desde un enlace sin que nada se rompa. Esa distancia es donde mueren la mayoría de los juegos web, casi siempre por subestimarla.
Qué demuestra realmente un prototipo
Un prototipo responde a una pregunta y solo a una. En Red Barón la pregunta era si el combate de biplanos seguía siendo divertido con controles táctiles. Nada más: sin menús, sin puntuación, sin sonido.
Si la respuesta hubiera sido que no, el proyecto se habría detenido ahí con un coste mínimo. Ese es todo el valor de un prototipo, y se pierde en cuanto empiezas a añadirle cosas «ya que estamos».
Lo que hay que construir después
Los estados que nadie prototipa
Cargando, pausa, fin de partida, reinicio, error de red, pestaña en segundo plano. Un prototipo vive en el estado «jugando»; un juego publicado pasa por todos los demás y cualquiera de ellos puede dejarlo colgado.
La primera vez de alguien que no eres tú
Tú conoces los controles. Quien abre el enlace, no. Hacen falta o bien una pantalla inicial que los explique en dos líneas, o bien un diseño tan evidente que no haga falta. Lo que no funciona es un manual de seis puntos que nadie lee.
Persistencia
Guardar el progreso, la mejor puntuación y las preferencias. En cuanto hay clasificación global, esto deja de ser un detalle y pasa a ser una superficie de ataque.
Rendimiento en la máquina de otro
El prototipo corre en tu equipo de desarrollo, con la caché caliente y los recursos en disco local. La publicación cambia las tres cosas.
- Peso total: cada megabyte es un porcentaje de gente que cierra la pestaña antes de jugar.
- Primer dibujo: hasta que aparece algo en pantalla, el visitante no sabe si el enlace funcionaba.
- Estabilidad de fotogramas: es peor un juego que va a 60 y baja a 20 de golpe que uno estable a 30.
Estas tres se miden antes de publicar, en un dispositivo modesto y con la red limitada a propósito.
Publicar es también una decisión técnica
Dónde vive el juego
Un juego servido desde una infraestructura distribuida carga rápido en cualquier país. Servido desde un único servidor, la experiencia depende de la distancia geográfica de quien juega.
Qué hacer con las versiones
Los archivos con nombre versionado permiten caché permanente sin riesgo de que alguien se quede con una versión antigua a medias. Es la diferencia entre poder publicar tranquilo y temer cada despliegue.
Qué se mide después
Cuánta gente entra, cuánta empieza una partida y cuánta la termina. Con esos tres números se sabe si el problema está en la portada, en los controles o en la dificultad.
El error de escala más caro
Construir para un millón de jugadores que todavía no existen. Toda la infraestructura pensada para una audiencia hipotética es dinero gastado antes de saber si alguien quiere el juego.
Lo razonable es publicar con lo justo, medir, y crecer cuando el crecimiento sea un problema real. Es exactamente el mismo criterio que se aplica a cualquier producto digital.
Si prefieres encargarlo
Esta forma de trabajar —una pregunta, un alcance mínimo, una medición— es la misma que se aplica fuera de los juegos:
Crear un MVP tecnológico: Cómo crear un MVP tecnológico que valide una hipótesis de negocio: qué entra en el alcance mínimo, qué se deja fuera y cómo se mide si funciona.
Continuar leyendo
El apartado de rendimiento merece más detalle del que cabe aquí. Está desarrollado en este artículo:
Cómo optimizar un juego web para móviles: Peso de descarga, presupuesto de fotograma, zonas táctiles y batería: las causas reales de que un juego web vaya mal en un móvil de gama media, por orden de impacto.