17

I´m planning to create a WebGL-based, realtime strategy game, where players are able to play together. I´ll use Node.js to create the game server, and websockets for realtime connections.

I´ve broken my mind about what would be the best concept to synchronize the clients.

One possibility would be to send only the orders of the users (moving units, building buildings etc.) to the server, which sends them to all other clients. But here, I have the problem of the delay. I think that the games would get async this way.

Another possibility would be to calulate the game on the server. The clients still send the instructions to the server, but the server sends now all changed states of all units&buildings to the clients in a high interval. The problem is here the high amount of data and how fast this can be...

Do you have some other ideas or improvement proposals?

Thanks!

yojimbo87
  • 65,684
  • 25
  • 123
  • 131
Van Coding
  • 24,244
  • 24
  • 88
  • 132

6 Answers6

23

Basically you have to decide between speed vs security.

Letting the client do the job and the calculations is faster but the data is at risk because the client can manipulate the data.

On the other side, having the server do all the job is slower but the data is more secure.

You could opt for a dual approach, decide to let the client calculate only some data, synchronize and then check for its validity, and let the rest being executed on the server.

It also depends on how fast the game runs, the amount of data to calculate, the speed of the server and band/connections, etc...

You should prototype both methods and try some tests to emulate the client and servers load.

If the game is small I would opt for a more server-side work. On the other hand, for a much complex game probably sharing more work to the client is best. Anyway I think a tradeoff is always needed.

Here are a few links you may find useful

Multiplayer Game Programming Introduction

Real time strategy networking

Multiplayer Programming thread (old but still with many useful links)

Lag Compensation

Prevent Multiplayer Cheating

The first link has helped me a lot back in the days and imho is still one of the best resources avaiable on the subject.

Books

Multiplayer Game Programming

Community
  • 1
  • 1
Jose Faeti
  • 12,126
  • 5
  • 38
  • 52
6

I would suggest to watch these resources regarding browser based game development concepts:

yojimbo87
  • 65,684
  • 25
  • 123
  • 131
1

Unfortunately I have no experiences in WebGL based online games, but usually it is a good approach to let the game logic be executed on the client side, and synchronize the results.

In this approach it is important to keep track of what game object is "owned" by what client. Clients only send updates (creation, update, deleteion) from their own objects and receive the updates of the other game objects from the other clients.

Additionally you can set up a messaging framework to deliver additional messages like "Player has entered/left" or something like that.

This concept has proven useful for a game I created, and I hope it is as useful to you.

Constantinius
  • 34,183
  • 8
  • 77
  • 85
1

You should have the game state and logic on the server, otherwise your game is wide open to cheating. The server is the ultimate authority the game state.

evilcelery
  • 15,941
  • 8
  • 42
  • 54
0

For security reasons, all the logic should be on servers side, and all the data update is on server.

But the client is able to predict some logic and play animation first, which is called client prediction.

The server side is in charge of verify the client logic, if there is no cheating, all done. If there is someone cheating, the server can tell the client to go back to right state.

If you are using node.js for server, there is an open source framework , pomelo . And there is also a full source code demo and online demo for it: lordofpomelo

Charlie Circle
  • 51
  • 1
0

Not sure about WebGL, but to my understanding following approach will be good.

  1. Initialize all objects (which are common across players) on server and run them
  2. On client start, it will request all renderer (related to specific client) for the objects running on server.
  3. client will render the objects on UI for all recieved renderer.
  4. When client make any update on UI, changes will be notified to server, and server will update the object accordingly
  5. When objects common between players are modified by one player, each player (client) will be notified to make UI changes.

This approach will be specific to common objects not UI / client specific objects.

hungryMind
  • 6,931
  • 4
  • 29
  • 45