Shadowrun: Awakened Forums Welcome, Guest. Please login or register.
Did you miss your activation email?
  Site Forums   Wiki   Bugs Code Docs Help Register  
    Page   Discussion         View source History  

Game Applications

From Shadowrun: Awakened

Jump to: navigation, search
Awakened engine.png

The Shadowrun Awakened game applications are the executables that run in order to provide the game. This article encompasses both the server and client applications, along with various supporting tools.


Additional Documentation

This document offer a high-level view that breaks down into article for each application. Documentation for the code, technology, and other supporting aspects of game applications includes:


The broad strokes of intended software for the project are laid out in this section. They seek to enumerate the capabilities available to the project and how we will harness them to build software that builds the game.

Behavior Architecture

UDK behavior.png

The Client and Zone Server Game Applications are fundamentally customizations of UDK applications that deliver content. In the UDK, both the application and the content can hold behavior. These layers include:

  • Matinee - A system for building cinematics in-game. While SRA is likely to have much in the way of cutscenes, Matinee is useful for creating basic animations for items like doors. Matinee is accessible from the UnrealEd level editor.
  • Kismet - A visual scripting system for controlling actors in a level. Kismet is useful for triggering behavior from player actions, such as opening a door when a player approaches it. It is accessible from the UnrealEd level editor.
  • UnrealScript - The Unreal engine's proprietary, Java-like scripting language. Classes in UScript are capable of modifying Unreal games at a low-level, such as AI and most Game mechanics.
  • C++ - The UDK is capable of loading and calling functions within a DLL via the DLLBind mechanism. For our project, this means writing code in C++ and building a DLL in Visual Studio. Ultimately, UnrealScript must be written to wrap this code, meaning it can only be functional in design (classes that utilize the code can be made in UScript; however, only C++ functions can be utilized). This enables the UDK to import fairly arbitrary functionality, such as calls to a MySQL database or external networking library.
  • SQL - Persistence in the game world is built on storing data and SQL databases excel in that area. Utilizing tables, views, triggers, and stored procedures, data is both stored and some behavior imparted. While this facility is separated from the UDK by a layer of C++, design decisions in the database affect the applications holistically, even if many complexities are hidden.

While any contributor to the project is encouraged to help in any way they can, these layers do require different types of expertise. Both Matinee and Kismet are accessible through visually interactive interfaces that virtually anyone can easily learn; however, the three types of programming languages require expertise that can take a long time to build up. This means that the layers requiring programmer-driven customization need to be thoughtful in trying to harness the layers above that are accessible to all contributors.

Game Applications


The applications make up the game "Shadowrun: Awakened" in its entirety, from behind the scenes into the eyes of the player. They express the game mechanics and knit together the Assets to create the world. They utilized the UDK and are written in a combination of UnrealScript and C++.


The client application runs on a user's computer. It allows the user to find and connect to SRA server applications. It provides a front-end into the universe through graphics and sound. The client will be built primarily using the UDK with most custom programming done in UnrealScript. Additional features in C++ will be added to enable communication with the World Server and any other non-UDK-enabled applications.

Zone Server

A zone in SRA constitutes a single discrete physical location that is part of the larger world of Shadowrun. Many instances of the Zone Server will each run an Unreal level that will have players constantly joining and leaving them. Each instance will integrate with the World Server to control what zones are running and to enable communication amongst active instances. It will also heavily communicate with the MySQL database to provide persistence in the game world's characters, objects, missions, etc, without tying up the World Server.

World Server

The world server provides a nexus for players and zones. It communicates with the zone servers, providing glue to stitch the discrete areas together, guiding client connections amongst the different areas.

Patch Server & Client

The patch client runs on a user's computer. It handles installation and file maintenance to keep the player's client synchronized with a particular server's content. This loader will connect with a remote computer that provides content to connected clients and will need to be custom built by our team. In the beginning, the client loader will likely not exist and users will suffer periodic manual installs to maintain their content. The patch server is primarily a file host that keeps up-to-date version of game assets on hand for players to connect to using the Patch Client. This enables everyone playing to use a single set of assets. In the beginning, it's likely the Patch process will be carried out using manual releases of uniform installers.

The patching system is not a necessity in the short-term, so no real planning or progress had been made on them. When the project begins to support a world that changes at a higher velocity than what putting out new releases would make convenient, then we will move to a patch-oriented delivery architecture.

Chat Server

The chat server runs independently and handles the vast amount of text conversations passing through the system. Since the UDK provides some in-game chat functionality, this responsibility is currently planned to be managed by the Zone server. This will limit players to chatting only in the same zone in the short-term. In the long-term, we will enable communication throughout the game world through use of a chat server (or potential integration of these features with the world server.

Development Tools

These are tools that support the creation of the game products, but do not appear as part of the interactions that support the game's mechanics or world.

Routine Analyzer

This C# tool generates code that interacts with the MySQL database. It procedurally generates the code by analyzing all of the stored procedures within a given schema. It is capable of making both C++ that calls into MySQL and UnrealScript that relies on the C++ code to relay data from the database into UDK code.


This C# tool interacts with item definitions in the database. It covers not just general purpose gear, but also weapons, augmentations, and spells.

The Code

Before reading this section, it is best to have the code downloaded. Information on getting started can be found amongst our tutorials. For a more low-level description of classes in-game, and to cross-reference with class names appearing in this document, check out the Doxygen documentation of game engine.

SVN Branches

The three main code branches are described below. Most developers need only concern themselves with SRA_UDK_Development since it's the dynamically growing code. All other branches are utilized in the release process.

  • SRA_UDK_Development - The active development branch where new changes and patches are applied, representing the ever growing snowball of features in C++, C#, SQL, and UnrealScript, plus all supporting libraries.
  • SRA_UDK_Beta - A snapshot of the development branch after an internal release, representing the current version undergoing testing.
  • SRA_UDK_Release - A snapshot of Beta at the time of release, enabling developers to reference code out in the world when analyzing problems.

In addition to the three active branches, there are two legacy branches that contain outdated, but potentially still useful code. Two of the previous version were noteworthy achievements in design that may need to be revisited for insight, particularly the SRA_OGRE line since it include some generally useful C++ functionality.

  • SRA_XNA - The second prototype game engine developed in C# that integrated Microsoft XNA, Castle Active Record, and Nvidia PhysX (back when it was owned by AGEIA).
  • SRA_OGRE - The third prototype game engine developed in C++ integrating OGRE, Nvidia PhysX, Boost, and Qt.

SVN Directory Structure

Each branch listed above has a similar file structure. It include all of the code directories, plus some other important directories that support it. There is a Visual Studio solution in the root directory that opens all relevant C++ and C# code for the project. Other directories containing material that supports this code or is part some other component includes:

  • Include - This directory holds all of the C++ Header files for third-party technology in the game engine. For instance, all of the headers for the MySQL C++ connector are in here. They are grouped by the product to which they pertain. The Visual Studio projects reference this location under their "C/C++" options.
  • Lib - Holds all of the .lib and .dll files for third-party technology in the game engine. For instance, the .Net Assembly fro the MySQL .Net connector is in here. They are grouped by the product to which they pertain. The Visual Studio projects reference this location and files within it under their "Linker" options.
  • SQL - This directory contains all of the SQL code for the project, most importantly the database schema for the MySQL database. To create a local instance of the SRA database, install MySQL, then use a tool to run this SQL code on the database.
  • UDK - This directory holds a copy of all UDK files that have been changed by the project to turn a standard UDK installation into an install of SRA. This includes all of the UnrealScript, the SRA splash screen, and modified config files. Applying the contents of this directory to a local UDK installation is explained in the How to customize a UDK install article.

C++ & C#

Our C++ and C# code is broken up amongst many libraries to more easily test our code and share it amongst numerous applications. All of this code is written and built in Visual Studio. Some libraries add features to the UDK, some are utilized by standalone applications that are part of SRA's tools or tools, and some libraries serve both purposes.

  • Routine Analyzer.exe - A small WinForms tool written in C# that connects to MySQL databases. It generates C++ and UnrealScript code for calling into the database's stored procedures. The code it generates appears in the SraData library and the UnrealScript code.
  • SraData.dll - Implements calling from C++ into MySQL stored procedures. Its intended to support manipulating the database from both C++ libraries and UnrealScript via DllBind. In the post-build events for this library, it copies the DLL into \UDK\Binaries\Win32\UserCode in both the SVN directory and the latest UDK installation's directory.
    • SraData Unit Test.exe - Calls the C++ version of data features in SraData, exercising their functionality and ensuring it runs. Please run this after making changes to SraData.
  • Support.lib - A library of supporting C++ classes that implement reusable features, including the Singleton, Object Pool, and Command design patterns, plus threading and custom collections. Code unrelated to game features that can be used by more than one library should be implemented in here.


All UnrealScript for the project is held in the "\UDK\Development\Src\SRA\Classes" directory. Some classes implement common UnrealScript design patterns while others are completely original.


All of the SQL utilized by the project is held in a single .sql file. This includes definitions for the tables, views, stored procedures and other parts of the schema, plus initial data based on our interpretation of the SR4 ruleset. To create an instance of a SRA MySQL database, simply create a new database instance on your local drive and run the contents of the sra_dev.sql file as a script.


The Game Engine History document details the growth of the game engine.