Games running on a PC are often designed with change in mind, and this consequently allows modern computer games to be modified by developers without much difficulty. The Internet provides an inexpensive medium to promote and distribute mods, and they have become an increasingly important factor in the commercial success of some games.

Q3's global sourcing model gives the maximum benefit to customers in terms of cost savings, improved quality, access to highly talented professionals, flexibility of operations and reduced time to market.

Company Profile

Client is one of the major players in the global gaming industry with expertise in both development and hosting of multi-dimensional, multiplayer software games.

Business Situation

Client has a well-established customer market of leased game servers. Client is developing new technologies to address the needs for low-latency, high-bandwidth, fault-tolerant, highly scalable simulation services. In this context, client requires customized mods / plug-ins to be developed to customize the execution logic of some popular games, such as Team Fortress2 and Warsow. The mods will be like add-ins for popular games and can include new items, weapons, characters, enemies, models, textures, levels, story lines, music, and game modes.

Challenges

• Providing platform independence so that the mods/plugins work on both Windows and Linux platforms.
• Automatic loading of mods/plugins through Loader Engine.
• Capturing all player activities and storing the same in the database.

Technical Solution

At the initial phase, Q3 interacted closely with client to gather the exact requirements and came up with the proposed architecture which reflected that the development of the required mods /plug-ins can be divided into three areas:

1. Game Execution: The Game Execution process involves the Game Server, Game Engine and database. The Game Engine is the heart of the entire application and acts the channel of communication between the database and Game Server, as shown in the following diagram:

The Game Engine drives the database and Game Server for the purpose of Game Execution. The sequence of events occurring during Game Execution is as follows:

• The Game Engine keeps on querying the database until it finds a game to be executed. If a game exists, a series of communication occurs between the three entities: Game Server, Game Engine and database.
• The Game Engine picks up the relevant game information from the database for executing the game. This information includes details, such as players who are supposed to play the game, the commands required by the Game Server for the executing the game, game start time etc.
• At the time of starting a game, the Game Engine issues the Game Server commands from the database to the Game Server, which in turn is responsible for the execution of the game.
• The Game Server internally validates the list of players from its internal database. This internal database is a MySQL database which in turn is populated by the Game Engine.
• Once the game is finished, the players are removed from the Game Server through commands issued by the Game Server. The Game server in turn gets these commands from the Game Engine, which in turn fetches these commands from the database.

2. Game Server Logs Recording: The Game Server keeps on sending game messages on UDP port. These messages contain information about the game being currently executed such as kills, deaths etc. The Game Engine has a dedicated process which keeps listening on UDP ports for messages thrown by the Game Server. These messages are then stored into the database by the Game Engine. The messages are used for certain business logic and calculation.

3. Database [Oracle 10g]: The database communicates with the C# engine in order to store/provide the following information:

a. Retrieval
i. Scheduled Game
ii. Information about scheduled game
iii. Type of match and player(s)
iv. Any additional game server execution and configuration commands (RCON Commands)

b. Storage
i. All events, such as player connected, disconnected, round win, kill, round start, round end, match start, and match end. These events may differ with every game.
ii. Result of match – Winner, looser, forfeit.
iii. Statistics – When player plays a match, he performs activities like kill, hit to left arm, right arm, right legs etc. All these activities are stored into the database as statistics of the on going match. Accuracy of these statistics is very important.

Architectural Design Diagram

As shown in the above architecture, the interaction among the Game Server, Game Engine, database and mods/plugins will be as follows:

The game is installed on the Game Server (Server1) and configured to play matches using the required game mods/plug-in. There is a separate Game Server for every game, but every Game Server runs multiple instances of same game on it. This is developed in C# .Net and runs using mono mode.

The Game Engine (on server 2) is like a service/demon that keeps pooling with the database to fetch information on the next scheduled match. The multithreaded engine has plug-in architecture with certain specifications given for mod/plug-in development. Every mod/plugin is independently responsible for executing the specific game for the match.

The interface given by LoaderComponent (Game Engine) provides some basic information about match start/abort and stop/restart.

Technologies

C#.Net
Oracle 10g
MySQL
Linux
Windows XP and Vista

Benefits

• High-performance gaming experience.
• Leverages the potential success brought in by popular mods.
• User-friendly mods/plugins that replace almost all the artistic assets in the original game, and sometimes core aspects of game play.