Ptifalls of using mono's networking for MMO games

Unity Engine
1

Me and my team are currently looking for alternatives to deploy a simple (if that’s possible :wink: ) MMO game with unity.

We already have experience with deploying custom client/server solutions for games and custom applications, but they all have had a different scale of this next project. But anyway, we have developed a custom solution for serializing/deserializing data, as also for the communication protocol itself (to be open sourced soon).

We’ve been looking for a possible solution for client/server setups, and while RakNet looked like a very good solution in many ways, the custom unity implementations on top of it just makes them impossible for us right now to use them out of the box.
But looking at the other custom solutions, I don’t quite get what’s their real advantage over a custom made TCP server, for example. Is it just the api for rooms / chat / positioning that they offer out of the box? Or are there improvements going on protocol-wise, that I will probably miss if using a custom solution?

Thanks!!
Cauê

2

Hi waneck,

I can speak to the benefits of using a 3rd party server solution. I’m part of the ElectroServer team, so while much of what I have to say is ElectroServer-specific, it (in most cases) applies to the other major servers out there.

You specifically mentioned the built-in ability for rooms and chat. Yes, that is useful. But that is just a tiny sliver of what most modern servers provide. I could go on for a long time about various features so I’ll just touch on a couple more big ones that make this type of thing attractive to game devs.

Scalability
In my opinion, one of the biggest things that something like ElectroServer (ES) provides is scale. As you may have experience, it isn’t all that difficult to create a server of your own. But it could take months or years to make it scalable to tens of thousands, or hundreds of thousands of concurrent users. Assuming that you need to scale to at least a few thousand users, laying down a few thousand $ for something that works could save you much more than building it…by orders of magnitude.

Extension model
Most good servers give you the ability to extend its functionality through custom code that you write that will plug right in. In that way you can make use of the scalability of the server but still use your own custom code.

Connection types
ES gives you the ability have the server listen on many ip/ports at the same time. Each connection listener is of a certain type. So, you can have a TCP listener, UDP, or HTTP (and for Flash RTMP for video streaming). HTTP is used to get through firewalls by acting like normal HTTP traffic.

Protocol
If you custom-write your own protocol for your own server, then you’ll likely achieve the smallest message size possible. But, that takes a lot of time to do and you might have to refactor it later if it doesn’t fit your needs. ES provides an extremeley flexible protocol that maintains datatypes and deep-structured objects, but is still light weight.

Lowering risk
To a developer this doesn’t hop to mind quickly as a big deal. But to managers it does. If you write your own solution then you run the risk of server crashes, performance problems, scalability issues, etc. Why not use a product that has already had these problems, and solved them.

There are certainly many more reasons (stats gathering, admin tools, security, etc) that I won’t get into. Hopefully this was of some help, and good luck with your next project!

3

I think Electro Server is a step back from SmartFox in my opinion, still waiting on the official release of SmartFox 2 so I can compare it to Photon, they have similar models though, Raknet that is in Unity can be used for an MMO as long as you know what you are doing. Other solutions include Photon/Neutron along with Netdog and Cafu, there are plenty of others out there that work with Unity and of course you can write your own, it is easy enough to do as long as you understand the in’s and out’s of what needs to run on the client and what needs to run on the server along with simplified packet utilization. In truth it doesn’t matter which one you choose as long as the one you choose you stick with it. I have seen others talk about Badumna, but haven’t personally used it, there are a few others lying around the threads, heck I have even gotten Unity to work with the XBox’s XNA network engine already, so just about anything is possible.

4

zumwalt,

I hope this doesn’t hijack the thread- but you said “I think ElectroServer is a step back from SmartFox”. I’m curious in what way you mean? ElectroServer 5 is superior to SmartFox in almost every measurable way. I’d be interested to hear more about why you think it is a step back. ES is better performing, has more features, scales better, and has been around longer.

Anyway, hopefully anything said here will be useful to waneck.

5

Scales better is hard to compare as the page could barely be more archaic and lacking with their single list of feature that goes into nil detail for example on what the distributed mode really means.
Thats neither inviting nor strengthening the trust when one compares to SFS or Photon which are both industry proofen.

Also going by the documentation it as a matter of fact does not scale at all. (http://www.electrotank.com/docs/es5/manual/ - server overview - server versions)
You can only have a single registry server (server that actually performs calculations) with the other nodes only serving as proxy to handle connections.
That is from our perspective as game devs not scaling at all, thats just single server mode with distributed connection handling but it still won’t get you more users onto the game as the single instance calculation node will remain the major bottleneck.

Also the listed UDP is another fake feature, as the documentation clarifies that it can not be used as general protocol, the client can only send plugin requests and pings through it. ((http://www.electrotank.com/docs/es5/manual/ - server in detail - udp)

Longer around is no valid reason for or against anything but especially not an intelligent base for technology comparision, otherwise Linux would be the primarily used OS, not windows followed by OSX :wink:

But its nice to have more options to choose from and there might actually be cases where you potentially favor it although its more pricey for less features.

6

dreamora,

It is kind of late here, so hopefully my responses are coherent.

ES5 does scale better. Electrotank posted ES4 numbers that showed scaling to several times the amount that SFS posted on their site. We’ll post ES5 performance and scaling numbers soon.

Regarding UDP: UDP is useful for fast, lightweight messaging. This type of messaging is only needed when within a game (or other application). When you are in the game plugin messages are the way communication occurs. Which is why ES5 supports UDP messaging for plugin messages. I can’t think of a reasonable use case for UDP that ES5 fails on.

You mentioned that Photon and SFS are industry proven. I agree. And so is ElectroServer. ElectroServer has been around longer than any of them, and is used by companies like MTV, Mattel, Webkinz, and many others for their massively multiplayer games.

Finally, I agree that more choices is a positive thing. I make no disparaging statements about SFS or Photon. They are good solid choices. I know I’m biased, but I still see ES5 as being a better product.

7

Hey guys!

Thank you all for your answers!
Well, to be honest I’m more confident to deploy the game with our own solution. We already have a great workflow for handling many client/server issues (to be open-sourced soon. :wink: ), and I feel that this way we can scale the servers based on our needs. My main concern up to this moment was if there was some black magic involving protocols that I wasn’t aware of. For example, RakNet does seem to be a very evolved protocol for gaming, where the messages are much more slick than a TCP solution, and it seems to handle well packet losses, for example. But I have heard about some good solutions built even on top of TCP, and since in this game the massive multiplayer interactions will still be limited to chat, positioning and friendly interactions, we still won’t need any complex synchronization/prediction algorithm.

Also I’m getting very interested by now on non-blocking i/o on the server-side using os polling. I look at the number of connections a program like Yaws can handle and it’s pretty amazing. This is a great benefit of being able to use our own server solution.

8

waneck,

No problem. I wish you luck with your game!

9

I just thought I’d weigh in on this thread, I work as a client programmer for an indie MMO developer, and we’ve successfully made a couple of MMOGs.

When it comes to the networking library you use, you can use a custom gaming UDP protocol, but I’d only say it was necessary for twitchy FPS games and the like, TCP is fine for an MMO (especially a simple one!).

I’d certainly advise against Smartfox, I’ve not worked with Electroserver though. I hear good things about Raknet, but to be honest for a simple MMO, I’d create the server yourself, especially if you plan to do more MMO stuff in future. You can create a nice simple protocol which will serve your needs, and you should be fine. The main point we find our server bottlenecks is at database access, so it’s fairly important to get your database right.

As for non-blocking, polling is one way to do it, though we use threads.

Good luck!

10

async sockets would be the way to go if unity wouldn’t fly around your head all the time doing so.
Guess you use threads for the same purpose and feed a queue with information for in unity usage?

11

Indeed, if the server was built on .NET then async sockets are probably the best way. Also if you happen to be using a language which is non-threaded, you’ll have to use multiple processes.

As you mentioned, feeding a queue of information for Unity is vital. Unity doesn’t allow you to create GameObjects on anything except the main thread, you may be able to modify existing GameObjects but that’s kind of playing with fire if you ask me.

12

spectre1989, thanks for your input!!! It’s really nice to hear from someone that has already actually made it.

I’ve got curious on how much info do you query on the database regularly? Or the bottleneck is only because of writing/transactions?

Thanks again!!
Caue

13

The bottleneck is due to reading or writing. Our server-side geniuses wrote the server tech first, and then just looked to see what database queries where being called most often and causing bottlenecking, and then set up a caching system so the results of these common queries are cached and then refreshed from the database every so often.