2 Replies Latest reply on Oct 13, 2010 4:27 PM by mr_malee

    Multiplayer Game Theory using P2P

    mr_malee Level 1

      Hello. I was wondering if anyone could shed some light on how to go about creating a realtime multiplayer game using p2p.


      Traditionally clients connect to a server, they make rooms, join rooms and start a game. Clients send data to a server, the server processes this data and sends it back to all clients. The server also processes game logic to keep clients in sync. The main job of a client is to render the world the server is processing and send updates about itself.


      Now, when it comes to p2p there is no server to manage the game. So how do you go about creating a game where all clients need to stay in sync and no cheating can occur?


      One method I can only think of is using a host system. For example, all players connect to each other, they are all clients. Each client does some small tests in order to determine the best location for the host so all clients have good latency with each other. After this communication a host is selected out of the clients and will process the game information. All clients are notified of this host and send updates to that host only. The host receives the updates and sends them out to every other client. The host determines game state so every other client only needs to worry about rendering the world. Clients also manage lag by doing some interpolation and guess work on positions etc. When the host leaves / disconnects another host must be selected and the current state of the world is set to whatever that client has rendered.


      I think that method could work, the only problem is the host could cheat, one way around this might be to swap hosts every so often so no client can determine if they are the host or not. If all clients cheat then good for them :). Other than that the only option is to use a RTMP server, but this would negate the speed benefits that comes with RTMFP.


      I'm quite new to this new network stuff so if what I say is completly wrong then please let me know, I would also love to hear any other suggestions you guys have. I know a lot of new things have been added such as multicast and groups, but I don't know enough about them to relate here.



        • 1. Re: Multiplayer Game Theory using P2P

          Designating a "host" client is in no way better than the traditional sever/clients model due to the following:
          a. you would have to either direct connect each peer to the host, which is innefficient for large groups and not always possible(see NAT issues), or route messages to the host which may turn out to be slow
          b. average latency of clients-to-server vs one-client-to-all-the-others should be in favor of the former, given that a server is generally connected to a network backbone
          c. individual P2P connections may fail and/or the group may "rewire" itself at any time so detecting when the host leaves is tricky; not to mention efficiently designating the host, rocket science may be easier
          ...and more


          The way I see it, you have the following options:


          1. Build it entirely distributed:
          -each peer posts individual updates to the group
          -everybody listens to all updateds and creates own copy of the state; processing overhead should be no bigger for any peer than if it had to be the host
          -have the model loss resilient; some individiual updates may be lost to some, further messages have to be self-sufficient (i.e. declare absolute grid positions not step movement); timestamp every message, they may even arrive in reverse order
          -obfuscate the data model to give cheaters a hard time; keep a backup (yet more obfuscated) data model and swap if the current is compromised; have each peer be suspicious about every update, as if it was the server and maybe report suspected illegal moves


          2. Use RTMFP unicast with FMIS4(the $4.5k one)
          -same client/server model as RTMP
          -managed, no way to cheat (or is there?)
          -lowest latency due to RTMFP yet slightly increased overhead due to encryption
          -RTMP fallback may still be needed for some with firewalled UDP


          3. Use a hybrid of managed and distributed architecture
          -connect peers to the server and also with each-other into the mesh
          -manage security at server level
          -peers send frequent updates to both server and mesh
          -peers receive frequent updates from the mesh yet unfrequent updates from the server; server copy of the state is both a backup for data loss in the mesh and a doublecheck of data integrity
          -whichever individual piece of information is received earlier, via either mesh or server is assimilated to the local state and rendered
          -have peers that have low latency in the mesh request server to update them more often


          The choice from above depends a lot on the specifics of the application, maximum group size(for P2P bigger is better, huge is awesome), requested latency, reliability and security.
          Good luck.

          1 person found this helpful
          • 2. Re: Multiplayer Game Theory using P2P
            mr_malee Level 1

            Ah Great. Thanks for clearing that up for me.


            I do like the sound of using a hybrid approach, seems like it could be the speediest.


            Thanks for sharing. If anyone else has more ideas It would be great to dump them here.