category: Application fundamentals

The Stormancer platform consists of a number of elements which allow you to develop online games.

  • A set of clientside libraries for various game development tools and languages.
  • A distributed server platform designed for performance and scalability. The platform allow you to create application then host it easily on the cloud.
  • Serverside & clientside components built for the Stormancer platform. Currently all of these components are open source for easy modification to fit your needs.

Technology

Network engine

Stormancer uses a cross platform network engine optimized for performance. It handles all the complexity of establishing connectivity between different devices, whether mobile, web or desktop based. To do that, it currently implements two transports and is modular enough to accomodate new ones when new technologies become available. (ORTC datachannels, for UDP in web applications *_* )

  • UDP through the Raknet 4 network engine. Raknet is a reference in the gaming industry, powering many games. It's a proven and stable technology, now available as open source. Raknet provides the best set of capabilities for Stormancer, and is our "reference transport". It provides reliable & not reliable messaging, prioritization and packet ordering.
  • TCP through websockets for the platforms without raknet support. websockets provide efficient realtime communication capabilities from an HTTP connection. It's essentially TCP with an HTTP handshake. It's fast enough for a lot of applications (many games run using TCP based protocols). However, TCP only supports reliable messaging, which may result in network contention if the connectivity is not good enough, or if too many messages accumulate.

Distributed cloud based engine

Stormancer is built from the ground up for the cloud. When we started the project, we had several core objectives.

The first was scalability, making sure that developers using the platform would be able to build great scalable multiplayer games. The core hosting infrastructure is a distributed system able to host your games transparently on several servers, according to your configuration. When developing games for Stormancer, you just don't have to care about synchronizing servers or load balancing your game sessions.

The second was customization & flexibility. Stormancer is a platform to run your code . We are quite fond of the work made on modern cloud web hosting platforms, so we’ve taken some of our inspiration from them. [Deployment][deployment] is always a few keystrokes away, then rollback securely if something goes wrong. We handle everything to make sure it happens smoothly.

The last was security. All the applications are isolated. Stormancer nodes (hosting apps) are isolated too, and all the network communication between your app and the exterior are filtered by the distributed platform. The web API themselves and the websocket communications are secured through SSL and symmetric key authentication.

Open source & standards

To make sure that Stormancer is as easy to integrate with outside technologies as possible, we make extensive use of standards or common technologies, whenever possible (if we forgot something, don't hesitate to remind us about it). Managing applications and monitoring them can be completely automated through a web API. The authentication process is mostly powered by OAuth (some work is required in this area) and our serialization protocol is the awesome MessagePack. Our communication protocol is proprietary as nothing adequate existed, but the specifications are available on request (and on our website in the near future).

We think that open source is today a core part of a great development experience. We have opensourced many libraries and components on GitHub and intend to add more in the future. All of our turnkey components including chat, virtual shop, turn-based engine will be open source. C# based, fully non blocking server scripting Recently someone asked us this very question: Why the hell is Stormancer scripting done in C#? Why not Javascript? We have several answers. The first is a single keyword (two actually) async await.

The asynchronous development capabilities of C# 5 are awesome and are the cornerstone around which we built our non blocking server platform. We like JavaScript promises very much, but they just can't compete. It's very easy to write fully non blocking and highly scalable code with C#, and the Stormancer platform leverages that fully. And you can, too. The second answer is shorter: why not. ;)

But what does "non blocking" mean? It means that when your Stormancer server application is performing HTTP or Database queries, it doesn't block while waiting for the answer from the remote server (and that can be a long time). The compute resources are free for other processing or user requests. Several queries can even be parallelized, increasing performance and preventing the server from becoming unreachable while doing essentially nothing.

Application structure

In this part, we will introduce accounts, applications and scenes. Let's start with a diagram summarizing all these concepts.

application

Account

Accounts group applications in a logical management container. Several users can manage the same account, and an user can manage several accounts. Management rights are defined at the account level for operations like deployment, rollbacks or application creation. (Note that currently application deletion is not possible on Stormancer. It would involve some complexity we haven't have the time to deal with yet).

Billing occur at account level. Payment methods are defined here too, and are not linked to an user in particular.

Accounts are identified by an (almost) friendly looking guid.

Application

Inside accounts reside your applications. You can have as many of them as you want in an account. Applications are associated with one or several deployment packages. These packages contain code and any static resources required for your server app to run. When you deploy a new package on Stormancer, it's stored on the platform until it needs to execute your code (when an user attempts to connect, or when it needs the list of scene types exposed by the application.). When this happen, the platform selects one or several server nodes on which to run your app, deploy the package on these servers, and starts an isolated application node running your code.

We store up to 10 versions of your application package, enabling you to rollback to earlier versions in a single clic may something go bad with your brand new code.

Furthermore, Stormancer provides metrics & server logs at the application level.These informations are available in realtime from the stormancer management portal or by any external application with account level access using the web apis.

Managing applications

Scene

Scenes are the cornerstone of your applications. Whenever players are interacting with it, they connect to scenes. Scenes can be chat rooms, lobbies, game sessions or whatever meeting point your application requires. One or more players can connect to the same scene, and such players can interact with one another or the scene logic.

Scenes can be public or private. Any user can join a public scene using the Stormancer client libraries with its own user data

await client.GetPublicScene("myPublicSceneId",userdata);

However, users need a authentication token to join private scenes.

await client.GetScene(token);

The token itself is generated using the Stormancer Api. This process requires an application level private key. The token contains:

  • The scene Id
  • User data defined while creating the token

This process allow you to plugin any authentication mechanism into the Stormancer infrastructure.

For instance, you could authenticate users on your website, create a token in the website using session data, and send it to the user for authentication with Stormancer.

Or you could create a public scene (a lobby) that would perform authentication using user provided data (for instance a login/password). Once the player authenticated, the lobby would provide token for private scenes according to your game logic.

All scenes have a scene type that defines which game logic they run.

Scene type

Every Stormancer applications define one or more scene types. Scenes types are an abstract collection of behaviors, a little like object definitions in object oriented languages. For instance, concepts like chatrooms, lobbies, gamesession are scene types.

When you create a scene, you have to tell the Stormancer api its type. When the runtime need to instantiate the scene, it will use the definition to add the required functionnalities to it.

You define scene types by providing a factory method to the runtime for a given identifier. For more information, look at the Creating scene types article.

Under the hood

Object oriented libraries

Most network engines offer a very low level set of functionalities clientside. In Stormancer, we chose to provide "fast & easy" object oriented APIs and low level equivalents when more flexibility is required.

So for instance, when you need to send a message to another Stormancer peer, you can either send an instance of an object or handle the serialization process yourself and write bytes directly to the stream.

var data = new Dto{ Text="Hello world!"};
scene.Send("aRoute",writer=> writer.Write(data));

or

byte[] rawData= GetMyData();
scene.Send("anotherRoute",writer=>writer.Write(rawData));

In the first case, Stormancer will serialize your data using MsgPack, in the second case, Stormancer will send the rawData to the remote peer without any processing.

More informations about the serialization infrastructure and how to customize it are available in the documentation.

The libraries are fully asynchronous & non blocking. We expose events through the Observable pattern, and bundle Reactive Linq with the libraries for powerful event querying.

var events = from e in OnMessage<MyObject>("route") where e.Dest == currentUserId select e;
events.Subscribe(e=>Console.WriteLine(e));

Server platform

The stormancer server platform is implemented as a distributed container system. Each server node can host several application node, and application are segmented into several application nodes each one on a different server. Each node expose our web API and transport endpoints. When a client application connects to Stormancer, a server node hosting the target server application is selected, the client connects to this node, the application node is started if necessary, and the servers route the client session and requests to the adequate application node. In the Stormancer platform, application startup is lazy, to make sure that resources are allocated to running applications. In the same way, inactive applications are shut down after an inactivity period.

Each application node on a server node is isolated in its own process. It's possible to enforce resource limitation on application nodes to make sure that each application gets its share in CPU & memory.

Server architecture

Compilation

Coming soon

Authentication & security

Coming soon

Client libraries availability

Client libraries are currently available for Unity3D (Desktop, web & mobile). These platform have very different capabilities and we optimized the client runtime for each of them. All Stormancer features are available in all Unity3D libraries.

Libraries are available for javascript too. They provide a similar set of features, with some difference in performance and implementation: Data serialization from & to javascript applications offer slightly less performance.

Finally, we provide .NET Mono compatible libraries compatible with the Microsoft .NET, Mono & Xamarin platforms.

[deployment] : /documentation/Deployment