#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    1
    Rep Power
    0

    Questions about multiplaying structure and implementations


    Hello! I am a newbie to multiplaying game programming.
    I am currently working on a 3D Multiplaying Internet Game. The 3D part is working fine. I am planning to communicate using TCP with threads. Sending struct to the others in order to let the game status up to date.

    However, I am getting trouble in threads.

    Actually, I have got two plans. The first one, one server with three clients. clients send the data to server and server update all the information and broadcasts to the clients. Then, the clients has only three threads. One for their i/o and two for their tcp sockets send/rec operations. However, server might need to have 7 threads. Six for communications and one for self i/o.

    The second plan is all peer. Each player broadcasting their new inputs to the others. So, in order to collect and boardcast at the same time, two threads for send and receive for each pair of connection. And, finally, 7 threads needed, as one for self i/o, 6 for 3 others players send/receive connection.

    I want to implement the second plan. Am my algorithm alright? I dont have such experiences in implement that. Would it be feasible?

    Besides, what else have to be taken care in implementing this kind of structure? I am going to include an unsigned long int variable as a synchronization tool in each struct sent. Would it be too heavy in work load?

    In opengl, the redering per second is about 150-180 frames. Could it be possible that the socket could send 150-180 data struct per second?? My data struct is only about 32bytes each.

    I have been seraching through the internet. However, the information available is not much. The deadline is coming. Please help!
  2. #2
  3. C# Addict.
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2004
    Location
    Earth
    Posts
    283
    Rep Power
    28
    I would go with the first plan, since it follows the KISS philosophy.

    As for the ability to send all those packets you should do the math.

    So 32 bytes = 256 bits with 180 sent a second you would have 46080 or 46k bits transmitted a second. But thatís excluding the overhead of TCP.
    So it might work, it depends on the connection.
    There are none so blind as those who will not see. ó Jonathan Swift

    My 2D Physics Engine.
    My Remake of UQM.
    Both are written in C#.
  4. #3
  5. Contributing User
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jun 2004
    Location
    Switzerland
    Posts
    1,152
    Rep Power
    1901
    I would definitely prefer the first approach. Sending data to a central from which to be processed and distributed is much easier on bandwidth and systems complexity.

    About sending updated: traditionally you'll only send updates to the clients. So if you have a moving player you only send an update when the player changes his speed or direction. This way the client can do the predictable changes on it own. You'll want to send a general update from time to time to ensure synchronization...
    - Hugh of Borg

    The first thing young borg are taught: Keep away from Microsoft software!

IMN logo majestic logo threadwatch logo seochat tools logo