Specifically which aspect are you interested in? There's nothing particularly special about mobile devices or ad hoc Wi-Fi networks (except in an ad hoc network, not all devices may be able to communicate with each other, so some mesh networking can help but unnecessarily complicates matters for the normal case).
I'll answer the broader question first, because it's more interesting. In my experience, there are a handful of major considerations:
- Server/client or peer-to-peer? By this I mean whether there's a "master" deciding the true state of the world and communicating this to all clients. Avara is the only game I know of that is "peer-to-peer" in this sense (peers sent commands to all other peers; this proved bandwidth-heavy for modem users on 6-player games). I am not aware of games using more sophisticated network topologies to communicate game state (e.g. only sending data to one client on each LAN).
- What do you do about latency? Avara is the only game I know of which lags everyone locally by the "latency tolerance" in order to get a consistent state of the world, which was terrible if someone was on a modem (turning off compression helped a lot). There are various ways to do "latency compensation" (e.g. in Half-Life/CS), some of which could also work on peer-to-peer games.
- Time sync? For client-server games, you at least need to worry about a changing RTT. For peer-to-peer games, I think you also want to agree on timing that minimizes the effective maximum latency.
- What if clients disagree about the state of the world? Avara just lets peers decide on their own state of the world (and displays "reality fragmentation detected" if it senses a mismatch, which might happen due to dropped packets or a too-low "latency tolerance").
- What if a player leaves? For a P2P game, you might have to agree on a consistent game state (e.g. if the player was disconnected after sending commands to a subset of other peers). For a client-server game, you might have to elect a new master.
And now, after watching the Spaceteam trailer:
I have no idea how it works, since I haven't reverse-engineered the protocol. However, it's pretty simple to make something that works well enough:
- Use some sort of P2P discovery to find players (e.g. Bonjour; there should be plenty of docs and samples out there).
- Communicate with peers. I've done this with GameKit circa iOS 3/4 (I'm not sure if it still works over Wi-Fi).
- Elect a master. This can be as simple as whoever presses "ready" last attempts to be the master. In some edge cases you might have to handle failure.
- Let the master decide everything. Spaceteam is not latency-sensitive; Wi-Fi latency tends to be at most a handful of milliseconds, and nobody's really going to notice if one device is slower by 100 ms (as long as the UI responds fast enough).
alljoyn
api? alljoyn.org – Therron