Changing scenes in MMO
Options
Hey all, I have a quick question that's been bugging me for a little while. How should I handle changing scenes when following the MMO framework?
Here is some background on our setup: vanilla MmoDemo single-server setup (we're in the process of developing multi-server) with a slightly modified but, so far, fundamentally the same implementation client-side as the UnityIsland MmoDemo.
As it stands now, players enter to a login scene and after clicking "Start" the actual Photon connections are made and the player is transitioned to sceneA. Everything works perfectly in sceneA; other players are visible, the text over their heads works, the interest area view distance works, all that stuff, but when the player clicks on the object that sends them to sceneB suddenly none of it works. Even if they click the object that sends them back to sceneA they will still be without anything working and can't see the other players (who are actually still there).
The MmoEngine is set to DontDestroyOnLoad so its staying with the player throughout all these scene changes, but for some reason it loses functionality after the transition from sceneA to sceneB, but doesn't in the switch from the login screen to sceneA. The only difference between these is that the actual connection to the server isn't made until the transition to sceneA from the login screen.
Here is some background on our setup: vanilla MmoDemo single-server setup (we're in the process of developing multi-server) with a slightly modified but, so far, fundamentally the same implementation client-side as the UnityIsland MmoDemo.
As it stands now, players enter to a login scene and after clicking "Start" the actual Photon connections are made and the player is transitioned to sceneA. Everything works perfectly in sceneA; other players are visible, the text over their heads works, the interest area view distance works, all that stuff, but when the player clicks on the object that sends them to sceneB suddenly none of it works. Even if they click the object that sends them back to sceneA they will still be without anything working and can't see the other players (who are actually still there).
The MmoEngine is set to DontDestroyOnLoad so its staying with the player throughout all these scene changes, but for some reason it loses functionality after the transition from sceneA to sceneB, but doesn't in the switch from the login screen to sceneA. The only difference between these is that the actual connection to the server isn't made until the transition to sceneA from the login screen.
0
Comments
-
The MMO example is actually not meant for scenes but single continous worlds.
As such if you would switch scenes you scenes would need to still retain 'continous coordinate spaces' and you will need to modify the framework to have knowledge of 'which coordinate space means which scene', either on the client or the server side (client is obviously easier as it does not mean any data serialization so you can even provide the knowledge to the server)
If you would like to work with Scenes then I would use Lite and backport the InterestArea concept to it instead so you get the required seperated coordinate spaces.
The reason why the transition likely kills it is keeping the connection does not help if you break the interest area registration which is likely going to happen if you kill your local actor upon the transition for example. You would need to replicate what the original login did to register yourself again within the world as an actor.0 -
Ahh I see, that makes sense. I was approaching the problem the wrong way. My intent was to basically make each region into a different scene. The only problem I see with doing it all in one scene is with the massive size of the game world we're creating we'll go beyond the limits of Unity, plus you would run into floating point precision issues in the outer areas. If I were to switch it over to Lite (Loadbalancing) then I could effectively have different "regions" where players cross over a border, have a loading screen, and appear at the edge of the next region, correct? Would this also allow for a "global" chat system? The end goal is to have the whole game feel and function as one complete world but "behind the scenes" it would actually be broken up into separate regions.0
-
for a global chat you would need to expand Lite.
but thats no different on MMO.
Reason is that trying to pull of a single global chat is NEVER going to be easy (its a massive amount of traffic you are asking there, a single spambot can take down your game if it operates right or you don't have proper handling in place, due to the traffic explosion).
Thats the reason why no MMO has it, not even EVE where all players are in a single world (unlike all other MMOs where the players per world are limited to a few thousand, not the 60k CCU+ EVE has)
Its hard to maintain good performance and reasonable traffic also for low bandwidth users if you have thousands of users in an unmoderated chat spaming the line.
If you naturally have a limited global chat like guild or party, its a whole different story but those are not unmoderated as guild admins / party managers can handle spamers0 -
Well yea, when I said "global" chat I meant a chat that worked across any number of regions, like between guild members and such. Having a purely global chat is never a good idea (unless, as you said, the population is limited).
I've been doing some research and it seems like it should be possible to create a second - or even third - layer of coordinates in the Unity coordinate system which would effectively circumvent the world-size issue. Do you think this would be a good idea or would I be better off going with Lite?0 -
Its a non trivial question here.
I would go with Lite, not just due to the coordinate system (which could rather easily be handled as you realize). Even more precise I would consider going with LoadBalancing, which is Lite expanded to multiserver (which no other solution supports) capabilities.
The reason for Lite / LoadBalancing is the clean data seperation. Each Room automatically gives you a clean, seperated data handling
At the same time, the chat and interzone interaction would require some deeper modifications to work in Lite so for those aspects MMO would be clearly to favor. Also the IA backport is not trivial either, while the 'rooming' likely is easier to replicate in MMO0 -
I'd separate chat all together from photon and use an xmpp (jabber) API thats specifically made for chat.0
-
That is a good suggestion duke, we're definitely going to look into that.
The reason I asked about changing scenes was because I didn't think it was feasible to have a ridiculously large-sized game world, especially when we would run into floating point precision issues at only about 1% of it. How would you recommend going about setting up and making a stupidly-large game world using Unity and Photon?0 -
You would need to go the 'Futurama way': Don't move the actor, move the world
But there is a major problem with large worlds and Unity: You can neither stream in light probes nor can you stream in occlusion culling (stream in means loadleveladditive or addtiveasync - both are bound to levels and can't be transfered through regular asset bundles either), so you would need to bake them for the whole world right at the start and in case of the probes then enable / disable them basing on the current virtual position (the position you had if you would move around the actor not the world - can be as easy as a 'world grid position' you use to identify where you are right now)0 -
What dreamora said. Set up a reasonable grid size for that purpose - say 1024 units per cell, and track the player by storing a grid reference (int2) and an offset relative to that cell (float2). On the Unity end, "treadmill" it. Every time the player hits a cell edge, move your world in the opposite direction and him back to 0. For example, if he walks to the cell to the east, the world moves west by 1 cell, and he enters the new cell at 0, rather than 1024. A bit of tolerance to ensure people hanging around the border don't flick back and forth and you have yourself a workable solution. If you have dynamic physics however, you're in your own!0
-
Does that method work for multiplayer though (and is it the preferred method)? I feel like it would open up a lot of issues with the client-side having more freedom to fake things.
That does seem to make sense though. I think I'm starting to piece this all together.0 -
Even with dynamic physics its possible, you are only doomed if you use the dreaded character controller.
Cause Rigidbody has a function to 'teleport' the body properly and if you do it for the whole world there will be no new physic interaction.0
