Building a simple yet powerful MMO game architecture, Part 2
Gaming and Web integration
This content is part # of # in the series: Building a simple yet powerful MMO game architecture, Part 2
This content is part of the series:Building a simple yet powerful MMO game architecture, Part 2
Stay tuned for additional content in this series.
Part 1 of this series introduced a flexible and powerful MMO game architecture, based upon the fictitious MMO game Starship IBM, that's quick and easy to implement. It explained the implementation of the architecture and the interactions among gaming clients, gaming servers, Web servers, and a database.
This article explores the relationship between the gaming components and the back-end component and demonstrates how you can achieve a simple yet powerful MMO game architecture.
Web back-end use cases
Most multiplayer gaming engines, such as Torque Game Engine Advanced (TGEA), provide default MOG functions out of the box. A Web and database back end can be used to add MMO functions. Table 1 shows the core subset of use cases provided by the Starship IBM Web back end. This subset can be used to implement any MMO game Web back end.
Table 1. Starship IBM core Web back-end use cases
|Get available mothership server||Gaming client||Retrieve the IP address and port of an available mothership server to initially log in to. This information is then used by the "Log in to server" use case to log in to the specified server. Additional game logic can be performed, such as gaming server load balancing, that determines which mothership server information to return.|
|Log in to server||Gaming server||Given the player's username, password, and the game server IP address and port, authenticate the user information. If authenticated, the database will be updated to indicate the player is logged in to this particular game server.|
|Get a list destination servers||Gaming client||Return a list of alien outpost and unexplored planet server IP
addresses and ports and the number of players currently on each
game server. The destination IP address and port can then be used
in conjunction with "Check if server is full" and "Log in to
server" to allow the player to travel from the
mothership server to another game server. |
The server player number can be used by players to load balance themselves (players can choose a game server to join that is not maxed out).
|Check if server is full||Gaming client||Given the server IP address, this use case is intended as a last-minute check by the gaming client before initiating the loading and login to another server.|
|Remove player from server||Gaming server||If the player disconnects from the game for any reason, update the database to indicate the player is no longer on the game server.|
|Get player points||Gaming client||Given a username, return that player's point total.|
|Update player points||Gaming server||Given a username and point value, add that point value to the player's point total.|
Actor denotes whether the gaming client or server invokes the HTTP request to the Web server, not whether the gaming client or server initially invokes the use case. For example, the "Remove player from server" use case's actor is the gaming server. Even though this is initially invoked when, for example, the player chooses to quit the game from the gaming client, the gaming server should actually make the HTTP request to the back-end Web server.
Figure 1 shows the flow of the players in Starship IBM, and how they can travel from one server to another. All 20 alien outpost servers are not shown.
Figure 1. Starship IBM player server flow
To help illustrate the flow, the following is a typical sequence of how a player goes through the various servers.
- The player enters a username and password, and selects Login to
start the game. This will initiate the "Get available mothership
server" use case, which will retrieve the IP address and port of an
available mothership server.
Using this IP address and port, "Log in to server" will be invoked, which will authenticate the player and update the database to indicate the player is currently on the specified mothership server.
- The player will bring up an interface that retrieves a list of available alien outpost servers, which will invoke the "Get a list of destination servers" use case.
- The player selects one of the alien outpost servers and starts that mission, which will perform "Check if server is full" and then "Log in to server" using the IP address and port from the selected alien outpost server.
- After the player is finished with the alien outpost mission, the player can go back to the mothership, which will perform essentially the same action as item 1 in this list. This time, though, the player will not have to enter a username and password.
Figure 2 shows all the database tables that underlie the Web back-end use cases described in Table 1.
Figure 2. Database implementation
The GAME_SERVER table stores the data for all the TGEA game servers. Note the one-to-many relation between the GAME_SERVER entries and the PLAYER entries. Each gaming server hosts zero to multiple players. There is also a one-to-one relation between the PLAYER table and PLAYER_POINTS table, as each player has a point total.
Table 2. GAME_SERVER columns
| The primary key (PK), consisting of the <IP
address>:<Port>, which uniquely identifies
each of the TGEA servers. An example value is
| Indicates whether the server is a mothership, alien
outpost, or unexplored world server. The allowed
values are |
| Indicates whether this is a type of game server that the player
can initially log in to (is it a mothership
server). Allowed values are |
The PLAYER table stores the base player information.
Table 3. PLAYER columns
| The PK that uniquely identifies each player. An example value is
|The player's password.|
|The foreign key (FK) to the GAME_SERVER table that indicates which gaming server the player is currently logged in to.|
The PLAYER_POINTS table stores point related data for each player.
Table 4. PLAYER_POINTS columns
|The FK to the PLAYER table.|
|The player's point total.|
Given the GAME_SERVER table described above, and the actual Starship IBM server implementation described in Part 1 of this series, Table 5 below shows what the actual GAME_SERVER table entries would be. Of course, the IP addresses and ports are only examples.
Table 5. Starship IBM GAME_SERVER table entries
|Alien outpost servers 0.0.0.2:28002 - 28009 and 0.0.0.3:28002 - 28009 not listed|
MMO game Web application programming interface (API)
The Web application server uses the given database tables and serves up a set of MMO game functions. The API of the functions consists of HTTP GET requests to the Web server, and the Web application server returns an HTML page for a given request. The syntax of the HTTP GET request API is as follows:
[scheme]://[Web server IP address]/[path]?[query]
[scheme]://[Web server IP address]/[path]?
is essentially static. The interesting part of the syntax is the
[query], which consists of
[action parameter] consists of
[parameters] consists of 0 through N
&[parameter key]=[parameter value]
This basic syntax can be used to accommodate all the HTTP GET request APIs. Table 6 shows examples of HTTP GET requests. Considering the Starship IBM architecture implementation, lets assume the public IBM WebSphere® server IP address and port are 220.127.116.11:80, and the secure WebSphere server IP address and port are 18.104.22.168:80.
Table 6. Example HTTP GET requests
|Web back-end use case||HTTP GET request|
|Get available mothership server|
|Get player points|
|Update player points|
Given an HTTP request, the Web application server will return an HTML page that the TGEA gaming client or server processes. The syntax of the returned HTML page can be:
request-status=[request status] [key value pairs]
[request status] indicates the status of the
HTTP request. The TGEA client or server will use this return status
message and process the HTML page appropriately. For example,
SUCCESS indicates the request was processed
successfully, while other possible return status messages, such as
SERVER_FULL, can indicate other states or
problems with the HTTP request.
[key value pairs] consists of 0 or more
[key]=[values] pairs. Each
[key]=[values] pair is on a separate line.
[values] can consists of one or more entries
delimited by a comma.
Table 7 lists the returned HTML pages for the example use cases.
Table 7. HTML page returns
|Web back-end use case||HTTP GET request query||Example returned HTML page||Notes|
|Get available mothership server|
|Log in to server|
The Web server doesn't perform the actual game login and loading. It simply authenticates the player and updates the database to indicate which server the player is on.
|Get a list of destination servers|| The |
|Check if server is full|
|Remove player from server||Should be invoked when a game client disconnects from a game server for any reason.|
|Get player points|
|Update player points|
The main characteristics of an MMO game are persistence and integration of the gaming world and servers. The use cases in this article demonstrate how to achieve persistence and integration in the Web back end. The "Get player points" and "Update player points" use cases show how to achieve persistence. It is easy to then extrapolate other persistence related functions, such as retrieving and updating a player's inventory or game world status.
Gaming world integration is more interesting and a little more involved. The small set of server-related use cases in this article show how gaming world integration functions can be provided by the Web back end.
Example: Log in to server in Torque
Implementing the use cases is straightforward using TorqueScript. Create a TorqueScript
HttpObject, make the appropriate
HttpObject get request call, and process
the returned HTML page. However, implementing the "Log in to server"
use case might not be that obvious. To go from one server to another in
Torque, you need to invoke the standard TorqueScript client functions
%ipAddr is the destination server IP
address. This will disconnect the player from the current game server
and start loading the new mission from the new server. The
"Log in to server" Web request can then be invoked in the default
TorqueScript server function
GameConnection::onConnect() to perform its
housekeeping duties of properly updating the database.
"Check if server is full" should be invoked right
disconnect(). The sole
purpose of this use case is to help reduce the number of unnecessary
(and unceremonious) dumping of game clients from the game to the login
screen. This happens when
typical, preventable case occurs if the destination server player count
maxed out before the client could start connecting to that server.
Other Web back-end use cases
The small set of core back-end use cases in this article helped explain the MMO game function provided by the Starship IBM Web back end. Of course, an actual MMO game would include more involved functions. The following list has brief descriptions of other possible MMO game use cases that can readily be implemented with the Web back end described in this article.
- More persistence functions
- Besides retrieving and updating points, other persistence functions can also be implemented, such as retrieving and updating player profiles, inventory, and game world status.
- Viewing a list of players on other servers
- Since the player and server relationship is tracked in the database, it's straightforward to display the list of all the players on a particular server. Messaging players on other servers is also an intriguing possible function; Part 3 of this series will explain how it might be implemented.
- Mission-status related functions
- The game servers can schedule a
recurring function that updates the Web and database back end with its
For example, the alien outpost mission could be a timed mission. The mission time can be passed to the Web and database back end at a repeated interval.
- Game server monitoring
- All game servers can schedule a repeated
keep-alive message to the Web and database back end. In conjunction with an
e-mail messaging component in the Web application server, this message can be
used to notify system administrators when a game server goes down.
The server status information can also be incorporated into any game server load-balancing algorithm, so users are not sent to a game server that is apparently down.
- Integration with other applications
- There are intriguing possibilities for further integration with other applications, using a middleware application such as IBM WebSphere.
A Web and database back end can be used to provide MMO game functions, such as persistence and an integrated game world. You can do so in a straightforward manner using a set of Web APIs using HTTP GET requests. These APIs are part of a standard three-tiered architecture, where the gaming client and servers cleanly integrate with a Web and database back end. The APIs have an effective array of options that can provide virtually all MMO game-related functions.
Stay tuned for Part 3, which will review and assess the capabilities and limitations of the MMO game architecture, and whether it meets the high-level specifications and goals defined in Part 1 (scalability, flexibility in deployment, flexibility in gaming design, performance, and security).
Thanks to Scott Crowther and Abraham Guerra from IBM CIO for implementing the WebSphere and DB2® components for PowerUp the game. This allowed the author to focus on such business critical tasks as dune buggy anti-rollover logic, water balloons, laser beams, and "smog monsters."
- Check out the other parts of this series:
- Part 1 shows you how to build a flexible and powerful MMO game architecture that is quick and easy to implement.
- Part 3demonstrates how the MMO game architecture meets the high-level architectural goals of scalability, flexibility in deployment, flexibility in gaming design, performance, functions, and security.
- Read about MMOs on Wikipedia.
- GarageGames specializes in gaming engines targeted for small and independent game developers.
- Torque Game Engine Advanced (TGEA) is GarageGame's flagship 3D game engine.
- Torque Game Engine (TGE), another game engine from GarageGames, has less advanced graphical capabilities than TGEA. It cannot render shaders (out of the box), but its networking capabilities are very similar to TGEA. The architecture described in this article does not use any particular feature that is TGEA specific and not part of TGE. TGE also runs on Linux® and Macintosh.
- The GarageGames forum covers Torque client/server networking.
- Read about how Torque interacts with a Web server.
- For comparison purposes, Unity is a 3D gaming engine that has features comparable to Torque.
- Check out Unity's game networking, particularly the section on "WWW functions" to learn how Unity talks with Web servers.
- Learn more about the various IBM products described in this article, including IBM WebSphere , IBM DB2 , and IBM BladeCenter® servers.
- Get the RSS feed for this series.
- Download, explore, and play PowerUp.