How should I architect my DB & API server for a turn based multiplayer iPhone board game? (thinking about nodejs, mongo, couch, etc)

Question

I'm working on a turn based board game for iPhone and eventually Android. I'm using Appcelerator Titanium to develop it. My multiplayer design is similar to Words With Friends. Users take turns when ready, and then the opponent's game board is updated accordingly.

One of my needs is to have a messaging API which enables the 2 players' devices to update one another on the status of the game board after a move. Thinking of doing this with JSON and keeping a JSON object on the device which contains the location of all game board pieces at any given time. This is the object that will need to update on the local device and then send a change to the opponent's device after a move is made.

I've done APIs in the past for mobile platforms and to do so I've used PHP with MySQL and sent JSON back and forth between the API server and the mobile device. Works just dandy for low concurrent users, and generally non-massive apps. Here's to hoping this one will get massive ;)

So now, instead of a general httpd server and the like, I'm starting to think about persistent sockets and if they're needed or not for my new game. I'm also thinking that it might be smart to forgo the big LAMP stack, and for scalability and maybe ease of development, to lean more towards a data flow of something like Mongo/Couch -> node.js -> iPhone. I'll be honest, it would be my first foray into a non-sql db and node.js as well.

Interested to hear others' takes and experiences on this, more options/thoughts, and whether I am thinking about it the right way, or just creating headaches for myself.

Answer 1

I've just started learning mongo, and it isn't hard to learn. Things like indexes and explain are there and work the same. When it comes to architecture, you want to think the opposite of SQL; instead of needing a good reason to de-normalize, you need to come up with a good reason to normalize. The guys at 10gen (who make mongo) will say that thinking of hierarchical is a more natural way of thinking about things, which I would agree with (tentatively). Finders feel sort of sql-ish as well, although you will still use map-reduce for aggregation queries.

From what I understand about couch, the big difference is there is a strong focus on the distributed replication thing. Mongo focuses more on performance over massive amounts of data (although they have autosharding and a great scaling story too). I would go mongo, unless you are actually going to use the distributed aspects of couch.

Node has got to be the coolest thing ever, and I think this would be a great application for it. I have zero experience with it, but from what I have read, it is great for loads of small requests, and scales up wonderfully. Idiomatic javascript lends itself quite well to the whole eventing model, and with v8 it runs just obscenely fast.

Answer 2

First of all, Nodejs is awesome for writing reverse TCP proxies to NoSQL databases. You could let all the standard commands pass through but alter/extend their APIs with your own magic, e.g. making MongoDB speak HTTP or CouchDB speak a binary protocol over sockets.

When it comes to choosing a NoSQL solution for storing board game pieces and monitoring for player moves I think either Redis and CouchDB are the best candidates.

1. CouchDB. It's fast, reliable, and can handle a lot of concurrent HTTP connections. It's probably the best option because unlike Redis it can broadcast a message when a document changes. The continous changes API makes it super simple for you to have each player's app monitor for changes to their board. The request might look like:
   
   

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

   
   Each client will receive a JSON object per line in the response anytime a pertinent document is changed. (And a blank newline every 1000ms as a sort of keepalive.)
   
   
2. Redis. It uses a simple line-based protocol (like MemcacheD++) to talk over a socket and allows you to store Lists, Sets, Hashes with arbitrary--even binary--values. It's very fast because everything happens in memory but is persisted to disk asynchronously. But most of all you should evaluate it because it already has PubSub notifications baked in. Note that you'll have to explicitly publish move notifications over a channel the players share because Redis won't automatically publish when a key/value changes.

Since MongoDB does not have a mechanism for observing changes as-they-happen or doing pubsub I don't consider it a good option, though with extra effort you could make it work.

So to conclude, you may be able to replace "the big LAMP stack" with CouchDB alone, Redis alone, or either one placed behind a node app for filtering/extending the APIs they already provide into something that fits your game.

Best of luck!