How to develop a real-time game server for html5 web app?

Question

I'm contemplating a graduate project proposal of developing a rather complex HTML5 game that requires real-time server communication. The premise of the actual game play is simple: 10 players battle it out with one another. Many pieces of information will be tracked, such as: player health, each players X/Y position on the screen, items in inventory, etc. The server structure for all of these potential changes, however, is not so simple.

My goal is to develop a scalable environment that can theoretically maintain 50,000 concurrent players in 5,000 separate game instances while all running reliably with less than 1 second latency. My comfort skill set is mostly in web technologies. For a small scale app, I would use PHP/MySQL. But for an app this large, I am confident HTTP requests will not be even a short term solution.

I don't really know how to approach this situation.

• Should I develop my own server, if so, what language should I use? I do not want to use NODE.JS. Is Python viable?
• Is a single, high-performance server capable of maintaining this type of load, or will I need to look into developing a cloud/cluster?
• What type of database read/write would be optimal for this situation? How would I scale beyond 50,000 players? How would this scale with a cloud/cluster?

Answer 1

This is too broad, you need to work out some things.

• What do you call a high-performance server. You can get some very powerful servers with 4 CPU sockets and such. But it is likely 4 servers with a single socket may be cheaper.
• Real time (meaning each game instance must be processed all the time at some frequency) or turn based (meaning you just need to process whatever a player did on their turn)
• How complex is the game logic? 3D world? Physics? Advanced AI?
• Are the game instances like a single short match (I am guessing this for 10 players), and the the player joins another, or a persistent world?

Assuming you are trying to get somthing fairly demanding, but with each game being a single match, the generally direction I would go is:

• Carry on using PHP/SQL for the general website, registration, logins, any persistent stuff like player stats, any items/skills/etc they have, etc.
• Write the actual game as a separate thing, possibly almost without any database stuff. Just have the game instance load in whatever the 10 players needs from the DB at the start. At the end of the match it can save stuff back to the DB. Avoiding in game DB access for general game logic avoids the DB scaling issues.
• The game instance could be its own process (but 5,000 might not scale well). You can alternatively run the instances in there own like server process with some maximum per process, possibly then split down further with some number running on each thread. The downside is if you crash a process or have some other glitch you effect multiple games. Either way this is scalable, you can put these game servers on multiple machines.
• The game instances would be written as if you were doing a PC client-server game or similar. The main logic would not really care about the client being on a web browser. You will need something like a GameInstance.Update method that you can run x times per second, and reads anything from the client sockets, processes an update step and sends stuff back to the clients.
• The game server instances could use HTTP for communication with the browser client. You could also try out WebSockets which give a more raw TCP connection.
• The game server could use node.js which is useful if you want to share common code with the client and server. Another option to do that would be to use something like C/C++ with emscripten to compile to Javascript for the client and use native C/C++ on the server. There might be some other languages you can do similar things with, but those are the ones I have used.