How to use websockets for real-time gaming

Question

I want to make a 2 player pong game that uses websockets and node.js server. socket.io is used on both client and server. So far, my only experience is creating a chat application.

This is my first attempt at a multiplayer game so I'm not so familiar with network gaming. Should the server keep track of:

1. Every position the ball is at and how often or when?
2. player movement, player move left or right, what if I press and hold for awhile, how do I handle this? Should I send like a pressHoldStartPosition and pressHoldStopPosition? I guess this is easy if I only allow pressing but not holding down.

My thoughts:

1. When the ball hits a player, the client calculates velocity, start and end position and the other client should perform the correct animation from that.
2. No idea.

Void

You should definitely have a look at @RobHawkes blog: rawkes.com He's developed, and continues to build, a HTML5 multiplayer game called Rawkets rawkets.com. I'm sure he'll have shared a whole bunch of information on subjects that are very relevant to what you are looking for and additional things you'll come across. – Mafala

Answer 1

1. The clients calculates - nothing - unless you want it to predict next game step* (server anwser). The whole game runs on server which is one and only trustworthy source of data and calculations. In pong like games where there is less than 10 objects you can send data quite often (50ms interval will do). For a ball I'd send [x, y, velocity, or angle], for a paddles [x, y]. Then interpolate (animate in time - 50ms) between old (x,y on client) and new (x,y which you just got from server).

2. Don't send milion copies of - player pressed up - rather send one packet each period of time (100ms?) containing informations like "player is pressing up" for 100ms, or "player set position" to (32, 100) then check server-side was this move possible and accept it or reject.

Maybe this thread will help with your adventure:

Multiplayer JavaScript game built with Node.JS - Separating players

[*1] preditction is a lag compensation mechanism which you can implement later. In simplified way it means that server and client shares some of game logic code and when client has no current data from server it tries to simulate what is happening in the real game.

Tieck

Answer 2

You are going to find books, upon books, about gaming networking.

In a brief description, here is what I find an interesting implementation: The server and the client calculate the physics of the game. The server will be a master, and have a correct state of all the entities, while the client will attempt to "predict" the state of the entities and keep a smooth animation. The client will get updated the correct state of entities from server periodically. In some games you might see entities suddenly teleport, and that is because client predicted position does not match the server actual position.

An entity state, such as the ball, or the players, usually contains information such as the position, velocity, button state (key down/key up).

Besides that, it is letting your imagination go wild and testing for the best solution and seeing what works. There are a lot to take into consideration, such as player latency and bandwidth.

Reserve

Answer 3

There is a stackexchange site dedicated to game development: https://gamedev.stackexchange.com/

Best practice is to only send updates that the clients need to know about. Also, generally you send the result of user actions and not the actions themselves. Things that can be calculated (physics) don't need to be sent, except for periodic sync points to account for floating point errors that accumulate error over time and to sync with remote user actions. This also makes the game seem more interactive and covers some of the stutter that results from network latency and jitter.

The main downside to this model is that if you have high network latency or packet drops, you will get the diverging timeline effect when the physics calculation continues and suddenly you get an update from the remote user indicating that they did something to effect the physics that we hadn't caught with yet. But this is a standard problem in most network games and the alternatives are worse for most types of real-time games.

Arriviste