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  

Shadowrun Awakened

From Shadowrun: Awakened

Jump to: navigation, search

Shadowrun: Awakened (SRA) is an Massively-Multiplayer Online Roleplaying Game under open source development. This article lays out the goals and challenges of our project, plus guidance for behavior of its members. The community-driven effort is driven by the Shadowrun Awakened Team.


Mission Statement & Project Goal

The mission statement of Shadowrun Awakened is to "create an exciting, fun, well balanced MMORPG set in the Shadowrun universe of 2070 using the 4th edition rule set". Our specific goals are:

  • Produce a Massively Multi-Player Online Role-playing game that emulates Shadowrun 4th edition set in 2070
  • Produce a 3D gaming experience built on character development and team-oriented gaming
    • Produce a game that users can pick up and play, but keeps them coming back
    • Foster a community of healthy competition amongst the players, not domination
    • Create an economy of wealth, advancement, and player interaction that makes a rich experience, not rich characters
  • Develop a world that expresses Shadowrun in as many ways as possible
    • Without losing elegant design
  • Capture the dark, nihilistic tone of Shadowrun
    • While having a sense of humor about it (as Shadowrun does)
    • Be faithful to the established fiction of Shadowrun, while still telling our own stories
    • Tell stories inside of its framework

Member Charter

Not only does the project need to state its goals for the product, but we must also define goals for our organization.

Approved behavior

The project is a long-term proposition, so always think of your comments/reputation/work as such. Someone 6 months from now will read it, someone 6 years from now might read it. People participating in the project, especially those representing the group by communicating with outside parties, must observe the following principles of decorum:

  • Politeness - Choose polite words and strive for a polite tone.
  • Respect - Not everyone will think as you do, respect their difference in opinion during discussions.
  • Trust - Not every choice in the project will reflect your opinion, especially in the details, trust that the shared ultimate goal will be realized and that's the most important thing.
  • Humility - You are not the first or last person to join/leave/disagree and no one person "owns" any part of the project.


The goal for our project is to listen to everyone as equals, but at the same time, never let ourselves be derailed. At times where we cannot come to a general consensus on an important issue, an objective and democratic measure of opinion will be used to settle disputes. This will maximize consensus while minimizing conflict. Unfortunately, voting does mean there are winners and losers, so putting everything to vote can be detrimental to the group over time.

Each Member appearing on the SourceForge Developer List is entitled to vote. The Senior members represent a quorum necessary for voting. For voting to pass, it must carry a two-thirds majority.

Donations Management

Perhaps the greatest point of ethics in the project surrounds our handling of money in the form of donations. In no place must we venture with more respect than when respecting the money given to us to help create Shadowrun in a virtual world. We may also create a proposal to one of several organizations in order to raise additional funds.

Project Licensing

In Shadowrun Awakened, we are walking a fine line of intellectual properties and licenses. We are an entirely non-commercial enterprise. We are a gang of dedicated fans wishing to manifest the will of a greater community of devotees. At the same time, we are treading on territory that could provoke tremendous litigation.

  • In 2006, Microsoft granted our project a non-commercial license to develop Shadowrun as an MMORPG. This means we must be mindful of our conduct with the game and recognize that Shadowrun is ours to pay tribute to in as high quality a manner as we can, but it is not ours.
  • The fourth edition rules set, developed by FanPro and owned by WizKids, is also something we are respectfully borrowing. Talks with WizKids continue as we hope to attain a similar non-commercial license with them, allowing us to continue the project without stepping on any toes.

Part of the necessary respect for licensing we must show is because we are also generating our own worth that we wish others to respect. While we look to others to lend us Shadowrun, the project and its contributors will be the owners of their works. The licensing of our own products falls into a few different categories.

  • One big umbrella for the project is the software we are making to share with everyone. The third party technology we use will impose licensing upon us in regards to how we can change or distribute it. Also, the software we create will have rules on its uses and distribution. Pending a comprehensive analysis of our licensing issues, we are looking at utilizing LGPL for licensing all Open Source parts of our platform. Other groups, with other goals, may utilize our Open Source tools to create their own incarnations of Shadowrun or an entirely novel game.
  • The other big umbrella is the content we are making to share with our users. This content is created by dedicated artists who deserve credit for their work. For this reason, we do not take an "open source" approach to our content. Starting at Beta, we intend to offer, as a service to players, an "Official Shadowrun: Awakened Seattle". This will be our extension of the Open Source SRA server and client that we will release. Anyone logging onto our server will be bound by our EULA. This will include language, and potential software measures, against the piracy of content from SRA's content team. We want our artists to still own their work and we want prospective users to respect their rights. Developers wishing to utilize our engine in alternate SRA servers or in their own games must provide their own content.

Please note: this wiki site is CCL. Non-Corporate, Sharing licence, that must continue to be Shared.


Stakeholders are anyone that will be affected by the success or failure of this product or any changes to its architecture or use. In the case of Shadowrun Awakened, we are not responsible to a specific entity overseeing our production; however, we cannot make the game just for ourselves.

  • Players – One day, people will play the video game we create here. They will be out primarily for a fun time. Also, we must at all times remember that they will be functioning as a large community, not just as individuals. This means we must balance the needs of the many against the needs of the few.
  • Us (The developers) – It was just stated that we must keep the project from becoming selfish in its requirements, but we must also remember that we came to the project to make a game we want to play. Any feature or design decision that the development community surrounding the project cannot find peace with is a feature or decision the SRA community cannot find peace with.
  • Shadowrun Fans – The core concept of our game is to make Shadowrun into a video game. We can make sacrifices for the sake of fun, put off features for the sake of technical considerations, but contradicting or violating Shadowrun will only serve to alienate part of our base. We should look at Shadowrun fans as automatic players, not a burden keeping us from being creative. Whenever a feature or decision is brought forth, remember that this is the only SHADOWRUN MMO you may ever make, be sure you do not confuse it with what would be a good Shadowrun game of another genre, or a good game completely unrelated to Shadowrun.
  • Microsoft, WizKids, FanPro – The profit seeking companies that control Shadowrun have little active interest in our project. We also have no written requirement to obey or honor them in anyway. At the same time, it is in our best interest to integrate with them whenever possible. This means we must keep a certain attention on keeping the game in a direction that can be integrated with the goals of the companies.

Project Risk

A risk is any project factor that threatens success. For Shadowrun Awakened we must weigh our risks carefully and react to them by engineering them out of existence.

Key Project Risks

  • Litigation
    • We do not own the Shadowrun Intellectual Property. We are fans doing our best to pay respectful tribute to an entire world of fiction and the collective enjoyment of a community around Shadowrun. This places us in a vulnerable position where the machinations of the owning entities can quash our project, like Shadowrun Online before us. Having obtaining initial permission from Microsoft at the inception of the project, we hope this risk is eliminated.
    • The world of commercial video game development, like any economy based on ideas, is rife with copyright issues in the general case. Even down to the naming of our project, we must take special care to avoid making ourselves a target as we have a very limited means to fight back.
  • Longevity
    • Open source projects generally suffer from longevity issues due to how few people are acting as meaningful buoys for the project. The more common problem is a loss of focus or a falling out amongst the members.

Key Software Risks

  • Functionality
    • Turning Shadowrun into a digital interpretation is a daunting task. The number of features required will be immense. Features must be constantly filtered to pertinence to both global scope and current iteration. We must not dig ourselves into a feature hole by placing unnecessary amounts of requirements on ourselves all at once.
  • Usability
    • Part of the nature of the project is seeking to reinvent some of the conventions of the MMO. Because Shadowrun is divergent source material to any current MMO, there will be certain concern with delivering an experience users find easy to pick up and play. Usability study, collection of user comments, and a long period of testing with full 1.0 features prior to official release will help reduce this risk.
    • While also a concern for assets, the graphics of a video game are usually used as a determinant for its quality. For the game engine team, this means capitalizing on as many features of our graphics engine as we can to deliver a delightful user experience. While we believe our chosen graphics engine is excellent and will serve admirably, we must also look to the future and be sure we are able to decouple rules implementation from the graphics and sounds output to make sure changing engines is as painless as possible in the future.
  • Reliability
    • Any networked application has concerns about quality of connection adversely affecting reliability. In the case of an MMO, the focus on shared game state means connection reliability is paramount. We cannot change a user’s connection speed, but we can be sure our client and server only communicate when necessary. No work should every be done on the server when it could be done on the client unless it poses a security issue. No work should ever require transmission of a notification when it could happen on one side unless it severely violates performance on one side.
    • It is a fact that users will be dropped from the game from time-to-time. Since we cannot guarantee it will not happen, we must ensure that its negative affects are minimized. No single player being dropped should cause a loss of information or deadlock for any other player or for the team in which that player may have been participating. This means that any volatile information on the game state stored on the client must be non-essential or mirrored by the server. Also, there must be redundancy in logic allowing teammates to continue on without their teammate. Similarly, no single player experiencing connection problems should threaten the connection of other players.
  • Performance
    • Graphics applications, especially video games, pose high performance constraints on the designer. Add in the networking concerns of an MMO and we start to feel a big performance pinch for the client application. As a benchmark for both, we must set a goal of maintaining a constant 30 frames-per-second or better for all clients. This also applies in high performance risk situations like combat and driving. Nothing ruins a good game like dropped frames.
    • The server must maintain, adjudicate, and disperse the game state to all clients within each area. This demand means the server must be intensely efficient. This efficiency will come not only optimizing actions for time, but also minimizing what the server needs to do for its clients. Any operation that cannot be exploited to unbalance the game must be performed by the client.
  • Security
    • For our project, “security” does not mean maintaining confidentiality for our users and their information. Primarily it is a game balance concern. It must not be possible for the game to be exploited in any way such that one player gains an advantage over all others. The game mechanics must be evenly enforced for all players. We must maintain the game state such that a single modified client application cannot create exploits in the game.
    • Despite being open source, we are not making it our policy to be 100% open with our game assets. This means that some assets must be protected by closed code. It must not be possible for outside users to access our models or animation once the game is installed.
  • Quality
    • Open Source projects constantly fall short of high quality. Due to the nature of our project as Open Source, we must keep sight of our quality. This means installing a quality control process for both coding and assets. This extra layer to the process will manage our quality and overall ensure we are reducing our risks and not introducing new risk.
    • No one wants to play a buggy video game that has many playability or usability issues. This means we must check any speculations on user demands against concrete user experiences gathered by our process. This means putting the game in the hands of real players who are not necessarily developers. This also means that coding bugs that result in crippling playability problems are as important as bugs that cause crashes.
  • Supportability
    • SRA’s planning must be done beyond the scope of releasing our initial 1.0 release. All MMORPGs must be ready to grow and change. We hope players will invest thousands of hours into our video game, thus we must be prepared to present thousands of hours of content. This means keeping an eye out for extensibility in our design.
    • SRA’s group of developers, since we are Open Source, will have some rotation to its roster. This means we cannot count on supporting developers to necessarily understand every facet of the game. This means we must help all future developers by producing comprehensive documentation, self-documenting code, documentation in code, and ensure that all active developers are generalists in their knowledge of the product.

Current Status

The project is currently in pre-alpha development of client, server, and necessary tools. Game content is being designed and created.

Anyone interested in volunteering should read the Tutorials.



Shadowrun: Awakened was originally started in 2006 by James Wood as a Project. James initially gained permission from Microsoft for non-commercial development of a Shadowrun MMORPG. He recruited Erik Ralston, known at the time for completion of his Shadowrun machinima. This time laid out a few tenets of the project, including settling on 4th edition. However, the project quickly went dormant due to conflicting life issues.


At the start of 2007, the project was slowly re-kindling thanks to the enthusiasm of Stephen Turner.

  • Spring - The project was blessed to find Aaron Adrignola who put his web skills to work establishing a website, forums, and wiki dedicated to the project. Game Design was heating up using Project Darkstar. Realizing that this could immensely shorten our required development time, the decision was made to utilize this open source revelation instead of our custom Distributed Cell Architecture (DCA).
  • Summer - Server and client technology hit numerous issues with their chosen technologies. We proceed using C#, XNA, and ICE. Development reboots.
  • Fall - We gain our 100th forum member. We go up on MySpace. We pick up Castle Active Record. We drop ICE for .Net Remoting during prototyping, we may see ICE later. Client, being most of the way to Game Engine Alpha, loses some momentum as we put more resources into Server to get it back to its feet. The first prototyping of the Commands & Snapshots design begins.
  • Winter - Server shares its first simulation and reaches its GEA status in only one month. Client's GEA list is reduced down to only animation. We christen the engine technology "Awakened Engine". We upgrade to XNA 2.0, many enhancements are added to our ability to simulate (including triggers, heightfields, and convex colliders). GEA is declared as achieved despite animation being stymied by XNACL being trapped in XNA 1.0.


  • Spring - After the upgrade to XNA 2.0, we hit a rocky time trying to include animation. Also, the desire for realistic lighting & shadows begins to undermine the factors that led us to C#. We reboot development back into C++ with PhysX and OGRE leading the charge.
  • Summer - Reconstruction of features in C++, Physics & Graphics. FMOD integration, Cross-platform support (Linux), serialization of levels, integration of Qt.
  • Fall - Content editor prototype released internally
  • Winter - Begin new SraLogic library for game mechanics implementation


  • Spring - SraLogic development continues; plus collision filtering and events are added to support logic and sound. The Boost and Thread Building Blocks libraries are integrated with the engine, primarily for threading and timers.
  • Summer - Coding enters hibernation while our Lead Software Developer changes employment and location.
  • Fall - The project starts meeting the limit of the OGRE engine. With the release of the UDK, the project is tempted into changing tracks again.
  • Winter - We adopt UDK and start on a new direction.


  • Spring - UDK is proving its worth. Data integration with MySQL is underway and the new beginning is going well.
  • Summer - Integration with MySQL is patterned out and ready to be filled-in, on-demand, as the game mechanics grew.
  • Fall - Movement, combat, sneaking, and basic AI start to coalesce in UnrealScript.
  • Winter - Cover and inventory each get initial treatment in UScript.


  • Spring - A working installer is created for the first time. A sizable overhaul of the data layer is made to streamline inventory management. An initial arena is crafted in the UDK.

A more detailed development history can be found in the following articles: