In this new recipe we will take a look at how to optimize the Room List that SmartFoxServer 2X sends to each client.

Room Lists are very important to show players what is going on in the server and allow them to quickly find games to join. Sometimes, however, they can get too big and result in a waste of bandwidth and information overload for clients.

» Room Lists in a nutshell

SmartFoxServer 2X sends the Room List to clients once, in response to a successful login event. After this it only sends updates related to changes in the list which include: a Room being added or removed and any change in the count of players and spectators in any Room.

While this may sound like a lot of updates, especially in high traffic situations, the actual update packets are pretty small, in the order of 30 bytes and the SmartFoxServer API offer a number of tools to fine tune how all these events are generated.

» Fine tuning the contents of the Room List

The first and most important aspect of the Room List is deciding which Rooms the player will be able to see when he logs in the system.

SmartFoxServer 2X provides a convenient way for categorizing Rooms in different Room Groups. If you’re not familiar with the concept, we highly recommend that you take a look at our “Room Architecture” article in main documentation website.

The purpose of Groups is to segregate different types of Rooms (for example all Poker Rooms, from all Lobby Rooms) so that users can just see one portion of the full Room List, based on their current activity.

For example, if your server hosts a number of different games there’s no need for players interested in playing Game A to see and receive updates for all Game B Rooms. Instead clients can dynamically subscribe and unsubscribe to Room Groups according to their interest, thus avoiding to deal with huge Room Lists.

The first thing to configure is your Zone’s “Default Groups” setting, which specifies which Room Groups are going to be auto-subscribed upon login by any User.

To do this open the AdminTool > Zone Configurator and edit the field making sure only the Groups that are strictly needed are subscribed to. If your application doesn’t require Users to see any Rooms when they have just logged in, you can leave the field empty.

» Fine tuning Room Events

Once the User is subscribed to one or more Room Groups he will start to receive a number of events that can be tweaked in several different ways.

• ROOM_ADD: notified when a new Room has been created in any of the subscribed Groups
• ROOM_REMOVE: notified when a Room is destroyed
• ROOM_VARIABLES_UPDATE: notified for RoomVariables that have the “global” flag turned on
• USER_COUNT_UPDATE: notified every time the user and spectator count of a Room changes

The first two events (ROOM_ADD / ROOM_REMOVE) are mandatory: they represent the essential mechanisms by which the Room List is kept synchronized with Users. There’s not much we can tweak for these two: we either receive them or not, and this is based on the choice of subscribing/unsubscribing to a specific group.

ROOM_VARIABLES_UPDATE is a different beast: normally Room Variables are only visible to the Users that are joined in a specific Room. People from “outside” don’t see the variables and don’t receive any updates.

Additionally, RoomVariables can be marked as global which makes them visible from outside without the need of joining the target Room. This can be useful to provide extra information to players before they choose which Room they want to join. This however has a small cost: every global Room Variable update is dispatched to all people subscribed to the Room Group.

We highly recommend to keep this in mind when working with global Room Variables, especially if they are intended for very frequent updates, as this may potentially use significant resources.

Finally we have the USER_COUNT_UPDATE event which keeps everyone in sync about the number of players and spectators in every Room. In high traffic situations these events can be generated every few milliseconds causing a lot of small packets to be sent continuously to all clients.

To optimize this event, SmartFoxServer provides a specific User Count Event Throttler which allows the system to aggregate multiple updates at specific intervals before sending them. This way we can save significant bandwidth at the cost of a slightly “less real-time” user count updates (which is usually acceptable).

By default we recommend to set the Throttler to 1000ms. The setting is per Zone and it can be changed from the Admin Tool > Zone Configurator, under the Advanced tab.

» Working without Room Lists

There is one last interesting concept that is also worth discussing, which involves avoiding Room Lists altogether. A number of games and applications may not require that the client knows about the details of every Room available, at all.

The Room List is essentially needed only when the joining process is left to the User entirely, but there are many scenarios in which the server side logic will decide where to join the players instead.

Let’s explore a simple use case:

• We have one main Lobby Room where all Users are joined as soon as they log in. We don’t need to know about any other Room from client side, because the joining will be done on the server side.
• A number of Game Rooms are available.

In this scenario we don’t need Room Groups and we can avoid sending any Room List related data to the client. To do this we simply leave the Zone’s “Default Room Groups” setting empty.

NOTE: even without a local Room List clients can still join Rooms from their side if they know the name of the target Room. If you want to completely remove the possibility for clients to send JoinRoom requests you will need to inhibit the functionality from the Permission Profiles.

You can learn more about it in this documentation page

» Conclusions

To recap, there are a number of strategies we can employ to optimize the traffic generated by the Room List and it’s related updates:

• Use Room Groups to your advantage by separating Rooms in different categories.
• Make sure the player only subscribes to the Room Groups that he needs to see in his/her current state.
• Unsubscribe to any Room Group that is no longer required by the application.
• Tread lightly with global Room Variables, they can be useful if used sparingly.
• Configure the USER_COUNT throttler to a default of 1000ms or higher to avoid excessive user count updates.
• When possible, move the Room joining logic on the server side and avoid subscribing to too many Room Groups or avoid the Room List altogether.