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.
Related
I'm trying to create a roguelike in the vein of Rogue Legacy, but I need to know how to not have enemies carry over from room to room. All enemies need to be idle and reset when you leave the room. I want to do this without changing the scene because that would be very memory intensive.
Here is an example:
https://youtu.be/B5jL25HgSIs
Bonus points if you know how to lock cinemachine to the room that you are in.
Yeah, I wouldn't recommend changing the scene as that takes more time (and all the GameObject instantiations can be avoided).
What I'd do is to have a single scene with all of my rooms, and determine in which room my character is by checking its position. If I detect it has moved to another room then I'd move the camera to render the next room, and in the same code I'd reset all the enemies of that room. At the same time I'd freeze all the enemies in the room I just moved from.
By the way, I feel this question, more than pertaining to Stack Overflow, pertains to Unity Answers. That one is specialized in Unity while here I rarely see a Unity-related question.
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.
Firstly, I'm new to Unity and I'm currently learning c#, please be gentle!
As a project, I'd like to create a simple 3d platform game. The idea being the player starts on a square tile, which is the game platform playing area. They explore different elements on this tile by moving around.
The perspective is 3rd person, so the player is looking down on the action. As they approach the edge of the tile Unity recognises this and adds another tile to the existing one, basically doubling the playing area.
As the player moves around further to the tiles edge, other tiles are added, increasing the discovered areas each time.
My thinking to achieve this would be to have 5 tile game objects, that have different elements like trees already built on them. The question is what is the best way to achieve this.
Would it be to build the complete level with all tiles and then using code restrict how far ahead the player can see, basically to the width and length of the tiles.
Or would it be better to trigger a new tile to appear as the player approaches the edge of the current tile.
Thought, links to example code that I could recycle would be very handy.
Thank you.
The question is primarily opinion based, but here is some advise:
There is no right way to make a game in unity. The correctness is mainly focused on performance; memory and processing.
There are two approaches here:
condition: Your world is endless (or very large) and player moves very slowly over time (say each tile takes more than a second to traverse).
solution: Do not instantiate everything at start, instead when player reaches the edge of a tile look for the next tile in your level structure to retrieve its data and then instantiate its objects.
condition: Your world is not very large (say it has less than overall 10K objects) OR player can move fast (as in Age of Empires game).
solution: Instantiate everything in loading phase and deactivate the game objects as they are being instantiated so that nothing is getting processed at the start of the game. In this case the level structure is a collection of game objects where you activate or deactivate them.
Hints:
Pooling is a good practice when it comes to repetitive objects. Pool is basically an empty game object with a script, and many many deactivated children.
e.g. If you have 1K trees of the same kind you better have a tree pool. Create a game object named tree pool, add a pool script to it and make that script generate 1K deactivated tree game objects in the loading phase. Then whenever your level generator needs a new tree just fetch a tree from tree pool and activate and reposition it. Make sure you clean up the pool after the game ends to prevent memory leak.
you can implement the pool as you like to provide object variations for a specific pool.
Instantiation in run-time is costly especially in mobile devices. Whenever you need to instantiate several game objects at once consider using a coroutine to prevent lag or freeze (this applies to loading phase too).
e.g.
IEnumerable CreateObjects(Data[] data)
{
foreach(var e in data)
{
Instantiate(e);//instantiate here and then wait
yield return null;//this line prevents lag
}
}
//...
StartCoroutine(CreateObjects(data));
//...
Having many active game objects is also costly especially in mobile devices. If many active game object have heavy scripts, the update methods will ruin performance. If many active game objects have rigidbodies or colliders the physics engine processing gets heavy.
Activating game objects is costly but less than instantiation, since it only runs Start method on its script if any, and also causes the physics engine to re-evaluate its structure if it has static collider or rigidbody.
Rendering is costly if only the rendered visuals are (fully or partially) visible to the cameras.
Create an editor project where you can design your levels. in this project you will make use of unity's editor classes to generate some kind of data (JsonObject) which represents your whole world. (collection of levels, tiles in each level and objects in each tile). Moreover you can have other data such as objectives and stuff each stored in a different JsonObject. Then use this data in your game by reading it and storing its structure in memory.
The reason I recommend JsonObject to store data is its size, portability, flexibility, accessibility and simplicity to work with. JsonObject is a dictionary stored as a plain text. and since it's a text you can encrypt it as you like
I want to use LOD groups in my(mobile) game, because I have problems with performance. The thing is that I have seen it used on objects that are not in big amount(like cars in racing game), but I think that my game would most benefit from using it on terrain(not unity terrain system, just some terrain parts like rocks etc.). The problem is that I don't know if it is meant to be used on this many objects(I have a lot of them in the scene). The other thing is how would baked lightmaps work on these(is it even possible)?
I'm using Unity3D for a networked multiplayer online game where I have a very large complex 3D terrain scene like a forest, with trees, cliff, hills, mountains, bounders, etc.
Players can also build structures sort of like minecraft, and put them anywhere in the scene, or even move them around anytime.
Aside from the human controlled players, there are automated AI players and objects like animals roaming around the scene following a path.
The problem is how to make these automated AI players and animals, able to navigate around the static and dynamic player created structures, because the path they follow can easily get blocked by player created structures, or even by other players and other AI objects, cliffs etc. So they have to find away around them or get themselves back on track if they tumble down off a high cliff for example.
So I made a navMesh and used NavAgents, but that just takes care of the static, non moving objects, but how do I make the AI players navigate around each other and also the dynamic structures created by the players which can number in the hundreds?
I thought of adding a NavMeshObstacle to everything, but this would result in it being attached to hundreds of objects since the user created structures are built using little pieces like blocks or little tiles to create a larger object.
Here are my questions:
Would attaching a NavMeshObstacle to hundreds of little objects slow down the game?
Is there another way to navigate of dynamic objects other than using NavMeshObstable without slowing down the networked game?
Thanks
Based on the documentation for NavMeshObstacle, one could reasonably assume that if carving (an obstacle "carving" a piece out of the nav mesh) is disabled, obstacles will only affect agent performance when they are in the agent's way. They won't affect pathfinding. The agent will just go around them when it's close. Note that this will not work for you if there are so many dynamic obstacles that the agents need a very different path. You can also set them to re-carve a piece out of the nav mesh only when they've moved a certain amount. You should test the performance, but that sounds like it might work well for you.
http://docs.unity3d.com/ScriptReference/NavMeshObstacle.html
If you don't want to spend much time on making your own "sensor and navigation" system extending unity's navigation then I think your way is through NavMeshObstacles. If you build your obstacles with blocks like minecraft to avoid add NavMeshObstacle on each block you have a huge range of choices on how to limit/approach on your building system.
There is also good AI systems free as RAIN, for example, that implements some extensible and consistent way to do what you want, take a look on unity market if anything there fits your needs.