Page 1 of 1

Limbo vs Regular room for more complicated Lobby?

Posted: 12 Apr 2011, 23:09
by Sarevok
Hi everyone. I am currently designing a classic turn based "lobby with rooms" game with some specific features in mind, so I have few questions.

When user log in, he will enter the lobby, and will be notified about the game rooms currently present in that lobby. He should be able to see new rooms when they are created in the lobby, as well as he shouldn't see them when they are destroyed. So far so good - it is job that can be handled with limbo room type, because it process events onRoomAdded and onRoomDeleted.

But I need one more feature - I want users who wait in lobby to see changes in some of the room properties (for rooms that belong to that lobby of course). For example, I want them to see current number of users in each game room, and I want him to be notified when number of users change.

For this type of requirement limbo room is not enough, because it doesn't receive joinRoom/leaveRoom events. I have two solutions for this problem in mind:

a) I could use regular room type for lobby, and process joinRoom/leaveRoom events in internal event handler (in extension assigned to lobby room). From there I could send updated room list to all users that are currently in lobby. This should work if regular room extension (assigned to lobby) receives joinRoom/leaveRoom events for all rooms in the zone. If that is not the case, then this solution will not work.

b) I could poll from client side on every 30 seconds (or so) for game room list if client is in the lobby. That way client would have relatively updated room info. Frankly, I don't like this solution, because it's not elegant, and I hate polling as idea :) Not to mention possible security consequences...

So my question is: Would solution a) work in the first place? If it will work, what do you think is better way to achieve wanted result performance wise? Do you have any other ideas how to solve given problem?

Thanks in advance!
Sarevok

p.s. I could use zone level extension to achieve solution described under a) but I hope I can avoid that :)

Posted: 13 Apr 2011, 06:46
by BigFIsh
How about this solution:

- Keep to your original design as first described.
- Get the server to send room count updates to every client every 30 seconds or so. It would be best if you use a graphical indication of how 'full' each room is, so that you don't have to worry too much about the accuracy of the room count.
- Get the client to send a 'join room' command using sendXtMessage. Validate the join on server side. If full, send a response back to client saying "Room is full" - and update the room count for that room. If not full, join the client to that room.

If you want to take it further, get the server to keep track of the previously sent room count for each room. That way, when sending the room count updates to each client - only send 'required' updates.

There are other ways to tackle this problem. i.e. request for update from client side, or even only request for updates for visible rooms (that the client can see on screen).

Posted: 13 Apr 2011, 12:49
by Sarevok
Thanks for answer :)

I have one more unrelated question. I saw you guys mention to set debug mode to true on client side, to help you in debugging. I use .NET API as client side, but when I set debug mode to true I don't see any additional information.
In other words, how do you access to that information (in visual studio for example)?

Posted: 14 Apr 2011, 06:23
by BigFIsh
It should appear in 'output' console.

Are you setting the debug mode by doing something like this:

Code: Select all

var smartFox:SmartFoxClient = new SmartFoxClient();
smartFox.debug = true
?

Posted: 14 Apr 2011, 15:44
by Sarevok
No, I pass true flag to the constructor, like this:

Code: Select all

SmartFoxClient smartFox = new SmartFoxClient(true);
I will show you my debug output for simple client. When I start application I have following steps:
1) connect to server
2) log in - if username/pass is ok, server joins me in main lobby, and send me room list
3) join some other lobby from the list
4) request from server available rooms - and server sends them back

This is the debug output for the above application, when debug flag is set to true:

The thread 'vshost.LoadReference' (0x1234) has exited with code 0 (0x0).
'SmartFox1.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\D\documents\visual studio 2010\Projects\SmartFox1\SmartFox1\bin\Debug\SmartFox1.exe', Symbols loaded.
'SmartFox1.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\D\documents\visual studio 2010\Projects\SmartFox1\SmartFox1\bin\Debug\SmartFoxClient.dll'
'SmartFox1.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'
The thread '<No Name>' (0x1328) has exited with code 0 (0x0).

****************************************************************
Warning:
The room list is empty!
The client API cannot function properly until the room list is populated.
Please consult the documentation for more infos.
****************************************************************

In some other posts on forum, people mentioned that you can actually see if messages are being sent from client to server by using this debug mode, but I cannot see anything like that in above debug output :)

Posted: 14 Apr 2011, 21:14
by BigFIsh
Look like it's not working.

Are you using an external config.xml file (that defines the zone, ip, port etc)? If so, check if it contains the debug tag.

Posted: 15 Apr 2011, 10:59
by Sarevok
I use config.xml on server side. It has following section in it:
<!-- Allow remote debugging of extensions -->
<ExtensionRemoteDebug>true</ExtensionRemoteDebug>

<!--
Allow global autoreload of extensions upon file save
You should specify in each Zone if the autoreload is enabled.
-->
<AutoReloadExtensions>true</AutoReloadExtensions>

<ExtensionRemoteDebug>true</ExtensionRemoteDebug>

Posted: 16 Apr 2011, 00:39
by BigFIsh
I meant the client's config.xml file. This is an example of such file:

Code: Select all

<SmartFoxClient>
	<ip>127.0.0.1</ip>
	<blueBoxIpAddress>127.0.0.1</blueBoxIpAddress>
	<port>9339</port>
	<blueBoxPort>8080</blueBoxPort>
	<zone>Hello</zone>
	<debug>true</debug>	
</SmartFoxClient>
Which is loaded at runtime via the smartFox.loadConfig() method. This is just one of the approach for defining zone/ip/port etc. Note the <debug> tag.

Posted: 16 Apr 2011, 11:07
by Sarevok
No, I don't use config files on client side.
Can you send me some simple visual studio application and corresponding server extension, where debugging works on your machine?

If it wouldn't work for for me, then I will probably need to get another client API.

Posted: 18 Apr 2011, 13:43
by ThomasLund
If you run your environment in Unity, you will get the debug output in the editor.log or player.log and not in the Unity console.

You can either pass the boolean in the constructor or on the SFS client instance. Should be the same effect.

One thing you might want to do is to add a callback for the debug messages inside your client. If I recall its called OnDebugMessage (from memory)

/Thomas

Posted: 26 Apr 2011, 18:13
by Sarevok
Thank you very much. I don't use Unity, I use pure VS2010 environment for client prototyping. I managed to solve the problem by following your advice to use onDebugmessage callback. It seems like client API redirected debug messages somewhere else instead to debug output of VS2010. To make it work, you need to use onDebugMessage callback so you can manually redirect debug message where you want them (in my case VS debug output window):

Code: Select all

        SFSEvent.onDebugMessage += OnDebugMessage;

        ...

        public void OnDebugMessage(string msg)
        {           
            Debug.WriteLine(msg);
        }

p.s. sorry for my late response.

Posted: 27 Apr 2011, 06:31
by ThomasLund
Super - happy it worked for you