My main scene is taking 20 secs to load and after running the profiler it points to StandaloneInputModule as what makes it take that time.
I've searched in project for that script but it does not exist, i've only found a StandaloneInput
¿Where can i find this script/reduce this load time?
StandaloneInputModule is in the Event System GameObject that you have in your project and it's the responsable of your input in the game that you are developing :)
The problem is essentially that you may have a ton of world space UI Canvases in your game. Each of these canvases has a "graphics raycaster" script, because I think they're put there automatically when you create a canvas (could be wrong). Just remove all of those graphic raycasting checks on all of those canvases. The event system was having to try to keep track of all of those objects, and thus the "Eventsystem.Update()" was having a really hard time. Getting rid of those "graphic raycaster" scripts freed up a ton of CPU time in my game.
The good news is that the "Event System" script and the "Input module" script are not terrible for performance in and of themselves. This is great news for me, because I thought it was on Unity's end, and it turns out not to be (unless you need a lot of graphic raycaster checks).
Peace!
Related
I'm new on that thing of analisys profile of Unity. I decided to see if my player is dropping too much FPS and the I found this. Will that be a problem for my game? I don't know how that system works, but I guess 8.35 is a high number...
Not its not.
The editor loop is how long the unity editor took.
The player loop is (roughly) the performance of your game. And the big green part looks like the WaitForTargetFPS call to me. Though to tell for sure you'd have to expand the player loop and see.
If you want to measure the actual performance of your game accurately you have to make a development build and profile that one (you can select the debugging options for this in the build dialog).
Further reading: profiler documentation
I'm trying to figure out a good way to script the NPCs in my RPG. A sample NPC interaction could go something like this:
NPC starts dialog #1 with player.
When the dialog is finished, the NPC moves to a waypoint on the map.
Once the NPC arrives at the waypoint and the player talks to him again, he starts dialog #2.
At the end of the dialog, the NPC asks a question.
If the player gives response A, the dialog ends. In this case, talking to the NPC again starts dialog #2 again.
If the player gives response B, the NPC gives an item to the player, and disappears. From now on, that same NPC will be present in a different Unity scene.
I've found plenty of examples of making a dialog tree, but I can't find a good way to handle complex situations like that. One of the most challenging problems is to determine which scene -- and where in the scene -- that NPC is. Depending on how far along the player is in the game, that NPC could be in any one of many different scenes, and will have different dialog and behavior.
Since Unity makes it easy to attach a script to my NPC's game object, I could of course do this all through a C# script. However, that script will get pretty big and messy for important NPCs.
The path that I've gone down so far is to create an XML file. Something like this:
<AgentAi>
<ActionGroup>
<Dialog>
<Statement>Hi!</Statement>
<Statement>Follow me.</Statement>
</Dialog>
<MoveTo>Waypoint_1</MoveTo>
<SetNpcState>NpcGreetedPlayer</SetNpcState>
</ActionGroup>
<ActionGroup>
<Conditions>
<State>NpcGreetedPlayer</State>
</Conditions>
<Dialog>
<Statement>Here, take this.</Statement>
</Dialog>
<AddItem>Dagger</AddItem>
<MoveTo>Waypoint_2</MoveTo>
</ActionGroup>
</AgentAi>
That sample would cause the NPC to greet the player and move to another spot. Then when the player talks to him again, the NPC will give the player a dagger and move to another waypoint.
The problem with the XML is that I'm worried about it growing very large for important NPC that can be in a lot of different places depending on where the player is in the game. I'd have to keep dynamically determining which NPCs are in a scene each time I load a new scene. I'm not totally against doing it with XML like this, but I don't want to waste a bunch of time heading down this road if there's a better way of doing it.
Since this type of behavior is common in a lot of games, is there a good way of doing it in Unity without having to homebrew my own complex system?
Normal software systems would use a database, once the level of complexity gets too high.
I'd setup the storyline with a numeric reference, like the pages of a book.
If they go to a higher number without interacting then the interaction is still available.
Then you can setup each interaction as a separate thing, with a start and finish number (not available before and not available after).
maybe you could do this by making the xml files separate, but I'd think you still need to tie them into the storyline.
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.
I made and android 2d game in unity 5 with about 15 scenes and applied scene change script to buttons, I observe uneven delay of scene changing by onclick button, some scenes load quickly while other load after a short delay of about 1~2 seconds and some times 2~3 seconds, suggest what could be done.
Accurate, but probably undesired answer:
There is nothing you can really do about this
Unity scenese, when you load a new one, have to be deserialized from disk (they are not kept in memory!). The larger the scene is (the more gameobjects, monobehaviours, etc. etc.) there are the longer this process is going to take. Additionally, each MonoBehaviour script needs to be sent an Awake() and Start() invokation which has some significant overhead.
You can reduce the overhead by using fewer scripts with Awake and Start methods (calling the same logic under a different method signature from a single Main script), as well as fewer scripts overall (further centralizing your program), as well as compiling the game under Fast But No Exceptions and .NET Subset (neither of these are available for Editor running, however), both mentioned in the prior linked article.
It is also possible that Unity compiles out scenes in the Resources format (which is clunky and slow) and you may benefit from using Asset Bundles instead.
However you're still going to be bound by the load times between various scenes regardless of your optimization efforts (what few options exist). A complex scene will always take longer to transition to than a smaller one, there's no way around that.
I'm trying to load a scene asynchronously so I can have a nice progress bar and I found that the returned AsyncOperation.progress stops at 0.9. I don't have a problem with that but what is happening is that after that, it takes up to 50s to load the scene and that doesn't show on the progress. After deleting some objects I found that there is 1 (the main scene object) that is causing this delay.
My question is, is there any way to load this object in the first 90% of the load (which is happening super fast right now - 1s)?
Thanks in advance
If this GameObject is inside the scene, it is loaded with the scene. The problem you have is with the all script logic inside the scene. The loading thread actually finished, but the scripts, instantieting etc., takes all device resources and it looks like stuck at 90%.
To solve it I think you should delay all scripts executions on Awake or Start methods. That should help, but still all the time needed on particular device to execute scripts will take all CPU, and will look like stuck again.
So, it seems it all comes to the substances I was using. It's really strange for me because I explicity check all of them as "bake and discard substance" which seems to do nothing. After baking all the textures and switch from substance to texture in the material the loading came down from 42s to 1s