Take the 2-minute tour ×

i developed a real-time fast paced shooter game on Windows Phone a couples month ago, then i ported the Game over to Windows also.

Now i am thinking about making the game multiplayer-capable but i have a few questions since i never done it before:

Considering that its a shooter so there is a lot of bullets, game objects of all types, players/mobs movements etc... :

  • Is working with Asynchronous sockets fast enough in this situation?(WP player with Windows player or WP with WP or Windows with Windows)
    • Note: Players would be communicating over a centralized sockets server
  • Is the performance of Windows Phone Sockets good enough?(3G/4G, Wifi)
  • Should i use TCP or UDP or both(UDP for objects/actions and TCP for chat for example)
  • How would you proceed to send the data, what kind of data would you be sending and how often?

Thanks a lot in advance! :)

share|improve this question
add comment

4 Answers

up vote 3 down vote accepted

Generally shooting games use UDP to send packets with shots and not think much about delivering them 100% of the time since there are so many packets and it wouldn't matter anyway if a few got lost in the cables. But why not try TCP first and switch to UDP later if problems occur?

share|improve this answer
add comment

The general recommendation would be to send the bare minimum of information which generally tends to be the user input rather than world state.

e.g. At 142 seconds in to the game, user A hit the fire button. At 145 seconds, user B started going left.

(As from the user input, it's possible for each client to recreate world state... usually. If you've got random elements then this is a good way to catch and rethink them in your design.)

As for protocol choice, I would recommend starting with HTTP and work "down" from that. This offers the greatest "built in" functionality (such as NAT traversal and proxying) and will hopefully highlight early any networking logic issues that you may have (such as whether you prediction algorithm is reasonably close to players gameplay style so that when re-sync'ing does happen on the client, the "snap back" isn't annoying).

When / if you determine that HTTP is too heavy / slow then you can swap it out for something like UDP with the knowledge of what needs to be achieved.

share|improve this answer
Thanks for the reply. Do you have a suggestion for how to deal with world objects? Ex: mobs movement, mobs spawned, mobs died, bullet traveling? Thats a lot of infos there that absolutly needs to be synchronized i think! –  Armkreuz Jul 12 '12 at 1:36
Generally I would suggest you really want to get to a point where the movement of any NPC (and environment) is completely deterministic and thus can be derived by each client without the need to chat about it. e.g. If you know when and where the player's character hit the "fire" then every client should be able to calculate the bullet's trajectory without the need to transmit or receive it. –  lzcd Jul 12 '12 at 2:19
add comment

I would beg, borrow, and steal good ideas from other games. id Software's Quake 3 has its network source open and many folks have dissected it. Most FPS games today use UDP in order to ensure timely delivery of time-sensitive data. Old data that is dropped shouldn't need a new packet.

Quake 3 uses a strategy where the last known good snapshot ID is sent with each packet from the client and the server sends an ID with each snapshot internally. At this point when the client drops data, it keeps sending the last known good ID on its side and the server sends a diff from its buffer of snapshots.

If you were using TCP you would have to wait for old data to be acknowledged by each client, which is going to add artificial latency which is intolerable for first person shooters.

share|improve this answer
add comment

Mixed: for authentication, login or changing server/client information use TCP but ingame when the most data travells on cable use UDP. TCP will make higher latency because of the connection-oriented operation.

share|improve this answer
add comment

Your Answer


