Receiving game properties in lobby?

edited September 2012 in Native
I've read that game properties in a room will not be accessible in the lobby unless the key value is specified with the CreateRoom() function. Now, I am using Marmalade with C++, and I do not see a CreateRoom() function, only opJoinRoom() which is used to create/join rooms.

How can do I specify which room properties are accessible from the lobby when I create my room? Currently I am creating the room like so:
	ExitGames::ValueObject<ExitGames::JString> roomNameObj = ExitGames::ValueObject<ExitGames::JString>("game name");
	ExitGames::ValueObject<ExitGames::JString> lobbyNameObj = ExitGames::ValueObject<ExitGames::JString>("Games_lobby");
	ExitGames::Hashtable hash;
	hash.put(ExitGames::KeyObject<byte>(255), roomNameObj);
	hash.put(ExitGames::KeyObject<byte>(242), lobbyNameObj);

	ExitGames::OperationRequest opRequest(255, hash);

And where will the properties be accessible aftwards? I would assume via the Room List update event (code 251).

Any help would be appreciated as I can find no other resource for this problem.

Comments

  • Obviously you are using class LitePeer, which is the client side API for the server side Lite application. Lite does not know the functionality of an explicit createRoom, but will create the room, when the first client wants to join it.

    The feature of game room properties being visible in the lobby is a feature of the LoadBalancing application and not supported by any other application.

    The client side equivalent for the server side LoadBalancing application is the LoadBalancing namespace. Class LoadBalancing::Client offers the function opCreateRoom(), for which you are looking for.
  • Ok, thanks, your advice has started me in the right direction. The only thing I am not understanding about the LoadBalancing app, is how I will get a list of players in a lobby. I was previously doing this with the LiteLobby application by setting the lobby's P_ACTOR_PROPERTIES and check them on OPC_RT_GETPROPERTIES.

    Is something like this possible with LoadBalancing? I haven't been able to find any way to set the lobby properties.
  • This currently isn't implemented out of the box. However you can of course instead of connecting to LoadBalancing connect to your own server side app that inherits from LB and implement this feature in the subclass.
  • Ok, so I'm just now trying to think of what the simplest alternative is. Thank you very much for your help so far.

    With the LiteLobby server application, is there no way to transmit any information from the room to the lobby? For example, how would one handle a game with a player limit from the lobby? It would seem that a peer in the lobby would have no way of knowing if there are available slots open in the room. Is this not supported out of the box? If not, I suppose I will just have to extend the server app as you suggested.
  • The Lobby in LiteLobby is just another room with some different settings than the gamerooms and LiteLobby does not offer any inter room communication out of the box. The gameservers in LB route room properties, that have been explicitly specified to show up in the lobby through to the master server, which is then providing them in the lobby.
    LB also offers a maxPlayers feature, which LiteLobby doesn't. So with LiteLobby you would have to implement the maxPlayers feature and then also implement the feature of gamerooms updating the lobby with this information yourself.

    If I would be in your situation I would go with LB and extend its lobby implementation to provide the list of players. There are 2 reasons, why I would prefer this over extending LiteLobby instead:

    1. In LB you just have to add functionality inside the lobby and can probably do this by just copying over the according code from the game rooms, which already provide the functionality you wish for. In LL on the other side you have to add functionality, that is not inside a room, but between rooms, which will be more complex (you could have a look at how LB does this, but as LB is interserver and LL is not, this probably won't be that helpful).

    2. As already mentioned, LB supports multiple game-servers, while LL does not. You can still just run the masterserver and a single gameserver and you can even run both on the same machine, as long as you don't have the player base to need multiple physical servers, but in case that you suddenly need more gameservers, you can just get them online in minutes and do not even have to put the master or already running gameservers offline therefor, while LL is single-server only, so that in case that you need more hardware power than a single server can handle, you would have to port your game to LB anyway later.
    If multiserver support is relevant for you of course depends a lot on the amount of players that you expect to have overall and that you want to support per room and on the costs of your serverside game logic.
    On an average single server hardware Photon supports multiple thousands of concurrent users (As a rule of thumb you can count with 1 CCU for every 10 daily active users, with 1 CCU for every 100 monthly active users or with 1 CCU for 200 downloaders of your game.) as long as you just have a few player per room like 4 (however you should account for player count peaks, that can be far above the average of your game).
    If a relevant amount of the interroom communcation goes to multiple players in the room, then you have to also account for the fact, that the increase of traffic in a room will be about the square-product of the amount of players inside, so very big rooms will decrease the amount of players, that the serve can handle, drastically.
    Futhermore some kinds of serverside custom game logic can have a huge impact on the amount of players, that a single server can handle. For example if you want to run a physics engine on the serverside, that needs 3% of the calculation power of your clients, then with just 100 players the server would already need the calculation power of 3 of your clients just for the physics.
Sign In or Register to comment.