mitmachen! anmelden   Suchen
RaMtiGA - Raising a Middleworld to its Golden Age
RaMtiGA - Raising a Middleworld to its Golden Age: Blog
Jan 13

Erstellt von: Jashan Chittesh

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 ;-)


2 comment(s) so far...

AW: Mixing Unity with Light? Looking into Photon

Hey jashan (how I know you from the Unity forums).

At the moment I am at the point you were when you wrote this post, and would like to know some of you thoughts on Photon compared to Unity's built-in networking. How it has affected your game structure (physics calulations, collision detection etc)? And of corse whether you are still happy about it?
At a later point I would maybe like to ask you for some guidelines or points in the right direction on how to cheat-proof your system, if you, as I understand, do not let the server control everything?

.... I have been reading alot of your posts on the Unity forum. You always seem to pop up when the topic concern networking :D ...

Von Kenneth am   2010-09-25T13:27:42

AW: Mixing Unity with Light? Looking into Photon

Hi Kenneth,

thanks for the comment and question and sorry for the somewhat late reply. I was on a trip to Italy and am just catching up with things (it's cool to be able to do small stuff like approving blog comments with the iPad, though ;-) ). As moving over to Photon will be a pretty massive amount of work for me, I'm still postponing this to a later version of Traces of Illumination when I've completed some more of the levels and polished some other aspects of the game. I'm just about to release a new version based on Unity 3 - but there's still some porting I need to do on that end as well (in particular make some of my shaders fully Unity 3 compliant which they are not yet).

The main difficulty with porting a project that is using Unity's built-in networking is that it's so super-easy to create lots and lots of RPCs. And that's not as convenient to do in Photon. So while I have my own RPC for pretty much everything in Unity's networking, I'll probably do some major consolidation and have less RPCs with more parameters. So instead of having RPCThisEvent, RPCThatEvent, RPCThatOtherEvent - which made sense in my design as long as being built on Unity's networking, the approach in Photon will more likely be RPCEvent(int typeOfEvent).

As mentioned in a forum posting on the Photon forums, I will try using an approach with having a Photon server that connects all clients and handles a significant amount of the logic, I'll also have that Photon server "check back" with a Unity based game server. So, I'll have a much better distribution of responsibilities:

The Photon game server will be handling simple logic checks (is this player allowed to use that PowerUp right now, do the current player positions make sense or is anybody cheating) as well as all persistence handling (store state to the database, get state from the database). And the Unity based game server will handle much of the physics stuff, in particular collision detection. Basically, anything I need an authoritative server for that is easiest to implement in Unity and that would be a mess to implement with just barebone C#/.NET.

I feel I will be happy about it once I've done the porting - but obviously, I can't tell for sure until I'm done with it ;-)

Regarding making the system cheat-proof: Just make sure to check everything on the server that matters, and be aware that things you may not consider relevant might be if someone is smart and uses those "not-so-relevant"-things to trick your system. What I'm doing quite a bit is let the client do whatever they want to do (which gives me instant feedback for the players so they don't notice lag as much as they would if I'd have to wait for the server to send the result of the check) - but ... I pass that information to the server and other clients only after sanity checks. So, if a player hacks the client to have unlimited power ups and uses them, all they will do is mess up their experience because those power-ups will have an effect for them ... but not for everybody else. So that'll end up giving them just a rather frustrating experience ... which I feel they deserve when they mess with the client ... but it won't ruin other player's experiences (except, of course, when they start yelling and shouting ;-) ).

Hope that helps a little ... and I'll keep posting about the progress (I know I know, it's slow ;-) ).

Von Jashan Chittesh am   2010-09-29T15:30:56

Ihr Name:
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Geben Sie die angegebenen Zeichen darunter ein.
Kommentar hinzufügen   abbrechen 
Copyright 2008-2009 by Jashan Chittesh   Nutzungsbedingungen   Datenschutzerklärung