3

I am in the planning phase of a mobile multi-player real time game and I am considering what architecture to implement in order to keep track of state within a game lobby.

I have considered making the game either peer-to-peer where all devices within the same game lobby (4 players max) will emit their position to other players as the game progresses. I have also considered having the players connect to the server and the server keeping track of the game state and sends the state to every player.

If I do go this route and implement the server using node what are some considerations that I need to look at?

I have a prediction that scalability will be a major issue as the server has to keep track of the state of every game lobby that is nominally running at 60 fps. If I have 100 active lobbies I can foresee the issues that could arise. Will this be the case and should I look into a different networking architecture? or could I get significant capacity until the server reaches a maximum?

Kevin B
  • 94,570
  • 16
  • 163
  • 180
Alan
  • 1,134
  • 2
  • 13
  • 25
  • you did not mention using Web Sockets which after an initial upgraded HTTP connection have a per message overhead of just (2 byte + 4 byte) ... see https://stackoverflow.com/questions/14703627/websockets-protocol-vs-http – Scott Stensland Feb 11 '15 at 22:04
  • So you recommend that I use web sockets? the persistent connection would definitely benefit performance. – Alan Feb 12 '15 at 14:01

2 Answers2

2

Depends highly on the kind of game. The peer-to-peer solution is probably tricky and cheating would be pretty easy except you validate it on every client but since you want to run it on a mobile client that would slow down the game a lot.

It makes more sense to validate the data on a central server and just send out the validated data.

In general the FPS doesn't matter for the server at all. Every client just emits user input to the server and not every frame (button pressed - button released). The server uses all this information and calculates what needs to happen and sends regular updates to the client. Then the client renders everything like 200ms (really depending on the kind of game) in the past and "predicts" what the server will send in the next update to make it look smooth. Just read this article, it explains it better than I ever could: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

But yeah, it will def take a lot more power than a normal website. However, the single lobbies don't need to communicate with each other so you can super easy just use 3 servers in parallel. You can expect Node to perform pretty well in comparison to most alternatives you have cause it handles concurrent connections very well. Just make sure you don't run CPU heavy things because that will pretty much kill Node (if you just receive status updates and use basic math to validate it and send it out again ->perfect choice).

Hope that helps

Ben A.
  • 480
  • 2
  • 7
-1

The biggest issue you will run into is Node is not built to handle application that are as latency sensitive as real time simulations.

HTTP is a bloated protocol, and it's text-based. It will not work for the type of games most people would consider multiplayer. It may work for games in which high latency is not an issue such as facebook games.

StevenDStanton
  • 841
  • 1
  • 7
  • 23
  • Well it would not be an http server, but a raw tcp or udp one – Alan Feb 11 '15 at 22:01
  • 2
    That is absolutely not true, node is built for pretty much exactly this. As Alan & Scott said, as long as you don't use http it's a good choice. – Ben A. Feb 12 '15 at 10:39