How can I show 2 scenes on the screen at the same time on Sprite Kit Swift?
I need to first scene be placed of the second (I need one scene to be seen and atop of it appeared other scene, which has some sprites).
Or tell me, how developers make, for example, menu (with buttons like "restart", "results") to appear on other scene when player dies? And that time, also you can see the main scene with location (or with dead character)?
You do not need 2 scenes. However, you can accomplish what you are after with basing an node tree off of an SKNode. For your menu idea you could build it out of however many objects you'd like, but since it is based from an SKNode, you can animate it to your hearts content. No need for two scene, just build another node tree and animate the root. If that isn't enough answer, I could write some code to help you out if need be. Sorry watching the Netflix and feeling lazy.
Related
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've been working on a really simple game for iOS that has just three scenes; the start scene, game scene, and game over scene. I was running the game and analyzing performance with the profiler and I noticed that when I changed scenes, which utilized the "SceneManager.LoadLevelAsync()" function, the CPU usage was around 90%. This is only for less than a second of course, and then the CPU usage drops again and I get around 70-80 fps, but this got me wondering if it would be more efficient for a simple game like this for me to simply have several UI "screens" (basically just a group of objects that I can activate and inactivate), which is what I did with my pause screen (it is just an overlay).
Of course this could have difficulties of its own, like I would have to restart the game on the same scene but it might help me with my problem of running the mute function I've built on my music manager, which is instantiated in the start scene, from a button that is on my game scene, and I wouldn't have to use the "DontDestroyOnLoad()" function on the music manager or my score manager (which stores the score to be displayed on the game over scene). But would it be inefficient to have so many inactivated objects, or is Unity pretty good at managing things like that?
In my personal opinon, menu system should be in one scene.
Having different scenes for every menu screen will cause overhead. Even it is for few micro seconds it will affect user experience when navigating between menus frequently. This is because of loading and destroying of each UI gameObject in scene.
While menu system based in one scene requires only activating and deactivating of gameobjects instead of instantiating and destroying.
You can have one root object for menu and assign it a canvas component and then you can add different panels for each screen and assign them canvas groups to toggle them on and off smoothly.
Here is a good tutorial for creating menu system: https://www.youtube.com/watch?v=DNqTUwnpLvI
Hope this helps.
You are correct, If your game / app is small you should keep it as simple as possible, if the only difference between your scenes is just UI & your "in game" scene is not that big, you can for sure keep using the same scene and have the UI activate/deactivate.
*Inactive objects DO eat memory.
My iOS game has a couple of scenes. I've noticed some lag between switching scenes, and I was wondering if it might be because I'm not removing all nodes and labels from parents when I transition to another scene. Is it good practice to remove all nodes from their parent when transitioning to another scene?
Also, I've noticed that when I do remove all nodes, the transition effect is kind of ruined, as the screen goes all black during the transition.
Is it possible to delete nodes(of previous scene) after the transition to next scene?
When you perform the transition, the scene and its nodes will be released from memory, unless you have a strong reference cycle. Also, you should know that SpriteKit has its own cache system for the SKTextures, so not all memory will freed.
The lag could be caused by a lot of thing, some possibilities:
If you instantiate the new scene on touchesEnded (or your custom button callback closure), the lag could be caused because you're doing too much work on the initialization. This can be solved by, for example, preloading the scene with a closure that run in background and, when you have to run the transition, you already have everything loaded. An example follows:
Maybe you're using assets that are too large and because they take longer to be loaded, you have the lag. You could solve this by, for example, converting images that don't need an alpha channel to .jpeg.
Another solution would be to preload assets. A code example follows.
I've been developing a board-style game in Unity3D. The main scene is the board, and has the data about each player and the current (randomly-generated) board stored within it.
I intend to add minigames into the game, for example when landing on a particular space on the board. Naturally, I would like to code the minigame in a separate scene. Is there a way I can do this without losing the instance of the current scene, so that the current scene's state is maintained?
Thanks in advance :)
Short answer: no, but there may be another way to do what you want.
A basic call to Application.LoadLevel call will destroy the current scene before loading the next one. This isn't what you want.
If your minigame is relatively simple, you could use Instantiate to bring in a prefab and spawn it far away from the rest of your scene. You can even use scripts to switch to another camera, toggle player controls and other interactions in the scene, and so on. Once the minigame is done, you can destroy or disable whatever you brought in, and re-enable whatever needs to be turned on in the main scene.
You could create a separate scene and call Application.LoadLevelAdditive to load that scene without destroying the current one. As above, you can then use scripts to manage which cameras and scene behaviors are active.
If you're careful, you don't really need two separate scenes. It may be enough to "fake" a scene switch.
Hard to give a complete answer without code, but you should look into the following things either with the unity documentation or youtube:
PlayerPrefs, this is one way of saving data, although i believe it isn't entirely secure i.e. being able to edit from a text file.
Serializable, this is apparently better than playerprefs.
DonDestroyOnLoad, can carry over information to multiple scenes.
Static variables, again not sure if this will help your particular problem.
When the game changes levels I have a method that loads a new background and also changes several global properties of the SKScene ie enemy speed etc.
Problem is when I redraw the background in a new level it covers all other nodes (created in initWithSize) . Is there a work around or a better approach redrawing the background?
If I understand what you are saying you have a level which has a background node and other nodes that are displayed during the level. When you change levels, you add a new background, presumably as a child of SKScene, correct?
If this is the case, that is why it covers everything. By adding it later onto the node tree, it gets drawn last, and hence covers everything.
There are a few ways you can handle this:
-Have a different scene per level. This way each scene is self contained and will not interfere with the other scene's contents.
-removeAllChildren on the SKScene, and then add your background and anything else you need for the new level.
-If you really wanted to, you could just replace the texture for the original background with the newer background. But if you do this, you still potentially need to clean up old nodes.
Having a different scene is probably the better option out of the bunch.