Hi!

We are a small team building a cloud platform to offer free tools and affordable hosting for realtime multiplayer games. We started this project some time ago when we started such a game, and we want to share what we are building.

After much work, we have made it available for everyone as a free beta. We really would like feedbacks and suggestions about what we've created and what you would like to see.

Stormancer uses websocket (we are working on UDP communications through Raknet), works currently for javascript and Unity games, and allows developers to deploy fully customizable code in the cloud (including stuff like physics, database, culling or AI). It's mainly coded in C#, and all the logic is non blocking.

We want to open source the client SDKs soon too (We just feel a little too bad about some parts of the code to release that now :( ). The documentation is a little (too) sparse right now, feel free to ask us for help. We are friendly & helpful ;).

The next version should feature distributed hosting on several servers, and we are working hard on adding metrics/analytics to let you know what exactly is happening in your games.

What do you think about it? If you have projects, we’ll be very glad to help you too, with or without Stormancer :)

Check our website at http://www.stormancer.com/ (and some tutorials are on: http://blog.stormancer.com/).

Cheers!

What competitive advantages do you offer over other services? Why would I pick your platform?

What is the operations experience like? If you want to talk about "cloud" services (I for one feel a little ill every time the word comes up these days) you need to have first-class deployment and monitoring tools. How easy is it to roll out updates? Can I do A/B testing with your platform?

When you say I can roll out "customizable code" is that just market-speak for "I have to write it all myself" or does that mean you have a code base of highly flexible feature sets that can be mixed and matched by customers?

How do you deal with service outages, both planned and unplanned? Do you have standard support contracts available? What happens if my game is attacked by a malicious party? What if someone else's game on your platform is hacked, and I become collateral damage? Do you have legal protection ready for such contingencies?

What does pricing look like? Is it competitive with existing solutions?


These details are not very clear from your post (and, nothing personal, but I'm not going to comb through your site).

Apoch listed a number of concerns that matter to businesses trying to run a production environment. If you want to make a business out of providing a platform, that's a good list of questions to start with.

Separately, it might be helpful if you described in a little more detail what it is you're looking for feedback on.

For example:

- is the feature set attractive? (For me, websockets-only is kind-of a deal breaker, for example)

- is the SDK usable for particular kinds of games? (I have no idea -- docs and examples are needed to evaluate that)

- is performance up to par for particular games? (Again -- some examples that can be tested would help here)

- is expected pricing in line with value? (I understand it's fee now, but nobody will want to spend a bunch of time driving into a tunnel that might be very, very steep at the end)

These are all different questions you might want to be asking, depending on which stage of development you are in, and the way someone would evaluate your offering would differer based on which question you're trying to answer.

Thanks a lot for these replies and the follow-up questions :)

I wrote this post more as a starting point for discussion than a sales pitch. Developing everything would have been quite long.

That's a lot of questions, I will try to answer them all.

- I understand your point about the cloud. I agree that it's easy to take any web service and put the "cloud" sticker on it. Let's just say that we built the hosting platform and we provide it as a service running on an infrastructure itself available as a service. That’s as cloud as it gets.

We are currently in the first stages of our development. We have the service working, used by developers without much network & server management skills. They are very satisfied, but the platform & tools are clearly not in the state we are targeting.

The platform is currently in beta, we don't offer strong SLA. I understand very well that it can be a real issue, but we’ve had very few outages since starting the beta (less than 8 hours in the last 12 months of beta), and we really can't ward our users against outage from our own service providers (currently Azure). However, we monitor issues & outages and communicate about them and about the resolution process. We currently offer support contracts on a case by case basis.

From a security point of view, we have put in place several security layers on our side to ensure isolation of application containers. We don't handle data storage yet because we want to be sure we can do that while enforcing a good enough security level. So right now we don't store your data. (But developers may well use databases like SQL Azure, tables or clearDB mySQL offering from the same datacenters)

For better isolation & performance (and direct client-server communication) it's possible to deploy dedicated instances currently on request and in a few months from the management portal. For even more security, it could even be possible to deploy a Stormancer cluster on your own infrastructure, whether cloud based or not.

We provide some security through SSL for websocket and HTTP. All API calls are secured through a symmetric key system (we may switch to JWT before the end of the beta) and monitored.

Legal protection is a tough subject. We have it for everywhere around the world... except the US & Canada. For now.

We provide an SDK which abstracts a lot of things like object serialization, communication channels (through a route system), room load balancing & lifecycle management (we call them scenes). Our SDK also offers open source multi platform client libraries (not enough platform now, we are building new libraries on request however),

The server SDK is written in C#, and designed for non blocking logic The customization pattern is behavior based.

We currently provide only a few turnkey behaviors on top of this framework, it's clearly something we want to work on. We are going to open source them on github too. We are doing that only a step at a time, mostly to take the time to clean things up. For instance, if you need something as simple as a realtime push or broadcasting server, you can do that without coding anything at all on the server. But you can also customize these components with your logic (and your code!), or create something from scratch.

For instance, we are also working on a matchmaking module, and another which will handle the base features of turn based games. We also make sure (when possible) that these turnkey components can be used together.

The available tools are:

- An open source command line system. Currently only works on Windows, we need to add some alternative authentication logic on the platform to port it on Linux. If needed, just ask.

- A local emulator (windows only too. Same as the command line, Mono support is on the roadmap, could be moved up on request). Manageable from the cmd line, and as soon as we get the time from an included web application.

- The management portal. Should go open source too, as soon as we get time to do some code cleaning.

- Management libraries for .NET, PHP & javascript

- Server library currently distributed through nuget.

- Client libraries currently for .NET, Unity, javascript and soon C++.

Network

Currently, it's websocket, so TCP (SSL) only. I agree that it requires a lot of tweaking to get the most out of it, and that's really not adequate for fast paced games. But on the good side it works almost everywhere, even behind transparent proxies for mobile games.)

Good news, Raknet integration is on the way: It will bring UDP and unreliable messaging to the platform.

What did you mean when you wrote websocket only was a deal breaker? Do you need unreliable messaging (UDP) or HTTP web hosting?

HTTP web API hosting is something that some developers asked us, so it's on the roadmap, but with a low priority because it's rather easy to integrate Stormancer into an existing web application hosted elsewhere.

Right now, it's possible to build custom, authenticated HTTP APIs (curl compatible) for Stormancer server apps. This enables full control of the Stormancer app from your own web servers for instance, without having to deal with bidirectional communication.

Deployment

Deployment is done through the command line (> stormancer deploy). Ultimately it's only an HTTP PUT request, so developers could very well build other tools on top of it, or integrate it into custom deployment workflows. We keep the 10 last deployments (configurable on request) and it's possible to rollback to any of them in the management app. Deploying a new version doesn't disconnect players by default, as different game versions can live side by side. However new connections happen only on the newest deployment.

We might add support for different environments in the future (ie production, staging...). However the feature can be replicated by creating 2 apps.

Monitoring

Monitoring is currently possible through a persistent logging system, and we should roll out a metrics system before the end of July. We are clearly not satisfied by the situation here so we are working on it. Our monitoring stack runs logstash & Elastic Search. I would be happy to get the opinion of people experienced with this subject about this stack.

We don’t do turnkey A/B testing right now, as we are focusing on the hosting/networking part. However, it should be possible to implement that through parametrized scene creation, custom metrics and some game client logic. Not trivial, but not overly complicated neither.

Building something better could be definitely feasible, however I would need to think more about use cases for realtime, synchronous apps A/B testing.

Samples and benchmarks

We have a few samples in Unity, javascript and native C#. For instance we made a very simple multiplayer version of Angry bots (explained I a two-part tutorial: part 1 and part 2), and a quizz game in C#. You can find more samples and tutorials on our blog.

We are working on a full quizz benchmark app (requested by a customer) including Database connections and with simulated players.

Apart from the free plan, Stormancer will be available as Pay as you use.

Developers will be able to buy compute units of different sizes with a base cost of 20€/month (300MB RAM, 1 CPU share) .This is not set in stone however, we want to adjust that with the data from our benchmarks and feedback.

What did you mean when you wrote websocket only was a deal breaker?

For many games, the significant lag spikes of TCP (which underlies websockets) are not a good match, so UDP is better in that case.

For other network infrastructure, plain TCP is easier to manage with existing networking tools than Websockets. But it sounds like you're not actually supporting developers hosting their own copy anyway?

Yes, I agree with you on that. The issue can be somewhat mitigated but it's far from ideal. That's why we have UDP on the roadmap. As our first requests focused on features like chat and reliable push or duplex messaging and cross platform compatibility, websocket has been the first transport we have implemented.

Raknet becoming opensource is something that as reduced dramatically the cost of adding an satisfying UDP transport. :) So it's underway.

We didn't consider plain TCP until now because websocket is essentially TCP with an HTTP handshake. Adding your own socket listener is not feasible neither, as the firewall configuration wouldn't allow that.

Right no Stormancer is not hostable outside of our infrastructure . However it's something we have in mind, depending on customer requests. The design is rather modular, with the game hosting servers working as a distributed app exposing its own API and pushing logs to a configurable endpoint (currently a redis queue).

We have somewhat a dependency with Windows Azure for Azure Table & blob storage but we built things to be able to plug another NoSQL DB & storage system without to much hassle.(Dependency Injection + generic interfaces) . We are considering ES as a replacement for Azure Table for instance. That would enable a few interesting search features in our scene system which are not possible with Tables.