Sample code for Distributed Lobby System is a sample online game program.
Sample code for Distributed Lobby System supports the generally needed functions for distributed server structure of online game. For example, it provides character creation, game lobby and etc.
Sample code for Distributed Lobby System has various development tips for making a small or massive scale multiplayer online game.
Features
Practical examples of making “logon”, “create a character”, “chat in lobby”, “create a session”, “join a session”, “host a game”, “game over” and etc.
These are basically designed for learning purpose but show how you can handle game data loading, user leaving the game during loading, interaction between host and other members and etc.
This is an example structure of distributed server utilizing ProudNet and ProudDB. It is also equipped with functions that maintain the lobby system which performs the distribution to several severs and game session (or dungeon instance) that load-balances between servers.
The casual sample 2 is a simple bullet avoiding game. You can control the air-plane by pressing your arrow keys and catch some items. The blue bullet is the moving bullet to upper side, the red bullet is the moving bullet to down side. You can move your air-plane by pressing the space bar key
Sample codes for Distributed Lobby System are as followed.
ProudNet : Server and Network
Part VIII. [For version 1.6 only]LAN communication between servers
How to run Sample code for Distributed Lobby System is guided in 6.1 How to use Casual Game Sample
The server structure of Sample code for Distributed Lobby System is explained in Distributed server of sample casual game 2.
Sample code for Distributed Lobby System has a vast amount of source codes (annotations alone exceed 8000 line). Thus it is recommended to refer on API reference of sample codes for better understanding.
API references of this sample code can be found at <Installed folder>/ProudNet/doc/CasualGame2.chm.
Whenever you have questions about Sample code for Distributed Lobby System, please contact us at Part XIV. Nettention Technical Support.
In case the samples of casual game system guided in Sample code for Distributed Lobby System are not suitable with the project you are developing, we recommend you build your game from scratch as just referring to Sample code for Distributed Lobby System.
Of course you can develop a casual game by editing Sample code for Distributed Lobby System but this would be very troublesome when updates take place in ProudNet and you end up searching for the update contents every single time. Therefore, it has suggested to branch out your source using your Source Control.
The practical use of functions guided in Sample code for Distributed Lobby System are as followed.
6.1How to use Casual Game Sample
First, install Creating a sample database
Next, run the server program.
Please check the version of SQL server installed in your computer. Depending on the version, you may need to edit DBMS link string as followed. You can find DBMS link string in CFarmSettings::CFarmSettings method of GCServer.
m_dbmsConnectionString = L"Data Source=localhost;Database=ProudDB2-Test;Trusted_Connection=yes";
Tip : If you are using the MYSQL, please see 'Sample/ SimpleAdoMysql'
Create Table and Procedure in DBMS by running .sql that located in Sample-schema folder depends on version of DBMS
You can build GCServer for server program. When you run execute file that created in previous step, it works like farm server. And farm server will run one Entry server and several lobby servers, battle server continuously once farm server is executed. This sample will show, it has distributed server structure.
If you want to in charge with each server’s role on one process for easier debugging server program then just put “-debug” as running parameter.
Now, let's run the client program.
The client program gets generated when building GCClient.
When you run the client for the first time, it will prompt a window that requires your entry of server address, gamer ID and password. Type in your gamer ID and password then click on [Connect] to connect to the server. This sample uses stored procedure for gamer authentication but actually it doesn't check the ID and password.
When the client is running, you can create a new playable character or delete an existing character. When your character is selected, click on [Confirm] to select a lobby channel you wish to join.
When a lobby channel is selected, it will show a lobby screen with functionalities of “chat to all”, “create a session”, “join a session”, or “go back to the previous screen”. After creating a session, you can join a game session where you can wait for other players to join or start the game as-is. In order to start the game, every player in the game session must set for [Ready!].
You can control this sample program very easily. You can control your character with arrows and space-bar and get item avoiding bullets on the screen. Blue bullet is moving at the bottom and red is top. You can avoid it with space-bar. Once your character’s point become 0, you will kicked out to lobby and point will reset to 10.
The scores earned by each player get stored in the game database and they will be displayed next to the character's name with [ ] on the game screen.
6.2Distributed server of sample casual game 2
The server inside Sample code for Distributed Lobby System is carefully constructed in deep consideration of scalability in the commercial casual game. And in result, it is distributed as followed.
Farm Server: A server where player can't connect to.
Farm Server works as the central manager for each server. When the farm server is down, all game servers will be shut down all together thus using very simple logics is recommended. Rests of servers that connect to the farm server become the farm clients.
Farm Server has ProudDB Cache Server while Farm Client has ProudDB Cache Client. (Refer to dbc2_server_client)
Farm Server and Entry Server have one-to-one relationship.
Farm Server and Lobby Server have one-to-many relationship. Which means player can select one of lobby channels out of many available.
Entry Server: Entry Server is the first server that player connects to.
It first authenticates the player with inserted gamer ID and password.
Entry Server sends the list of player characters to Entry Client.
And it also sends the up-to-date information of lobby server and each battle server subordinated under lobby server to Entry Client.
Lobby Server : When the selection of player character and lobby channel is done, Entry Client disconnects from the client server, starts preparing the lobby client and connects to the lobby server.
In the lobby server, player can chat with other players in the lobby channel, create a game session, and join a game session.
When the lobby server receives the requests of creating a game session or joining a game session, it searches for the least crowded battle server then asks it to create a session there. And once the game session is created, it sends the information of that game session to the lobby client, which connects to the battle server after disconnecting from the lobby server and preparing for the battle client based on the information it received.
The relationship between Lobby Server and Battle Server is one to many. Which means one lobby channel can have several battle servers and the limit of joinable players in one lobby channel is scalable.
Battle Server: It is a server that manages the game waiting session and actual in-game play. Battle Server can have more than 0 of game session instance.
In this sample, the game waiting session is being managed by the battle server, not by the lobby server. Since the lobby server has a very limited space that can only allow a restricted number of players, it is crucial to maximize the scalability of the server. In consideration of this, this sample is specifically designed to manage everything from the battle server where can even dynamically expand the processing load of the game waiting session.
6.3The relationship between server and client in the game server
At Sample code for Distributed Lobby System, each game server gets distributed by its functionality and communicates between servers. Please refer to 6.2 Distributed server of sample casual game 2 for more details.
When the farm client begins, it attempts to connect to the farm server.
•CFarmClient.Connect
•CFarmServer.OnClientJoin
•CFarmClient.OnJoinServerComplete
When it is successfully connected, the farm starts the authentication procedure.
•CFarmServer.RequestFarmLogon
•CFarmClient.NotifyFarmLogonSuccess
When the authentication is completed, the farm client waits until it gets disconnected from the farm server.
•CFarmClient.OnLeaveServer
•CFarmServer.OnClientLeave
The farm clients are each linked with peer-to-peer communication. So the communication between the lobby server and battle server can persistently occur.
6.4Entry server and client
When game client of Sample code for Distributed Lobby System is running first time, it will create entry client. Then entry client connect to entry server.
•CEntryClient::Connect
•CEntryClient::OnJoinServerComplete
Once logon process is finished, entry client will request registering to entry server or sending encrypted ID and Password as message to logon. Entry server request load information and authenticate gamer to ProudDB cache server that based on collected information.
Logon after registering
•CEntryServer::RequestLoadNewGamer
•CEntryClient::NotifyLoadNewGamerSuccess
•CEntryServer::RequestFirstLogon
•CEntryClient::NotifyFirstLogonSuccess
Logon with current ID
•CEntryServer::RequestFirstLogon
•CEntryClient::NotifyFirstLogonSuccess
Once it succeed gamer authentication and information loading, game client will transform to selecting character form. And it will request local player character list to entry server then receive it.
•CEntryServer::RequestHeroSlots
•CEntryClient::Hero_Begin
•CEntryClient::Hero_Add
•CEntryClient::Hero_End
In this stage, gamer can create or delete local player character. And choose player character. Then entry server will save selected character information to gamer database.
•CEntryServer::RequestAddHero
•CEntryClient::NotifyAddHeroSuccess
•CEntryServer::RequestRemoveHero
•CEntryServer::NotifyRemoveHeroSuccess
•CEntryServer::RequestSelectHero
•CEntryServer::NotifySelectHeroSuccess
Then entry client request lobby channel list to server. Lobby channel list that assigned from entry server contains name of each lobby server, number of concurrent users, and internet address of lobby server. Game client will show list to gamer then gamer can choose one of those.
•CEntryServer::RequestLobbyList
•CEntryClient::LobbyList_Begin
•CEntryClient::LobbyList_Add
•CEntryClient::LobbyList_End
During this process farm client (lobby server at this stage) request exclusive right to farm server. Entry client will be disconnected and removed. Game client will prepare lobby client then try to connect to lobby server. Please refer to 6.5 Lobby Server and Client.
There are possibly occurring problem which is requesting exclusive right when connecting with same ID and Password by DBCache Client of other entry client. After processing of this thing will prevent dividing customfield in parameter that coming from OnDataUnloadRequested callback. In casual game sample2, it will pass exclusive right to newest farm client that requested exclusive right.
6.5Lobby Server and Client
When the connection is successfully made between the lobby client and the lobby server by 6.4 Entry server and client, the game client shows the lobby screen.
•CLobbyClient.Connect
•CLobbyServer.OnClientJoin
•CLobbyClient.OnJoinServerComplete
•CLobbyServer.RequestNextLogon
•CLobbyClient.NotifyNextLogonSuccess
When the data loading for the lobby screen is done, it displays the list of all players, chatting window, and game sessions.
•CLobbyServer.NotifyChannelFormReady
The list of players in the lobby can be expanded, edited and deleted at all time. Such changes in information can be persistently received from the lobby server.
•CLobbyClient.HeroSlot_Appear
•CLobbyClient.HeroSlot_Disappear
The list of game sessions in the lobby can be expanded, edited and deleted at all time. Such changes in information can be persistently received from the lobby server.
•CLobbyClient.GameRoom_Appear
•CLobbyClient.GameRoom_ShowState
•CLobbyClient.GameRoom_Disappear
The actual game session exists in the battle server. The lobby server only acts out a role of sending the list of game sessions synchronized with the battle server to the lobby client.
•CFarmClient.GameRoom_Appear
•CLobbyServer.OnGameRoomAppear
•CFarmClient.GameRoom_ShowState
•CLobbyServer.OnGameRoomShowState
•CFarmClient.GameRoom_Disappear
•CLobbyServer.OnGameRoomDisappear
When a chatting message is sent from a lobby client to the lobby server, it Multicast the chatting message to other lobby clients connected to the server. And, the chatting message that each client received gets displayed in the chatting window.
•CLobbyServer.Chat
•CLobbyClient.ShowChat
Creating a game session
When player requests to create a game session, such request get passed on to the lobby server. Then the lobby server starts searching for the least crowded battle server subordinated to the lobby server and requests to create a session there.
•CLobbyServer.RequestCreateGameRoom
•CFarmClient.RequestCreateGameRoom
•CBattleServer.CreateGameRoomByLobbyServer
The battle server manages the request of a game session creation and sends its result the lobby server. Then the lobby server sends the received information to the lobby client.
•CFarmClient.NotifyCreateGameRoomResult
•CLobbyServer.OnCreateGameRoomResult
•CLobbyClient.NotifyCreateRoomSuccess
Joining a game session
When player requests to join one of already existing game sessions, the lobby client sends the requesting message to the lobby server. Upon receiving such request, the lobby server requests an entry permission to the battle server that contains the game session player selected.
•CLobbyServer.RequestJoinGameRoom
•CFarmClient.RequestJoinGameRoom
When the battle server receives the request of entry permission, it first judges the entry conditions of player then sends the result to the lobby server. Upon receiving the result, the lobby server delivers “success” or “fail” message to the lobby client.
•CBattleServer.JoinGameRoomByLobbyServer
•CFarmClient.NotifyJoinGameRoomResult
•CLobbyClient.NotifyJoinRoomSuccess
When the lobby client receives “success” message for creating or joining a game session, the client also receives the address of battle server and guid of the game session. At this time, the lobby client gets terminated and starts connecting to the battle server after the battle client are created. This process is explained in battle_session. In this process, there are possibly occurring problem which is requesting exclusive right when connecting with same ID and Password by DBCache Client of other entry client. However it can be solved by passing exclusive right to newest farm client that requested exclusive right.
6.6Battle Server and Client
After the battle client goes through the process of lobby_session and starts connecting to the battle server, it waits until the connection is successfully made with the battle server.
•CBattleClient.Connect
•CBattleServer.OnClientJoin
•CBattleClient.OnJoinServerComplete
When the connection is made, then the battle server starts the logon protocol and receives the information of game session that player wishes to join. This means that the process of joining to the game session gets concurrently conducted at the logon protocol.
•CBattleServer.RequestNextLogon
•CBattleClient.NotifyNextLogonSuccess
When logging on(as well as joining the game session) to the battle server is successfully completed, the game client displays the session waiting room screen, which receives the list of players and information of game session itself.
•CBattleClient.NotifyGameRoomInfo
•CBattleClient.HeroSlot_Appear
•CBattleClient.HeroSlot_Disappear
•CBattleClient.HeroSlot_ShowState
If local player is the host, then he or she can request to start a game.
•CBattleServer.RequestStartPlayMode
Other players than the host must all agree to start the game by clicking on ‘Ready' from the session screen.
•CBattleServer.RequestToggleBattleReady
When every player in the game session sets for ready, the host can start the game immediately. But in order for the game to start, all required data files must be loaded for each game client and until then all players must be on standby.
•CBattleClient.GotoLoadingMode
•CBattleServer.NotifyLoadFinished
•CBattleClient.GotoPlayMode
When the score of players is changed during in-game play, it is necessary to be stored in the database server. This sample allows player to earn a score quickly, which gets stored in the database server.
•CBattleServer.RequestGainScore
When player exits during in-game play, all it needs is to disconnect the player from the battle server and sends the player back to the lobby server logon screen. On the other hand, when the game is over (i.e. Mission Cleared), the game session must go back to the waiting mode and display the screen of session waiting room to each player. For learning purpose, this sample allows you to clear a mission rapidly and witness the process of game ending. Also if other DBcache client of entry client request exclusive right, just disconnect current connection and pass exclusive right.
•CBattleServer.RequestMissionClear
•CBattleServer.GameRoom_GotoWaitingMode
•CBattleClient.GotoWaitingMode