I have a 2D game/demo I am working on for learning purposes for Unity Networking and I have come to a predicament on how I should handle multiple scenes in my game because as we all know most games have more than 2 scenes and players are not always in the same scene (someone is in the scene HouseLrg while the other is in MainWorld scene).
Now the best thing I have come across is :
SceneManager.LoadScene (newScene, LoadSceneMode.Additive)
But when I use this I notice that the scene that I am loading literally overlaps the scene I was currently on. So my questions are :
1) Is there something else besides LoadScene(string, LoadSceneMode.Additive) that would work for having players in different scenes?
2) If LoadScene(string, LoadSceneMode.Additive) is the solution I am looking for; would I have to just edit the position/location of my entire scene so it isn't in the same positions as other scenes so that when I load it "Additive" there is no overlap? Or is there something I can do that is "isLocalPlayer" based so that the player making the scene change is the only one that goes through it?
Help me become less ignorant please because, "Knowledge is Power!"
Thanks!
Related
I was reading up on the unity MLAPI and read in the documentation that basic scene management is offered. https://docs-multiplayer.unity3d.com/docs/mlapi-basics/scene-management. However as far as I could see this is limited to placing all of the connected clients and their player prefabs in the same scene. For this use case this works pretty good, I was wondering if anyone has experience using MLAPI and managing different scenes for different players. Basically running a multiplayer game where player X could be in a different scene than player Y, whilst still being able to move to another players scene and see the state of the scene that player caused. A bit how games such as Diablo 3 work. I have no idea where to begin with such an implementation, any pointers would be greatly appreciated!
I'm trying to make this game using the approach of multiple scenes to make things more modular.
In my actual case I have an "Initialization" scene which holds some global state objects and the one to control the state machine of all the scenes in the game.
As for the other scenes, for now I divided them just in two: the base scenes (which for now contains everything besides UI) and its UI scenes (which basically have a Canvas and all the UI elements and UI-related scripts).
The confusion in my mind is simple though: as I tried to make the UI scenes as modular and independent as possible, there are a lot of points of interactions between the base scene and its UI scene.
For the sake of illustrating this question please take this problem I'm facing right now: I have camera animations that should be played as a response to user inputs to the UI (like the click of a button should trigger a specific camera animation). Thing is: that camera is not in the UI scene. The way I'm resolving this problem right now is creating a ScriptableObject which holds events for important actions triggered in the UI scene that are fired in the UI scene and subscribed in any other place. The same can occur in the opposite direction: the UI scene need to react to many actions that happens in other scenes.
Considering that the "camera animation" problem I explained above can happen with many other objects, if there is not a better way to handle that wouldn't splitting a game into multiple scenes be just too much of work just for the benefit of modularity? And by that I also asks: am I handling this problem the right way?
If you want to keep things consistent between scenes, there are a few ways to do it.
PlayerPrefs lets you keep variables consistent, I don't need to do a whole tutorial here, look it up.
DontDestroyOnLoad lets you take an object and make it consistent throughout the whole game. If you want, you can use DontDestroyOnLoad on one of your cameras and just delete the others in the other scenes if you want to keep a consistent camera.
I'm currently making a 2d platformer game with unity. I'm going to build game world with rooms (like in Hollow Knight and many other metroidvania games). So, my first idea is to have each room as a separate prefab with virtual camera and exits linked to other rooms on scene. And to have several scenes (smth like each scene contains a set of "thematic" rooms).
I have another idea but i'm not sure if it gonna work properly in terms of perfomance. The idea is simple - to have single game scene and instantiate\destroy game rooms dynamically and seamless. So the game will have current room and all adjacent rooms loaded (with some depth maybe, i.e. all adjacent rooms with depth R), when player changes room - some new rooms are instanciated and others destroyed. This feels like a good idea, cause after creating dynamic room system you can just concentrate on creating and linking rooms. But i'm afraid it can lead to some perfomance problems (i.e. game freezes when player moves from one room to another if there is a big enough room nearby). And i guess there can be a lot more unexpected problems.
So it's kind of open-type question. What do you think about this "dynamic" approach? Is it worth trying? If you have expirience building similar games, what design approach did you use?
Typically, creating and destroying objects in-game is a no due to performance issues.
From my high school game dev teacher, a better way to do it is to preload everything outside the camera, and just move needed resources into view as needed for a randomly generated scene.
If you're looking for a static scene, I would just preload everything that I need for that specific scene.
I have a work-in-progress spaceship interior built with Unity (utilizing pre-built assets). It won't move much. The space around it will, similar to how I made an HTML/Three.js version of this concept (although linked example does move ship around space scene while scales are also animated).
With the three.js version, I was constantly fighting with "space" entering the ship; warp beams and planets colliding with the front info screen or passing through the chair (destroying the illusion of massive scale). I was able to resolve most issues, but it was a challenge when everything was in the same scene.
In Unity, is there a way to keep the ship scene separate from the surrounding space "scene", whether it is part of the same scene or in a separate one on another layer, or the same scene with masks that prevent overlap? I don't need a very literal answer, but any guidance that leads to a solution will be promptly accepted.
Yes, it's a very basic and useful aspect of Unity - the layers system.
As you guess you can find endless doco about it at Unity, cheers
Note too - Unity of course has superb occlusion culling built-in. Almost always this will "just work" for you.
Note that (if I read you right) you're doing a scene with a tremendous difference in scales (like "10 cm" objects AND "1000 km" objects at the same time). As you probably know you basically can't do this in a game engine, it's tricky to pull off.
Just BTW this is more a question for gamedev.com
My game will switch between two scenes : scene A and scene B;
scene A is a world where the hero can walk around and trigger battles;
scene B is the battle scene;
when the battle finished, I want to turn back to scene A and hero should be in the position where it trigger battles. So I need to save scene A before I load scene B;
I tried the api LoadSceneMode.Additive; But it's just used to mix one scene to the current loaded scenes.
Could you help me plz?
Firstly DO NOT use "additive". Just use ordinary scene load.
Secondly you have the problem of "remembering" where the guy was when sceneA loads.
Your easiest approach to get you going .. learn about PlayerPrefs.
Just before you quite sceneA, save the hero's position. When you load sceneA, get the hero's position.
Alternately you can use one static class as a sort of global to keep track of the info. But to do that you have to learn about writing that sort of code.
Be aware that what you're doing is not that easy - Unity is a lot harder than it says on the box.
I encourage you to master PlayerPrefs in the first instance, because you will have to use it all the time anyway.