game server/client user input/event handling

Question

I'm currently getting my feet wet in the realm of networking, so I set a goal to make a simple client/server game using SFML for both graphics and networking. In my head it seemed easy at first, but the more I got into it the more questions arised. I didn't want to make a post before I hadn't done any research, but now, having read many blog posts and articles, there's nothing to lose.

The game I'm working on is a trivial PONG game: server waits for 2 players, when they are connected, clients send server paddle's X position only if mouse is moved. Server reads in the X pos. and sends each client opponent's position.

The problematic part is opponent's behaviour on the client side. When playing both clients + server on my computer, using 100% CPU speed server side, the opponent moves smooth, but having CPU running as fast as it can is nonsense! If I reduce update speed the movement becomes weird so to say.

1. Might there be anything to do with client-side prediction (I read about it too, but didn't quite grasp how it would be implemented)?
2. Since there are frequent position changes, should the server's update speed be as high as possible?
3. I'm using TCP, which I understand is "reliable" = no lost packets. For such fast-paced game like PONG, which protocol is more suitable.

Now, I do not fully understand the magic behind it all, very very thrilled about network programming. I've never been more excited during programming as I am dealing with networking.

Thank you for your attention!

Answer 1

CPU 100% is most like a loop running, maybe to check if mouse has moved? You have to realize, that if you don't restrict message sending with time passed, you might send thousands of packets per second, when moving mouse.

1: Client-side prediction is movement you do, before server says it's ok to move. So, Client pressed move button and instead of waiting for new coordinates from server or somekind of move command to come from server, the client predicts that, pressing forward, moves you forward and thus, when server finally send the commands/coords, client should be in right position allready. This tries to eliminate lag perception.

So, Client side prediction is easy to add. You have to run same movement logic on server and client. You have to note, that when server eventually send the new coordinates, you have already send new movement stuff from client and also predicted new movement. So if you just take and set coordinates from server to client object, you snap back to previous position. You can prevent snap back by recording where you were after predicting movement and then check if client is on right track when server message comes and if not, snap it.

2: 30 updates per second should be enough ( 1000ms / 30 == every ~33ms). You can play around with this number to get some feeling. Anything between 20-50 can work.

3: TCP is fine for this kind of learning project and it can work even in larger projects. TCP does not guarantee that there is no packet loss ( packet lost between server-client), but if packets get lost, TCP can recover from it, but it can cause heavy lag. UDP however is little bit harder to use, because server can never know, if packets arrived or not.

Anyways, i would say that you should definitely limit sending the packets, limit your update loop running time and have fun. Also consider what you should be sending, you can send mouse movement event or direct mouse coordinates. Best would be events, so that client does not decide anything, it just tells server what buttons were pressed or what actions were requested. When server update loop runs, server could send new coordinates to every client.