Hice un MVP de FLIP! en tres días. Después pasé otros tres intentando que las salas se vieran por WebSockets.
Pensé que lo difícil sería hacer funcionar una partida uno a uno. No. El reto estaba en el matchmaking: conseguir que los dos jugadores llegaran a la misma sala y vieran la misma partida.
Una sala, dos pantallas
En una prueba, un jugador aparecía listo y el otro seguía esperando. Los dos tenían el mismo código de sala, pero estaban leyendo instancias distintas. Cada una conocía solo una parte de lo que estaba pasando.
Ahí entendí que abrir dos conexiones no resolvía el problema. Las dos pantallas tenían que hablar con la misma partida y reconocer el mismo estado.
Qué hace el Actor
Para organizarlo usamos Durable Objects Actors. Pienso en el Actor como el encargado de una sala: conserva su estado y coordina los cambios que llegan de los jugadores.
HTTP sirve para solicitudes concretas. WebSockets mantiene una comunicación abierta para los eventos de la partida. Son caminos distintos, pero ambos necesitan llegar a una fuente coherente de estado.
En FLIP!, Intellekt | Network Actors Framework es el marco que usamos para conectar salas de juego por HTTP y WebSockets. La idea es que los clientes puedan hablar con la sala y recibir lo que está ocurriendo ahí.
Cuando una respuesta no llega
También tuvimos que pensar qué pasa si una jugada llega a la sala, pero quien la envió no recibe la confirmación. Una pantalla puede avanzar y la otra quedarse atrás.
En esos casos, la recuperación consulta el estado más reciente de la sala para volver a sincronizar las pantallas. La acción no debe duplicarse ni perderse en el intento.
Probamos también dos pestañas intentando crear una sala al mismo tiempo. Si las dos solicitudes venían del mismo anfitrión, tenían que recuperar una sola sala, no crear dos partidas que parecieran la misma.
En QA revisamos reconexión, creación concurrente y estados compartidos. Algunas pruebas mostraron avances; otras todavía encontraron diferencias entre sesiones o problemas al reabrir una sala después de revertir. No dábamos por terminada la prueba solo porque el socket abriera: los dos jugadores tenían que ver el mismo estado.
Después verificamos un flujo multiplayer con dos cuentas, reconexión y guardado de resultado. Ese hito fue distinto de las exploraciones de QA que seguían afinando la sincronización.
El reto no era solo jugar
El networking fue la parte que más tiempo me tomó. No porque una partida uno a uno fuera imposible, sino porque encontrar una sala, mantener su estado y hacer que ambos peers vieran lo mismo terminó siendo un problema más grande de lo que esperaba.
Los WebSockets ayudan a hablar en tiempo real. Pero no deciden por sí solos qué pantalla dice la verdad. Para eso está la arquitectura que coordina la sala.
FLIP! está aquí: flipgame.strevel.net. Puedes probar el juego y entrar a su mesa.
Esta serie empezó con un prototipo en Delphi, pasó por una interfaz construida alrededor de cartas dibujadas y termina con dos jugadores intentando compartir la misma partida. Quería volver a darle una oportunidad a mi primer juego. No pensé que el matchmaking me fuera a enseñar tanto sobre la palabra “misma”.