smartfoxserver.com

If I use a server instance to run as many of the same game as it can handle.
Lets say for argument sake that each server can handle 20k users and the games are 2 player meaning I'll be running 10k rooms...

Does it matter if all 10k rooms run in the same zone or is it better to break up into many zones?

There is no reason from a game code perspective and we haven't discussed chat functionality yet. Thought I saw something about maximum number of rooms per zone but I can't seem to find it.

Hi,
Rooms are lightweight objects so their number is not a problem.
When designing an application that will require so many rooms it is good to think about Extension architecture a bit.

Attaching a Room Level Extension to each on of the 10k rooms will generate 10K instances of that extension, so you will need to have at least 1-2Gb of free RAM at your disposal, I would say.
In this case using Java for the server side code would be highly recommendable

Does it matter if all 10k rooms run in the same zone or is it better to break up into many zones?

One problem I foresee is the default room list size.
If you are familiar with the SFS client side API you know that the client gets the room list from the server right after having logged into the zone.

A list of 10K rooms will be pretty big, plus anyone will be overwhelmed by the amount of rooms available and find it difficult to choose one among so many.

If these 10K rooms handle different games it would make sense to have each game played in a different Zone.
If this is not the case you should probably avoid to send the whole room list to the client, instead you could send a stripped down version of it. (*)
Or you could implement your own game matching system and again avoid to send the full list of rooms.

Hope it helps

(*)= it can be easily done by sending a custom message to the client that uses that same format of the room list server response

Thanks Lapo,

Ram is no problem and I am using Java so we should be ok there.

If these 10K rooms handle different games it would make sense to have each game played in a different Zone.

Each room will handle the exact same game and as a matter of fact we will likely use more than one server instance (terracotta) in production to handle the volume of games we expect.

Or you could implement your own game matching system and again avoid to send the full list of rooms.

Thats exactly the model I'm working on.

User logs in to the zone (custom login) and immediately sends a request to the zone extension for a list of games(rooms). I plan on returning only a hundred.

One idea I'm working on since the game is a real time design, is maybe having the client spend a few seconds checking its round trip time. In this way I might be able to group like latency's together for a better experience.

As far as the extension architecture I would love some feedback.

The server side game logic requires an update tik on a 30 ms timer. I realize that if each room extension was to create a timer task than I think I'm looking at 10k threads which will be no bueno.

The scenario that I'm exploring is to instance a timer task class called Game Manager from the zone extension. I imagine having like 20 Game Manager instances, each responsible for running 500 or so games.
20 threads - no big deal right?

The timer task would be scheduled to run() every 30 ms. The run method will loop through it's game list and call an update() method on each room extension using the handleInternalRequest() function.

Do you foresee any issues with this model?

The only other way I thought about doing this was to instantiate a simple class as the game entry and call an update method directly but then I would have to keep track of the room/class pairs and write a snarly message router in the zone extension. ugly.

I appreciate your feedback very much. We just purchased a license for the development box and anticipate needing more copies as we go along.

Hi,

User logs in to the zone (custom login) and immediately sends a request to the zone extension for a list of games(rooms). I plan on returning only a hundred.

Ok. Just make sure to create a "landing room" of type Limbo before that. Just-logged-in users are not yet allowed to call extensions, they first need to join a Room.
Limbo Rooms are specifically designed for these types of preliminary tasks such as consulting/search a database of users, registering profiles, setting up one's character etc...

One idea I'm working on since the game is a real time design, is maybe having the client spend a few seconds checking its round trip time. In this way I might be able to group like latency's together for a better experience.

Good idea. The lag monitoring could also go on during the game if you need to adjust any client side parameter according to it.

The server side game logic requires an update tik on a 30 ms timer. I realize that if each room extension was to create a timer task than I think I'm looking at 10k threads which will be no bueno.

30 ms is quite ambitious as it requires that the client has a lag <= 30ms
While this is certainly possible most users are likely to have have a lag time of 50-100ms, so you should probably tune your game for these timings.

50-100ms is still considered good, while 150-200 starts to get bad for real-time as you can get 5-7 updates per second.

As regards the 10K threads... I agree, no good. You would kill even the most performing JVM in a few seconds

I would simply recommend using an ExecutorService backed by a thread pool and shared across all Room extensions. (Java 5 provides a great choice of thread pools)

You might also consider to keep the game logic at Zone Level and govern each game for that Zone in a central place. While it might add a 10-15% extra code it would probably also optimize the general performance quite a lot and simplify the approach to the global thread pool.

The scenario that I'm exploring is to instance a timer task class called Game Manager from the zone extension. I imagine having like 20 Game Manager instances, each responsible for running 500 or so games.
20 threads - no big deal right?

Probably the centralized game logic would simplify this as well.

Hope it helps

Great feedback - Thanks!

I'm definitely looking in to the ExecutorService and thread pools. I'm a bit new to Java so I'm handling a learning curve on that as well here.

You might also consider to keep the game logic at Zone Level and govern each game for that Zone in a central place.

This sounds a bit like my original scenario where I govern each game by instantiating a new game class instead of a room extension.

Are you suggesting not even using game rooms?

Is this method better and faster than room extensions?

All client messages would be handled by the single zone extension than and I would have route those accordingly - obviously

This would be better than sending messages directly to the room extension for that game room?

More than happy to write 20% more code for performance gains.

Are you suggesting not even using game rooms?

Nope, gameRooms are necessary to group players into separate logic areas of the server. So this is required.

The idea I am suggesting is that the game logic resides in the Zone Level extension. At Zone Level you get events for each Room belonging to that Zone, so you govern them all.

This means that instead of keeping the state of each game in its relative Room-Level extension you avoid instantiating all those copies of the same game logic, you keep that logic in a central place (Zone-Level) and you are still free to store the game state in each Room.

In fact each Room object exposes a properties object (of type java.util.Map) which can hold all your game state.

I would suggest to take a look at this 2 part article which has some other tips on application architecture: http://www.smartfoxserver.com/docs/docP ... mmo_p1.htm

Nope, gameRooms are necessary to group players into separate logic areas of the server. So this is required.

Thats kinda what I thought.

you avoid instantiating all those copies of the same game logic

Is the concern here related to memory or performance?

Is the concern here related to memory or performance?

Mostly memory usage