Creating a game server loop

[Jackolantern]

(Split off from a_bertrand's project topic here)

One thing I have not been able to wrap my head around, is how do you make a real game server loop in Node.js? Obviously event-driven mechanics work great and are dead-simple, but we all know everything can't be event driven. For example, even when the player is just sitting there, doing nothing, monsters need to be moving around, and an aggressive one may attack a stationary player who gets too close. In a traditional game server, you would just have a nearly infinite while loop running that handles all of the world up-keep, while other threads handled the communications and player-specific work. But how do you set something like that up in node.js and socket.io? I tried setting up a continuous .nextTick() function that should let the socket.io events occur and immediately come back to do more world processing, but had mixed results. Is that how you would do it, or is there a better way, possibly through child processes? I know there must be a "best way", as node is beginning to power so many online games.

[a_bertrand]

If you want to make your server handle those kind of things, the best option is to use a "setInterval" on the server side. In the function called there you can do all the handling you want. Of course you can send events to your clients by keeping all the open sockets in an array and then call the emit function of each of those.

On my own implementation I want to make it... different. The server will be most likely passive and all the logic even monsters will be on the client side. Why? Because server resources are expensive, so not having to keep monsters, maps and more on the server side makes it easier. Therefore 1 client will be responsible for a given area of the map. When the player having that area as master leave the area, the server will try to re-locate the master token to somebody else, if nobody is there, drop it. Therefore all the logic is basically handled by the clients and shared across them.

Of course this open more options for cheating, but it can be mitigated by stats checks, for example if a player progress too fast you have an high risk of cheating, or simply by adding check code on the client side, which means if there is 1 cheater he will be detected by other players and that will trigger a server information.

[Jackolantern]

Thanks! I will just kind of leave it at that as I don't want to derail your thread lol.

Very nice work on this by the way!

[Darius]

If you want to make your server handle those kind of things, the best option is to use a "setInterval" on the server side. In the function called there you can do all the handling you want. Of course you can send events to your clients by keeping all the open sockets in an array and then call the emit function of each of those.

On my own implementation I want to make it... different. The server will be most likely passive and all the logic even monsters will be on the client side. Why? Because server resources are expensive, so not having to keep monsters, maps and more on the server side makes it easier. Therefore 1 client will be responsible for a given area of the map. When the player having that area as master leave the area, the server will try to re-locate the master token to somebody else, if nobody is there, drop it. Therefore all the logic is basically handled by the clients and shared across them.

Of course this open more options for cheating, but it can be mitigated by stats checks, for example if a player progress too fast you have an high risk of cheating, or simply by adding check code on the client side, which means if there is 1 cheater he will be detected by other players and that will trigger a server information.

Mostly networking is the bottleneck, not the game loop itself. Of course this would depend on heavy you AI and calculations are.
But I see several more problems with the architecture itself:
If the master client is laggy or slow, everyone will experience lags. If your server is the master, only the laggy people would feel the delays (unless you server suffers).
What if the client sends back broken or false information … how will the server respond or deal with that? The master client is active and responding but the data it provides is invalid, this could cause massive problems.

While relocating the master token, you might cause delays. Plus the master client would always be one or more game cycles ahead giving it a advantage.
You shouldn't trust the client with anything... since it's always uncertain how they work/act/respond/delay/time out/...

If you do want to limit the server resources, it would be better to outsource certain tasks to a different server (so you know it will behave correctly). Companies like Google (Google AppEngine) offer free (to a certain extend) cloud space to allow such tasks/architecture. This solution seems a lot more reliable then giving control to clients.

[Jackolantern]

The game loop can be a bottleneck for node.js, since it is single-threaded and node must get in and get out of each handler as fast as possible. Of course, what looks like a ton of code to us, modern processors just laugh at and perform in under 1 ms, but it still can be a concern. While the main server loop is being processed, no networking is being performed, no event handlers are running, etc.

This issue has almost made me wonder if we may see a resurgence in MMO servers made on traditional platforms once JSR 356 hits in JEE 7, and as SignalR picks up steam. Having the ability to use classical threading when needed can be quite an advantage over a purely async platform, even with the complications that come with threading.

[a_bertrand]

Keep in mind the map works in areas of 50x50 tiles. It will not be that a single client will handle ALL the areas as a max of areas a client will have in memory is 9 areas. So worse case scenario is a client which handles 9 areas lags and the monsters on those areas will react slowly. Something can be done and the master could be moved to somebody else. I don't believe it's such a difficulty.

For the not trusting the clients, it's true, in principle you should never trusts the clients, yet if you design your game as nearly a P2P design, you can have as many "monitors" or "checks" as you have clients. So if somebody hacks into the code, any other players can see it. It's unlikely that all the clients will be hacked at the same time, right?

For could services like Amazon or Google, first check their prices, you will soon see it can grow to very high numbers. I prefer to start with something I control instead of having some sort of black hole for my finances.

[Jackolantern]

I have been a bit wary of those cloud development platforms as well. A couple of them sound pretty cool, but the prices are quite high.

[Darius]

I've never worked with Node.js.
But instead of creating threads, you could make different applications/processes 'for each thread'.
A process to handle the requests and then pass it through to other processes (several options on how to pass the information). Then pull the game model/game objects, it needs from the process which holds all the game information and send that back to the client.

I do agree it causes extra overhead but it also allows a lot more flexibility.

[a_bertrand]

Of course that could be done in one form or the other, but I'm not sure you will really gain from it. The only advantage is that if you use some protocol like SOAP or others between the different process then you could split the load on multiple servers. Yet honestly I doubt it is a good design for a relatively small game, at least at first. It's usually better to start simple, and then think about solutions once you have a problem because if you start too complex your architecture may start to be difficult to debug / deploy and you may end up never releasing anything.

[Jackolantern]

The issue isn't with actually creating the threads, but with synchronizing them, an issue that is still there with multiple processes interacting. If a process isn't "atomic" (meaning it is completely carried out in 1 command), the state of the data it is working on can change during the operation. For example, process A checks to see if player1's health is under its max of 250, and if it is it increments it by 5. Process A checks it and it is 245. But in between the checking and the addition, process B added 5 to player1's health, but process A doesn't know that and adds 5 as well. Now player1's health is above its max at 255.