views:

531

answers:

1

I'm working on a multiplayer iPhone application that allows up to 6 users to connect and play in "real time." I've been looking at hosted and non-hosted socket servers (SmartFox, ElectroServer, Photon/Neutron, ProjectDarkstar) and I'm wondering if anyone has any recommendations for services or implementation? Anyone have any idea of what a game like Zynga's Live Poker uses for this type of functionality or what kind of hardware you might need?

Some sub-questions:

  1. The game is turn-based. Would it make more sense to use AMF and poll a server or should I go for the socket-based route? My current concern is concurrent connection limits and hosting costs.

  2. Is it possible to "broadcast" a device as a socket server? i.e. once I get all my players connected, could I allocate one of the 6 devices to be a socket server and push all communication through that device? Would that be crazy? That would get around concurrency issues and I'd only need to rely on the socket server service as a lobby for the initial connection. The allocated user would stay connected to facilitate game to server communication.

+1  A: 

1.

It's much easier to use polling, and since the game is turn based you could poll at a relatively slow rate (perhaps a couple of seconds), which means less battery drain. That said, using sockets or persistent HTTP connections would be a slicker way of doing it (and much more work). These two questions might be of interest:

How do I create a chat server that is not driven by polling? COMET (server push to client) on iPhone

I don't know why you would use AMF. Why not JSON? Or maybe HessianKit?

2. It makes a lot of sense to designate one of the devices as a server. Having a completely decentralized network of game clients that need to synchronize is a very hard task. Again, since your game is turn based, which doesn't require perfect real-time synchronization, you don't have to worry that having centralized state will introduce more latency.

If you intend for users to play over a local network, you should consider using GameKit.

Felixyz
On #2. Any resources on how to get started doing that? I've been checking our RakNet (http://www.jenkinssoftware.com/) and think that might work, but I'm far from a C expert so I'm unsure if it's something I can accomplish. Thanks for the insight.
Typeoneerror
Perhaps this could be simpler than you think. You probably don't need a full-blown game networking library. The way I would do this is program the app so that inputs and logic and screen representation are completely separated. Then write a dummy co-player class that stupidly emulates a second player's controls. When that works, plug in GameKit to get actual control events from that layer. When that works, write up a server using Google App Engine and use polling to get state updates. Again, this should only interface with the part of your code where input events get passed in.
Felixyz
As for making one of the devices a server, you just arbitrarily decide at the time of establishing the connection which one will be the server (perhaps the one that first broadcast itself). All the other devices don't update their interface in response to user events (except for simple things like highlighting buttons) but send them on to the server, and then get event objects back which cause the interface to update. Don't be tempted to let each device update it's own state. (That's often necessary in real-time games, but very hard to pull off.)
Felixyz