El problema de los juegos con turnos donde el turno puede ser corto (en cuatro en raya normalmente la gente mueve en tres o cuatro segundos, en las damas hay más estrategia y puede llevar más tiempo pero también hay movimientos inmediatos como en las capturas obligadas) es que están a medio caballo entre un juego a tiempo real y uno por turnos tipo apalabrados.
Y no tiene que ver nada cómo se afronta uno u otro.
Si fueran turnos largos podrías notificar exclusivamente por GCM de nuevos movimientos, y te daría igual si el usuario está en la app o no. Es lo que hace apalabrados y es un modelo donde tienes tropecientas partidas a la vez, la mayoría detenidas a que el adversario mueva. Si no le llegan las notificaciones tampoco pasa nada, como el usuario entra a la app cuando le apetece jugar ya se refrescan las partidas de forma automática o manual al entrar.
Para turnos (muy) cortos GCM no vale porque la notificación igual tarda en llegar más de lo deseado.
- Ventaja: no hace falta que los dos usuarios estén conectados a la vez, pero el usuario tiene que saber que rara vez va a jugar una partida del tirón y no sé si en un juego de tanta concentración y estrategia tiene sentido continuarla más tarde porque toda la estrategia se te ha olvidado ya.
- Desventaja: más estrés en la base de datos que tiene que guardar el estado de todas las partidas el tiempo que duren. Y en ese caso más que una base de datos al uso convendría un sistema de colas de mensajes con persistencia (rabbitmq y similares), que de paso es más escalable.
Si lo planteas como juego en tiempo real es más fácil: un servidor que gestiona el estado de las partidas en curso y conexión permanente con socket o websocket mientras dure la partida y a correr.
- Problema, tienen que estar conectados a la vez los dos usuarios, eso solo puedes hacerlo si tienes muchos usuarios durante el día o nadie encontrará rival para jugar. Asegúrate de tener un servidor con eventos asíncronos como node.js, netty o vert.x para que los usuarios que están esperando al rival no consuman recursos en forma de hilos de ejecución.
- Ventaja, la base de datos está tranquila porque la partida normalmente dura unos minutos y guardas el estado en memoria. No te hace falta persistencia del estado de todas las partidas porque si el servidor se cae solo afecta a la partida en curso del usuario y una vez interrumpida tampoco tiene sentido recuperarla porque probablemente ni los dos usuarios vuelvan a coincidir conectados.
Luego está la solución híbrida, si los usuarios están conectados al mismo tiempo trata la partida como si fuera tiempo real y si no lo están como si fuera por turnos largos. Tiene las ventajas de ambos acercamientos y también las desventajas de ambos. No he visto ningún juego ni ningún backend SAAS que ofrezca este acercamiento, probablemente porque no tiene sentido o porque la complejidad no compensa
Aun así... algún día me animaré a implementar una prueba de concepto, quizá no para el cuatro en raya pero sí para otros juegos que tengo en la nevera.