More than a year ago I did a series of load-tests to find out how many players my game-server could take. My goal was to be able to host about 150 players per server. Unfortunately, in the last of those load-tests it turned out that around 70 players things got really messy.

A few months later, I did some major refactoring of my networking code, but in general, my feeling about Unity's built-in networking (which I built-upon) got worse and worse - and it seems like I'm not the only one. The major problem is that if the game server doesn't scale well (and 70 players per server is not scaling well at all), this means that I'll need a lot of servers to support even a small number of players - which means I'll have pretty intense monthly costs without generating a significant income. Besides, requiring many servers in the approach I'm currently following requires some rather tricky things to make it work (for the technically interested: each client can only connect to a single server in Unity, so I'd have to do inter-server communication either via custom-sockets or the database ... both something I really wouldn't like to implement). Unity Technologies is very clear about its implementation of multiplayer: It's designed for small multiplayer games - not for anything on the scale that I'm planning.

Another issue that arose in the world of multiplayer-games first, and then in my mind is that the business models are heavily going towards "free-to-play". Everything seems to be "free-to-play" these days. I really don't like this model at all because in the end, it's not really free: You can play for free - that much is true - but then you can spend lots of money on in-game-items. So, what really happens is that many people "play-for-free" and some people spend a lot. I don't consider that a particularly "balanced" way of financing these kinds of games. It's tempting for the players - but IMHO, that's the only thing it is. A monthly subscription fee is much more fair: Everyone pays more or less the same amount (you might get discounts for paying for longer periods in advance). Also, things become much easier to calculate: As game service provider, you know how many players you have - and the number of actual players determines the turnover. That simplifies calculations - and simplicity rules ;-)

For a while, I had been considering giving into that flow of events going towards "everything is now micro-transactions; tell them it's free-to-play and then rip'em'off with in-game-items". I resisted that temptation. However, I reconsidered my original idea of making multiplayer "for-pay-only" and single-player the only thing that's free. So, I will give players the opportunity to get into multiplayer - but I'll add some limits and priorities. The reason is simple: Those who are paying, are paying for the servers. So if you're paying, you'll be able to play unless the servers are full with other paying players.

If you're not paying, you might catch a slot on a server when it's idle otherwise. But when more paying players are coming, you'll have to make room for them. Also, you'll only be able to play in the first three levels. That's fun - but you won't get to see the really interesting stuff or be able to discover the other Tracers (which you have to earn by going beyond Level 12 with the most advanced Tracer you currently have - which requires collaborating with 19 other players ... so it's not how much money you invest in the game that determines what you can play with - but instead it's how much time and collaboration you invest).

I think that's a fair and balanced approach to "free-to-play".

Anyways - with these thoughts, the results of my load-tests became more and more of a PITA. The less players I can support per server, the harder it is to get this whole ball rolling in any reasonable way (and that, of course, includes how well development of RaMtiGA comes into reach).

So ... yesterday I came across a couple of forum postings discussing alternatives to Unity's built-in networking. And one stood out: Photon. It's a solution that provides highly-optimized scalable networking with the flexibility I need. Interestingly, just like Unity, it's built with a native C++ core (for super-optimized performance) but has a .NET / C# layer for implementing custom logic. What I'm hoping to achieve with this is to have one networking layer that does mainly just that: Distributing messages and a little bit of "sanity checking" (in other words: cheat-prevention). That part would then be implemented purely inside a Photon-server.

I'd still keep Unity clients and Unity game servers - but those game servers would have significantly less responsibility. In other words: Less to do per player. In yet other words: More players to handle per server. The decision is not yet made - I'm currently trying to figure out the chances that my theory will play nice in practice but so far I have a good feeling about it. Maybe it's just a crazy thing about the name: Photons are particles of light, and what could be better than a game built of Unity and Light? But from a more down-to-earth perspective, this approach still looks very promising and like a solution to the most difficult and frustrating problem I'm currently facing in this project.

Interestingly, I've started feeling how I can invest more time into this project again (time for working on Traces of Illumination had been extremely scarce during the last year - as you probably have noticed) ... maybe the time just wasn't ripe, yet? Maybe the time is now finally ripe for the next steps? Oh well -time will tell ... you'll be sure to find out - if you just keep on checking back to this site ;-)