I'm working on a game similar to Subspace. However, my network programming skills are quite lacking. The most I've done with winsock are simple chat and mud servers/clients, all using tcp, the server utilizing select() to handle multiple connections. Obviously, tcp in and of itself would seem to restrictive on this type of game. With that aside, I intend on learning what I need to about udp (doesnt seem very complicated from Network Programming for Windows, 2nd Ed.) to implement this design. Hopefully thos who read it can critique it and tell me what to improve, as this is about as naive an implementation as it gets. The scheme I'm considering works this way:

The server maintains a list of socket connections. TCP is used for connecting to the server (verifying etc) as well as chat and quitting.

A server worker thread reads datagrams and, if the sender is on the current players list, creates an internal message structure to be utilized by the main thread (ie game logic).

Another server worker thread reads anything on the outgoing message list and transmits as necessary. This thread, along with the client's udp sender, works with player information updates every 100ms, as well as any spontaneous updates as occur during the game (player alters movement vector, rotates etc). Aside from that, my other question is about the client input itself. With some other simple multiplayer games I've always used a sort of thin-client approach in that all input is just packed and sent to the server to be accepted and acted upon or rejected. Should that approach be used here as well? Hopefully that list is more explanatory than it feels and you understand what I'm asking. Thanks in advance.

UDP is not complicated. Its actually simpler than TCP, because its closer to the actual packet nature of network traffic. Its also very easy to use. I would not recommend a separate TCP connection, but instead, implementing reliable send over UDP, which is not very hard and will simplify some things (most 3D action games do this).

For the keyboard and mouse buttons, I recommend sending the raw player input commands to the server and having it process it. This is what is done in most popular games, for security reasons (if the client can easily alter its own position, it encourages cheating). For the mouse, I say, just let the client handle its own rotation, at least in the case of 3D action, otherwise, you're going to have mouse lag on the client side over the internet. The client just needs to send its orientation in space at regular intervals.

For a spaceship game, however, its possible you might also want to have the server handle the raw mouse rotation commands for security purposes as well. Just pick what suits you best... You might also just want to handle all the input on the client side and neglect security, if this is a hobby project (though it could be good to design your game with a professional perspective in mind).

Well, it's 2d so there is no mouse input whatsoever. :p

Now my other questions. You said that the client needs to send its orientation... If the server is receiving all of the raw input, shouldn't it be the server informing the client of where and how it is oriented? Basically leaving the client as a graphical processor updated by the server (with some prediction I'd presume).

Also, about the reliable send over UDP, I have an idea, but how would you implement something like that? Just send, wait for response and send again if x time elapses with no response?

Lastly, I should really read more before asking this, but I'm intrigued. I know that when I read from a TCP socket that I am either reading the whole packet or I'm not reading at all. Is it the same with udp? Is there a chance that packets get mangled etc? I realize I'm getting ahead of myself but any resources to get my going along those lines are greatly appreciated. Thanks a lot, Max.

Quote:

Original post by Woodsman If the server is receiving all of the raw input, shouldn't it be the server informing the client of where and how it is oriented?

Since you will implement the logic on the server to process input from different sources, you might as well send out all client input from the server and let the clients do the same thing.

Quote:

Also, about the reliable send over UDP, I have an idea, but how would you implement something like that? Just send, wait for response and send again if x time elapses with no response?

Yea you are basiclly right. Some kind of sequence number is usually used. This number is unique for each packet and used as packet identifier. If you send data continuesly you could embedd the acks (sequence numbere for the received packets) in your own packets. This way you don't have the extra overhead of sending acks as seperate packets.
There are many opensource libraries for this. A google search with "reliable UDP" should give you some links.

Quote:

I know that when I read from a TCP socket that I am either reading the whole packet or I'm not reading at all. Is it the same with udp? Is there a chance that packets get mangled etc?

From MSDN:
If the datagram or message is larger than the buffer supplied, the buffer is filled with the first part of the datagram, and recv generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost; for reliable protocols, the data is retained by the service provider until it is successfully read by calling recv with a large enough buffer.

An advice is to use a single threading model with a non-blocking UDP socket. It will make your life easier than with threads.
If you don't want to write the networking system by yourself, just use a free library. It will most likely do what you want.

It is recommendable to abstract the interface to TCP/UDP. It is quite simple to create a layer that makes UDP work "connection based" like TCP. The only difficulty is to detect a broken socket, and to create a reliable delivery system, but for the basic send and receive you can abstract it quite easily.

> about the reliable send over UDP, I have an idea,
> but how would you implement something like that?

There are source code libraries you could use:

ENet: http://enet.cubik.org
AirHook: http://www.airhook.org/

Both implement a reliable layer atop UDP. ENet is, imho, better suited for games and is well maintained by the authors and the community.

Hope this helps.

-cb

Ok, thanks a lot everyone. I think I have a pretty good bearing and some test projects I've made seem to work perfectly. My next question is this, since the client is just sending along it's input to the server I'm sort of shaky on this aspect.

Since the primary input of the player is right/left (rotation) and thrust/reverse thrust, should I send this as it happens (which could send a LOT of packets on a fast computer), only send the packets every xms, or just send when the player presses the key and then lets go. The only problem with the last one is that the player's down packet might get dropped so he wouldnt rotate or move until he released the button and pressed it again.

A workaround that might be a combination of send when its pressed and then every 30 ms or so send a packet that it's still down...

Er, if a mod sees that anon post could you delete it? Thanks and cheers.

I would recommend sending the input at a constant frequency.