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.
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.
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.
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:
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:
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)
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.
Windows XP and Vista