Come dovrei architetto mio server DB & API per un multiplayer iPhone gioco da tavolo a turni? (Pensiero su nodejs, Mongo, divano, ecc)

Question

Sto lavorando a un gioco da tavolo a turni per iPhone e Android alla fine. Sto usando Appcelerator Titanium per svilupparlo. Il mio progetto multiplayer è simile a parole con gli amici. Gli utenti, a turno, quando è pronto, e poi gioco da tavolo dell'avversario viene aggiornato di conseguenza.

Uno dei miei bisogni è quello di avere un API di messaggistica che consente ai dispositivi dei 2 giocatori per aggiornare l'un l'altro sullo stato del tabellone dopo un movimento. Pensando di fare questo con JSON e mantenendo un oggetto JSON sul dispositivo che contiene la posizione di tutti i pezzi del gioco da tavolo in un dato momento. Questo è l'oggetto che sarà necessario aggiornare il dispositivo locale e quindi inviare una modifica al dispositivo dell'avversario dopo un movimento è fatto.

ho fatto API in passato per piattaforme mobili e per farlo ho usato PHP con MySQL e inviato JSON avanti e indietro tra il server API e il dispositivo mobile. Funziona proprio dandy per bassi utenti simultanei, e in generale non massicce applicazioni. Ecco a sperare questo otterrà massiccia;)

Ora, invece di un server httpd generale e simili, sto iniziando a pensare a socket persistenti e se sono necessari o non per il mio nuovo gioco. Sto anche pensando che potrebbe essere intelligente per rinunciare al grosso stack LAMP, e per la scalabilità e forse facilità di sviluppo, a propendere per un flusso di dati di qualcosa come Mongo / Couch -> node.js -> iPhone. Sarò onesto, sarebbe la mia prima incursione in un db non SQL e node.js pure.

interessato a sapere degli altri prende ed esperienze su questo, più opzioni / pensieri, e se sto pensando nel modo giusto, o semplicemente la creazione di mal di testa per me.

Answer 1

Prima di tutto, Nodejs è impressionante per la scrittura di proxy TCP inversa ai database NoSQL. Si potrebbe lasciare che tutti i comandi standard passano attraverso ma alter / estendere loro API con il proprio magia, per esempio rendendo MongoDB parlare HTTP o CouchDB parlano un protocollo binario su socket.

Quando si tratta di scegliere una soluzione NoSQL per la memorizzazione di pezzi gioco da tavolo e di monitoraggio per giocatore si muove Penso sia Redis e CouchDB sono i migliori candidati.

1. CouchDB. E 'veloce, affidabile e in grado di gestire un sacco di connessioni HTTP simultanee. E 'probabilmente l'opzione migliore perché a differenza di Redis può trasmettere un messaggio quando un documento cambia. Il continuo cambia API rende super semplice per voi di avere monitor di applicazione di ogni giocatore per modifiche al loro bordo. La richiesta potrebbe essere simile:
   

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

   
   Ogni cliente riceverà un oggetto JSON per linea in qualsiasi momento risposta un documento pertinente viene modificato. (E una nuova riga vuota ogni 1000ms come una sorta di keepalive.)
   
2. Redis. Esso utilizza un protocollo basato linea semplice (come memcached ++) per parlare su un socket e consente di memorizzare liste, insiemi, gli hash con arbitraria - anche binari - valori. E 'molto veloce, perché tutto avviene in memoria, ma viene mantenuto su disco in modo asincrono. Ma più di tutto si dovrebbe valutarlo perché ha già PubSub notifiche al forno in. Nota che dovrete pubblicare in modo esplicito le notifiche si muovono su un canale della quota di giocatori, perché Redis non pubblicherà automaticamente quando una chiave / valore cambia.

Dato che MongoDB non dispone di un meccanismo per osservare i cambiamenti come-si-accadono o fare PubSub Non mi considero una buona opzione, anche se con sforzo supplementare si potrebbe farla funzionare.

Quindi, per concludere, si può essere in grado di sostituire "il big stack LAMP" con CouchDB da solo, Redis da solo, o con uno posto dietro un'applicazione nodo per il filtraggio / estendere le API che già forniscono in qualcosa che misura il vostro gioco.

Buona fortuna!

Answer 2

Ho appena iniziato l'apprendimento mongo, e non è difficile da imparare. Cose come indici e spiegare ci sono e funzionano allo stesso modo. Quando si tratta di architettura, si vuole pensare il contrario di SQL; invece di aver bisogno di un buon motivo per de-normalizzazione, è necessario trovare una buona ragione per normalizzare. I ragazzi di 10gen (che fanno mongo) diranno che il pensiero di gerarchico è un modo più naturale di pensare alle cose, che sarei d'accordo con (provvisoriamente). Finders sentono sorta di SQL-ish e, anche se si continua a utilizzare carta-a ridurre per le query di aggregazione.

Da quello che ho capito su divano, la grande differenza è che c'è una forte attenzione sulla cosa replica distribuita. Mongo si concentra di più sulle prestazioni su grandi quantità di dati (anche se hanno autosharding e una grande storia di scala troppo). Vorrei andare mongo, a meno che non si sta in realtà intenzione di utilizzare gli aspetti distribuite di divano.

Il nodo ha ottenuto di essere la cosa più bella mai, e credo che questo sarebbe un grande applicazione per esso. Io ho zero esperienza con esso, ma da quello che ho letto, è grande per i carichi di piccole richieste e bilancia meravigliosamente. javascript idiomatica si presta molto bene a tutto il modello a eventi, e con V8 funziona solo oscenamente veloce.