¿Cómo debo arquitecto mi DB & API de servidor para un juego de mesa multijugador basado en turnos iPhone? (Pensando sobre nodejs, mongo, sofá, etc)

Question

Estoy trabajando en un juego de mesa basado en turnos para iPhone y Android con el tiempo. Estoy usando Appcelerator Titanium para desarrollarlo. Mi diseño es similar al multijugador palabras con los amigos. Los usuarios se turnan para cuando esté listo, y luego tablero de juego rival se actualiza en consecuencia.

Una de mis necesidades es tener una API de mensajería que permite a los dispositivos de los 2 jugadores para la actualización entre sí sobre el estado del tablero de juego después de un movimiento. Pensando en hacer esto con JSON y mantener un objeto JSON en el dispositivo que contiene la ubicación de todas las piezas de juego de mesa en cualquier momento dado. Este es el objeto que tendrá que actualizar en el dispositivo local y luego enviar un cambio de dispositivo rival después de que se hizo un movimiento.

He hecho API en el pasado para plataformas móviles y para ello he utilizado PHP con MySQL y envié JSON de ida y vuelta entre el servidor de la API y el dispositivo móvil. Obras dandy de bajas usuarios simultáneos y aplicaciones generalmente no masivos. Aquí está la esperanza de éste recibirá masiva;)

Así que ahora, en lugar de un servidor httpd general y similares, estoy empezando a pensar en los zócalos persistentes y si se necesitan o no para mi nuevo juego. También estoy pensando que podría ser inteligente para renunciar a la gran pila LAMP y para la escalabilidad y tal vez la facilidad de desarrollo, a inclinarse más hacia un flujo de datos de algo así como Mongo / sofá -> Node.js -> iPhone. Voy a ser honesto, sería mi primera incursión en una base de datos y Node.js no es de SQL también.

¿Le interesa a escuchar a los demás toma y experiencias sobre este tema, más opciones / pensamientos, y si estoy pensando en la manera correcta, o simplemente crear dolores de cabeza por mí mismo.

Answer 1

En primer lugar, nodejs es impresionante para escribir proxies TCP inversas a las bases de datos NoSQL. Usted puede dejar que todos los comandos estándar, pero pasan a través de alter / extender sus APIs con su propia magia, por ejemplo, haciendo MongoDB hablar HTTP o CouchDB parecen ser un protocolo binario a través de sockets.

Cuando se trata de elegir una solución NoSQL para almacenar piezas de juego y el seguimiento de jugador se mueve Creo que cualquiera Redis y CouchDB son los mejores candidatos.

1. CouchDB. Es rápido, fiable, y puede manejar una gran cantidad de conexiones HTTP simultáneas. Es probablemente la mejor opción, porque a diferencia de Redis puede difundir un mensaje cuando un documento cambia. El continua cambios en la API hace que sea muy sencillo para que usted tenga monitor de aplicación de cada jugador para Los cambios en su tablero. La solicitud podría ser:
   

   curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000

   
   Cada cliente recibirá un objeto JSON por línea en cualquier momento la respuesta se cambia un documento pertinente. (Y una nueva línea en blanco cada 1000 ms como una especie de mantenimiento de conexión.)
   
2. Redis. Se utiliza un protocolo basado en la línea simple (como MemCached ++) para hablar sobre un zócalo y le permite almacenar listas, conjuntos, con hashes arbitraria - incluso binarios - valores. Es muy rápido, porque todo lo que sucede en la memoria, pero se conserva en el disco de forma asíncrona. Pero la mayor parte de todo lo que debe evaluarlo porque ya tiene PubSub notificaciones al horno en. tenga en cuenta que tendrá que publicar las notificaciones de forma explícita se mueven sobre un canal de la cuota de jugadores porque Redis no publicará automáticamente cuando un clave / valor cambios.

Desde MongoDB no tiene un mecanismo para observar cambios como-suceden o hacer pubsub no considero que sea una opción buena, aunque con un esfuerzo extra que podría hacer que funcione.

Para concluir, es posible que pueda reemplazar "la gran pila LAMP" con CouchDB solo, Redis solo, o bien uno colocado detrás de una aplicación del nodo para filtrar / extender las API que ya proporcionan en algo que se adapte a su juego.

Mucha suerte!

Answer 2

Me acaba de comenzar el aprendizaje mongo, y no es difícil de aprender. Cosas como índices y explicar existen y funcionan de la misma. Cuando se trata de la arquitectura, que quiere pensar lo contrario de SQL; en lugar de tener una buena razón para de considerarse algo normal, es necesario llegar a una buena razón para normalizar. Los chicos de 10gen (que hacen mongo) dirán que pensar jerárquica es una forma más natural de pensar acerca de las cosas, que estoy de acuerdo con (tentativamente). Buscadores sienten especie de SQL-ish, así, a pesar de que todavía va a utilizar mapas reducir para las consultas de agregación.

Por lo que sé sobre el sofá, la gran diferencia es que hay un fuerte enfoque en la cosa duplicación distribuida. Mongo se centra más en el rendimiento en cantidades masivas de datos (aunque tienen autosharding y una gran historia de escala también). Me gustaría ir mongo, a menos que se les va a usar los aspectos distribuidos de sofá.

Nodo tiene que ser la cosa más fresca nunca, y creo que esto sería una gran aplicación para ello. Tengo cero experiencia con él, pero por lo que he leído, es ideal para cargas de solicitudes pequeñas, y las escalas maravillosamente. Javascript idiomática se presta muy bien a todo el modelo de concurso completo, y con V8 que pasa justo obscenamente rápido.