How plausible is it to create an open world MMO in unity, using Photon’s Server, that can have hundreds of players connected on a single server at once? Basically set up similar to Eve: Online.
I really like how that model works where every player action means something, and the world and story is therefore very player-driven.
The graphics are voxel based (like minecraft) to minimize performance hits.
Also, if this isn’t possible with Photon, if you have any other suggestions of ways to pull this off, I’d love to hear them!
But are there any with quite that scope? I’m talking hundreds, maybe thousands of clients all connected and exchanging data with a single authoritative server.
Have you had a look at Badumna http://www.scalify.com ? It was designed with single unsharded worlds in mind. It uses a hybrid of a P2P architecture and client-server. Most traffic is carried P2P so you have almost unlimited scalability - the network is the server. Client-server is used where authentication and arbitration is required. You can try it out for free.
That is the thing… P2P is REALLY hard to prevent cheating… You need a server that says “Yo, this data is not matching what I have… something is wrong”. This is one of the reasons for an authoritative server. If you are planning on doing something on the scale of eve: Eve has a lot of servers, and doesn’t do voxel world sims… think about that for a second.
P2P means you will need to trust that what the user sends is good data. You can do checks to see if it is within a range of “ok” parameters.
Ok, tough question time… How much do you know about networking? How do you plan on running your simulation? Does the user only control one object?
As I slowly build up the core of this game, I’m slowly building up my networking knowledge. I’m dreaming big but I’m going to be starting pretty small. Yes, the user controls only one object, kind of like in Eve the user controls only one ship. Given this new information on networking, this is what I’m thinking. The main thing that I want is my world being a single sharded game world. The game-world is split up into multiple regions. One option would be to have a scalify server running all the regions. Another option would be having multiple authoritative photon servers, each running their own region of the world, and when a player moves into a different region, they switch servers. I guess in that case I would have to have all the photon servers sharing information with eachother as well.
You might be able to trick the system into working… To do something like this, you would move the world around the user. This means the user sits at origin at all times. You can load bits of your voxel data into a visible buffer, then load it into the scene where it should be. You would also drop data you aren’t using. This will make it seem like the user is moving.
Now, I am not sure if this will work with scalify, as their system is based on object positions. This you might be able to trick this as well… by saying that when the user is in view, they are “here” (ir, translated to world) in the world, not at 0,0,0
Another thought… If they have abstracted their NetworkView object (this is what unity uses), you might be able to use double precision for locations, then translate it on the local. Note that this would double the traffic.
Yes, I will certainly start building it ground up with multiplayer. Right now I have some multiplayer functionality implemented with photon cloud, but there is no way cloud is going to work in the long run.
In that case I think my world will end up being too large for Scalify. I’m guessing that moving the world around the player is a workaround for having a maximum world size? That is a smart idea. Since I’ll likely do multiple authoritative photon servers, I’d imagine that moving the player around the world is less expensive than moving the world around the player though.
Admittedly, I’m not sure I completely understand your suggestion about double precision as I’m not too well versed in networking yet. It sounds like it could be another workaround for Scalify’s size restriction.
What I want to be sure of is that I’m using the best server system to run this sort of game and maintain a good level of performance before I dive into anything. It seems like Scalify might not be able to do it, so do you think that the multiple photon server idea is the best way to go about it?
As i am working on a multiplayer voxel game at the moment, let me share something you need to consider with an authoritative setup in a voxel game.
Memory!
Voxel worlds often take up quite a bit of memory. If people shouldn’t be able to alter the world client side the server needs infomation of it, this can be a bare minimum, but can still be heavy. Now on the client side you can just load/unload regions as people move around. However the server needs to have infomation of all the regions which could possible be insane amounts of memory.
Now when you mention voxels, is it only the style or do you actually have a sort of voxel engine where every piece of the world is a voxel that store some sort of information.
Furthermore, do you use Unity physics in your game, or any kind of physics? Then you need to write your “own” for a Photon Server which can take some time to get right! (We did it where i work).
The world actually isn’t alterable at all, the voxels is just basically a style. Everything is made up of cubes, but for the most part they are simply meshes, so I hope that saves me some memory.
As for terrain, I may just use unity terrain, and then just objects and structures and such are made of voxels. Do you know if Unity terrain would be more expensive than a single layer of voxel terrain (since you can’t dig or alter the world)?
And yes I use the Unity physics engine. Do I really have to write my own physics to use photon server then? That would be an unfortunate challenge!
That is a tough one to answer… I don’t quite understand the scope of your project or what you plan on doing. Can you tell me a little more? Feel free to do it in private message if you don’t want to talk about it here.
You want to have a really solid concept for what you want to do in the game. I suggest writing it all up and sticking to it. It is a nightmare to switch networking systems mid swing. Your goal should be to do it correctly the first time.
As for the floating point / double. Floating point has half the size of a double. With doubles, you can map all of planet earth to right about the meter. With float, maybe down the block. So if the goal is to have this really massive world, say like minecraft… you will have to do some magical work. This will play a huge role in how you develop the networking back end.
Hi Julian, Just to clarify, Scalify does use floats for synchronising positional information by default. If your are planning on positional accuracy to the nearest centimetre, the largest position you can represent with a .NET float is 99,999.99 which is about 100km. So this would give you a game world of size 200km by 200km which is 40,000 square kms. If you drop the precision to 1 metre, your game world would be 100 times bigger (and so on).
You also have the option of defining a custom position property on the entities (which use double). Scalify network will automatically synchronise this and then you can have the precision and size that you wish. Geoff’s last post on this thread explains the problem very clearly.
The key benefit of Scalify is that you don’t have to worry about managing all the servers and the communication between them as it is managed transparently in the network.
Alright, well that is definitely good to know, so I won’t write off Scalify just yet. Will I be able to use the unity physics engine with Scalify? That would save me a lot of time I think. Also, is there a way around clients being able to cheat easily?
You can certainly compute the physics for objects locally while using Unity’s physics. In terms of your question about clients being able to cheat easily - you need to figure out what is critical and non-critical wrt your game. Scalify allows you to send critical updates using central arbitration servers (such as result of a puch, or a combat operation, etc). All non-critical updates such as chat, running around in the world can be sent directly.
There is also a distributed validation module that provides further cheat prevention for all game updates. When enabled, this module will select validators for each client in the network and use them to compute the update for that client. This will provide the same security as client-server while using a decentralised model so that your game is highly scalable. You can read more about this in the developer documentation.
