Seamless Server Integration Options

I'm curious if anyone has found any alternatives to Photon for seamless server integration for an MMO game built with Unity.
We have been eying uPikko, but I dont see that working out for indie developers and am trying to find some alternatives.

Anyone know of anything available I should consider?

 

Have you actually talked to MuchDifferent about Pikko? They're a very nice bunch - and are actually a not-for-profit.

Otherwise you have the DIY routes, and I believe Badumna might be useful : http://www.scalify.com/

http://forum.unity3d.com/threads/95277-Networking-Server-Comparison-Chart

 

uPikko is by MuchDifferent.

It's not ready yet and I don't think their business model for that is going to work for indies.

 

Then if that doesn't work out, I see you having three options:

• Stick with photon [It's painful in my experience, but people have done it].
• Try another solution, e.g. Badumna.
• DIY - Allows a very lean powerful codebase that solves the problem and can be modified as needed.
• Magic a solution using ordinary networking.

From a networking POV we'd need to know how many people are going to be in an area, how seamless you want it to be [e.g. can we use regions, rooms and instancing], how people interact with the world [e.g. physics is *bad*, how fast paced is it etc.]

 

I'm the Lead Programmer for ElectricCrow Gaming. How we were planning on setting up our Servers is a Hybrid of Seamless and Zoned. It's based off of WoW and how HeroEngine does seamless. We would have "Regions" which each would be 512meters by 512meters (using a 1 Unit = 1 meter scale). Each Region would be hosted in it's own Headless Unity Instance. I was planning on having each Region Connected to the 8 regions surrounding it using uLink's P2P connection and then the player Handoffs between servers would be handled through uLink's P2P Handoff method. However reading through the documentation on it it seems the whole level should be reloaded when doing that because it doesn't take care of deleting any of the Objects that the last connected server created. So it seems like it's going to be WAY to slow to use in a seamless setup.

 

So each region would be it's own area and there is going to be a small 'jump' between regions?

Is so now the question is how to make the transition faster. If not, then I think you'll find that you might run into issues when a battle starts on the border of two regions.

Assuming the former, keeping track of everything spawned in a region should be fairly straightforward, making deleting them pretty easy. To load new area's, I'd look into Unity's async loading.

 

We have a Custom Seamless Terrain paging system Client side that loads in level additives on the fly as the player walks around. On the Client everything should appear seamless with no loading screens or anything. I guess if there are some minor little pauses when crossing Regions that's ok but it should be barely noticeable. I've also created a Custom Area of Interest system so the Clients only receive the updates for the objects with in range of them. Now comes what's the best way to Ghost the Players and Objects that are close to region boarders between servers...

 

Yep, that is an interesting part.

I think at the end of the day it's a matter of being smart with your instantiating and RPC's... and putting in a ton of blood sweat and tears. You need to architect it so each region can act seamlessly with each other, and then build ontop of that the logic to show the client the world.

Last big question is how many players/regions are you expecting? If it's not that many you can simply stick a bunch of regions on a few beefy servers on a fast network and call it a night - let the OS take care of load-balancing it for you. If you have a ton or regions, or a ton of load then you night need to look into dynamically instantiating and moving regions...

 

A little off topic but it might be good worth considering making your regions arbitrarily sized instead of fixed size:

1. Some areas are going to be more popular than others.

2. From what I understand the game is going to be fairly open but I expect there's still going to be natural features and the like which you can use to support occlusion between regions(i.e. less "ghosting"). The more your regions are bordered by natural boundaries (tall mountains, thick forests, etc) the better, but it might become a bit too obvious if your "natural" borders are all 512m apart

 

We are planning at the very least 150 regions spread over 5 Climates (Like Continents in WoW). To keep the right ratio of Player Owned Parcels to Wild Parcels we need at the very least 30 regions per climate. I still need to do some more research on it but I had been talking about using uZone to spin up and down regions depending on if any players are around it or not. That would reduce costs for us by reducing the number of server instances we need running at any one time. I need to look into how I would set that up using Cloud hosting though since I have pretty much no experience with Cloud hosting.

 

Think simple.

Unity is single-threaded. That means on a simple dual hex machine [can be rented for at $450/month*, possibly much cheaper] can have ~20 regions - each with it's own dedicated 'core'. Now, it's unlikely all your regions will be at heavy load all the time, so you can quite easily push that to 50, 100, or 150 regions and use the OS to manage load.

The benefits of this is that it's easy to do, and every region will have superextremeultimate fast interconnections .

Then in terms of scaling what one can do is boot up multiple machines

Dynamically loading/unloading zones sounds like a good idea [and may be useful for disaster recovery/updates] but in terms of scaling it's not going to help much at such 'low' levels. A unused zone will only cost you a few dollars a month in memory - the code to 'turn it off' could costs thousands or tens of thousands.

*From the sounds of it you already have huge sunk costs in hardware, so the maths is even more in the favor of this kind of thinking.