(For more resources on Flash and Games, see here.)
A lobby, in a multiplayer game, is where people hang around before they go into a specific room to play. When the player comes out of the room, the players are dropped into the lobby again.
The main function of a lobby is to help players quickly find a game room that is suited for them and join.
When the player is said to be in a lobby, the player will be able to browse rooms within the lobby that can be entered. The player may be able to see several attributes and the status of each game room. For example, the player will be able to see how many players are in the room already, giving a hint that the game in the room is about to begin. If it is a four-player game and three are already in, there is a greater chance that the game will start soon. Depending on the game, the room may also show a lot of other information such as avatar names of all the players already in the room and who the host is.
In a car race game, the player may be able to see what kind of map is chosen to play, what level of difficulty the room is set to, etc. Most lobbies also offer a quick join functionality where the system chooses a room for the player and enters them into it.
The act of joining a room means the player leaves the lobby, which in turn means that the player is now unaware or not interested in any updates that happen in the lobby. The player now only receives events that occur within the game room, such as, another player has entered or departed or the host has left and a new host was chosen by the server.
When a player is in the lobby, the player constantly receives updates that happen within the lobby. For example, events such as new room creation, deletion, and room-related updates. The room-related updates include the players joining or leaving the room and the room status changing from waiting to playing.
A sophisticated lobby design lets a player delay switching to the room screen until the game starts. This is done so as to not have a player feel all alone once they create a room and get inside it. In this design, the player can still view activities in the lobby, and there's an opportunity for players to change their mind and jump to another table (game room) instantaneously.
The lobby screen may also provide a chatting interface. The players will be able to view all the players in the lobby and even make friends.
Note that the lobby for a popular game may include thousands of players. The server may be bogged down by sending updates to all the players in the lobby. As an advanced optimization, various pagination schemes may be adopted where the player only receives updates from only a certain set of rooms that is currently being viewed on the screen.
In some cases, lobbies are organized into various categories to lessen the player traffic and thus the load on the server. Some of the ways you may want to break down the lobbies are based on player levels, game genres, and geographic location, etc.
The lobbies are most often statically designed, meaning a player may not create a lobby on the fly.
The server's responsibility is to keep track of all the players in the lobby and dispatch them with all events related to lobby and room activity.
The rooms that are managed within a lobby may be created dynamically or sometimes statically. In a statically created room, the players simply occupy them, play the game, and then leave. Also in this design, the game shows with a bunch of empty rooms, say, one hundred of them. If all rooms are currently in play state, then the player needs to wait to join a room that is in a wait state and is open to accepting a new player into the room.
Modeling game room
The game room required for the game is also modeled via the schema file (Download here-chap3). Subclassing should be done when you want to define additional properties on a game room that you want to store within the game room. The properties that you might want to add would be specific to your game. However, some of the commonly required properties are already defined in the GameRoom class. You will only need to define one such subclass for a game. The following are the properties defined on the GameRoom Class:
Name of the game room typically set during game room creation
The server keeps track of this value and is set to the current host of the room. The room host is typically the creator. If the host leaves the room while others are still in it, an arbitrary player in the room is set as host.
Is maintained by the server similar to host name.
Should be set by the developer upon creating a new game room.
The server keeps track of this value as and when the players enter or leave the room.
Max player count
Should be set by the developer upon creating a new game room. The server will automatically reject the player joining the room if the player count is equal to the max player count
The possible values for this property are GameConstants.ROOM_STATE_WAITING or GameConstants.ROOM_STATE_PLAYING
The server keeps track of these value-based player actions such as PulseClient.startGame API.
The possible values for this property are value combinations of GameConstants.ROOM_TURN_BASED and GameConstants.ROOM_DISALLOW_POST_START
The developer should set this value upon creating a new room. The server controls the callback API behavior based on this property.
A server-reserved property; the developer should not use this for any purpose.
The developer may inherit from the game room and specify an arbitrary number of properties. Note that the total number of bytes should not exceed 1K bytes.
Game room management
A room is where a group of players play a particular game. A player that joins the room first or enters first is called game or room host. The host has some special powers. For example, the host can set the difficulty level of the game, set the race track to play, limit the number of people that can join the game, and even set a password on the room.
If there is more than one player in the room and the host decides to leave the room, then usually the system automatically chooses another player in the room as a host and this event is notified to all players in room.
Once the player is said to be in the room, the player starts receiving events for any player entering or leaving the room, or any room-property changes such as the host setting a different map to play, etc. The players can also chat with each other when they are in a game room.
Seating order is not required for all kinds of games, for example, a racing game may not place as much importance on the starting position of the player's cars, although the system may assign one automatically. This is also true in the case of two-player games such as chess. But players in a card game of four players around a table may wish to be seated at a specific position, for example, across from a friend who would be a partner during the game play.
In these cases, a player entering a room also requests to sit at a certain position. In this kind of a lobby or room design, the GUI shows which seats are currently occupied and which seats are not. The server may reject the player request if another player is already seated at the requested seat. This happens when the server has already granted the position to another player just an instant before the player requested and the UI was probably not updated. In this case, the server will choose another vacant seat if one is available or else the server will reject the player entrance into the room.
(For more resources on Flash and Games, see here.)
The room may be said to be in one of two states:
In case of a dynamically created room, the room is said to be in a wait state upon creation. This state signifies that the game has not begun yet. In the case of a statically created room, all rooms start out in this state. This is also the time when other players may join the room. During the wait state, the host may still be allowed to change the room attributes, such as the difficulty level, or depending on the game developers' preference, the room properties are all set when the player is in the process of creating the room. The room goes into a play state when the host broadcasts a start message to all the players.
As you can see from the illustration, the room is created in wait state, and goes into play state when the game is started. The room object will be purged in case of a dynamically created room. The room is usually purged when all the players in the room leave.
The host may decide to start the game at any time, except for games that must have a minimum number of players. For example, a card game may require at least four players to start or a game of tic-tac-toe may need at least two players to start. In the case of racing game, the host may wait for as many players as he or she wishes. The server will prevent more than the maximum number of players from joining.
As with rooms, the players within the game room may also be in one of the following two states:
- Not ready
Once the player has joined the room, the player usually starts out in the Not Ready state and each player may have to set the state to ready. The game may not start unless every player in the game room has set their state to ready. The player may change their state before the game starts. Some games force the player to be ready and are allowed to change the state. It is usually in good intention of the game developer to give players a chance to ready themselves before the game starts. But most often, it does happen that a player forgets to click the button to set themselves as ready, or even may simply leave the computer without closing the game leaving the player hanging in the game room. The flip side is also the reason why some games expose this feature, meaning you only want to play with people that are active at the computer playing the game. When a game round ends, the server sets the player's status back to "not ready" and the player must actively choose to go into the ready state. Failing to do so, the host or other players assume that the player has left the computer physically leaving their avatar hanging in the game room. In this case, we need to kick these players out of the game room.
Kicking out a player
There are various reasons that you want to kick a player out. Sometimes it is not pleasant and sometimes it simple is a necessity.
The player may be kicked out when the room is in the wait state, that is when the game has not started yet. You might want to kick someone out of the game room because the player is using foul or offensive language during chat. Or it could be that a player for some reason has not set the status to ready. In such events, the host has the power to initiate a kick-out process. Another reason might be that the host wants the room to have challenging players so as to make each game round as interesting as possible. There could be several ways or policies to kick someone out:
Anarchy being not much of a policy where anyone may kick anyone else, this method usually becomes destructive and is not recommended to implement. In the Imperial policy, only the host has the right to kick someone out; this policy is also quite easy to implement. Diplomatic, the third policy, is quite common in a lot of multiplayer games. The host may get a consensus from all the players, except from the player that is being kicked out. It happens in three steps:
- Host initiates a kick-out—may state a reason.
- Players receive the notification—may agree or disagree.
- The player is kicked out if all players agree.
If everyone agrees, then the server forces the kicked-out player out of the room and into the lobby. The host may also optionally give a reason as to why somebody is being kicked out. The other players would usually have a dialog window that comes up with a countdown timer. The player has a choice to say yes or no to kick the player out, and if the player does not respond, then the default response is a yes to the kick out. It is very rare that an implementation allows even for a host to be kicked out.
Room types define the behavior of how the game is played within the room and additional policies for players entering the room. The following are a few attributes that define a room type and are not mutually exclusive:
- Password protected
Password protected is a very common implementation where the host creating the room may set a simple password on the room. Only players knowing the password can enter into it. The password is then given out to friends via private chat or even an external instant messenger.
Turn-based, is where, in a game each player takes a turn to make their move. When the game starts, the host or a player at random is chosen to play first. It could be determined by last round's winner or loser. The turn then goes round the table in the seating order, either in clockwise or counterclockwise direction. The turn management is typically controlled by the server; it notifies the corresponding client when it's their turn. The turn is usually controlled by a countdown clock, when it goes to zero, either a default move must be implemented by the game developer on behalf of the player, or if the game rules allow, the player's turn could also be considered a pass. Some games may also allow any random player to call in when it is not their turn. This means the player may request the server to skip all other players, making it the players turn. If two player's call for a turn simultaneously, the server arbitrarily chooses one.
An open room is rare but typically allows players to join the game room even after the game has started. For example, in a game like multiplayer jigsaw, you could allow new players to join no matter how much the game has progressed. Of course, a maximum number of players would still be enforced.
Audience is a non-playing avatar inside a game room. An audience can join in the room at any time even when the game has already begun. Depending on the game, the audience may simply observe or may encourage a certain player who is playing the game. This feature is a great opportunity for novice players to learn from expert players in a game of chess or Go, for example.
The audience game screen may look identical to that of the players actually playing the game. For example, in a game of chess, an audience would view pretty much the same screen as that of a player. But in a racing game, the screen may look completely different. For example, the actual players may see the screen as though they were driving the car, whereas the audience may see the game as a top-down view, showing the current positions of all players on the track.
In addition to room states and type, there are numerous other things that are needed to keep track of for each instance of a room:
- Maximum players
- Current player count
- Member player names and summary
- Game host name
The above list is a generic list of properties that players browsing the rooms would want to know before joining the room. But there's a lot of game-related information that a game developer may expose to the players, giving them the choice to and thereby maximizing the fun while playing the game.
In this article, we learned about game lobby and game rooms, the management of which is essential for any multiplayer game.
In the next article we will cover The Lobby and New Game Screen Implementation.
- Flash 10 Multiplayer Game: Game Interface Design [Article]
- Flash 10 Multiplayer Game: The Lobby and New Game Screen Implementation [Article]
- Flex 101 with Flash Builder 4: Part 1 [Article]
- Working with Drupal Audio in Flash (part 1) [Article]
- Flash Video Encoding, Skinning and Components in Wordpress [Article]
- Joomla! with Flash: Flashy Templates, Headers, Banners, and Tickers: Part 1 [Article]