¿Es viable un juego multijugador en tiempo real usando Google App Engine?

Question

Actualmente estoy desarrollando un juego multijugador en tiempo real, y he estado evaluando varias soluciones de alojamiento basadas en la nube. No estoy seguro de si App Engine se ajusta a mis necesidades y agradecería cualquier comentario.

En esencia, quiero que el sistema funcione así: el jugador A calcula la ronda n, y genera un hash fuera del estado del juego al final de esa ronda. A continuación, envía sus comandos para esa ronda y el hash, como http POST al servidor. El jugador B hace lo mismo, en paralelo.

El servidor, al manejar el POST de un reproductor, primero escribe el código hash recibido en el Memcache. Si el hash del otro jugador aún no se encuentra en el Memcache, espera y revisa periódicamente el Memcache para el hash de los otros jugadores. Tan pronto como los dos hashes están en la memcache, los compara por igualdad. Si son iguales, el servidor envía los comandos de cada jugador al respectivo otro como la respuesta http.

Una ronda como esa debería durar alrededor de medio segundo, lo que significa dos solicitudes por jugador por segundo.

Por supuesto, esta forma de hacerlo solo funcionará si hay al menos dos instancias de la aplicación ejecutándose, ya que dos solicitudes deben tratarse en paralelo. Además, la memoria caché debe ser coherente en todas las instancias, ser bastante confiable y actualizar de inmediato.

no puedo usar XMPP porque quiero que mi juego sea capaz de funcionar dentro de las redes restringidas, por lo que tiene que limitarse a HTTP en el puerto 80.

¿Hay una manera de hacer cumplir que dos instancias de la aplicación siempre están corriendo? ¿Hay fallas evidentemente obvias en mi diseño? ¿Crees que una arquitectura como esta podría funcionar en App Engine? Si no, ¿qué solución basada en la nube sugeriría?

Answer 1

Creo que esto podría funcionar. La API clave para que aprenda sobre/test probablemente sería Channel API. Eso es lo que permitiría la comunicación de ida y vuelta entre el cliente y el servidor.

El siguiente problema para preocuparse sería Memcache. En general, es confiable, pero en el sentido más estricto se supone que suponemos que los datos de memcached podrían desaparecer en cualquier momento.

Si decide que no puede arriesgarse a perder los datos de esa manera, debe conservarlo en el almacén de datos, lo que significa que tendrá que experimentar para asegurarse de poder sostener 2 movimientos por turno. Creo que esto es posible, pero no trivialmente. Si hubieras dicho 1 movimiento cada 3 segundos, diría "no hay problema". Pero las actualizaciones múltiples a una entidad por segundo comienzan a topar con el límite práctico de escrituras por segundo, especialmente si son transaccionales.

Tener varias instancias ejecutándose no será un problema - puede pagar para mantener las instancias calientes si es necesario.