I am making a super simple game for a website where you just have to find a game object and click it. It’s just one level. There is one game object “a”, 20 game object “b”, and 200 game object “c” instantiated when the level loads, and then the score is updated and the level resets when the player finds a. I want to add a little variety in color to them because “a” is a little bit too easy to find. Would making an array of game objects to spawn be too expensive for webgl? Or is it better to randomize the materials? (Also I don’t actually know how to do that so any help would be appreciated) what is the easiest way to do this without slowing the game down too much? Thanks for any help
Two things:
-
don’t concern yourself with speculative optimization. Just do it and find out.
-
it will probably be fine.
Go!
DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:
Window → Analysis → Profiler
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
https://discussions.unity.com/t/841163/2
Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.
Notes on optimizing UnityEngine.UI setups:
https://discussions.unity.com/t/846847/2
At a minimum you want to clearly understand what performance issues you are having:
- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.
Lol, thank you. I don’t know what I am doing at all. I have been trying to learn this since COVID but it seems like every time I learn something I forget something.
Ok so I got the game all built and it was working great until I switched to webgl to build. It looks a little more like a slideshow then a game. Fps around 1.6. I have been following a YouTube video to get it faster and so far it is still the same speed but now it looks bad
Use the profiler to find out what is happening. My money is that it is something relatively trivial to fix that is probably just a bit of a beginner mistake. Once you find it and fix it you’ll remember that for the rest of your life and never have to worry about it again.
Keep in mind 221 GameObjects in itself isn’t a measure of really anything.
It’s what is ON those GameObjects that matters, and that’s where @Sluggy1 's post comes in: you gotta find out what is slowing you down before you go rip-tear-shredding your project based on some Youtube video!
As a point of random reference, my Jetpack Kurt game plays just fine through WebGL and that is on a Late 2013 MacBookPro… a ten-year-old laptop!
See for yourself:
And then bust out the profiler before you wreck your game further doing fixes that won’t help… here’s my blurb on optimization, reposted from above:
DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:
Window → Analysis → Profiler
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.
Notes on optimizing UnityEngine.UI setups:
At a minimum you want to clearly understand what performance issues you are having:
- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.
Right. WebGL is kinda limited with memory, however performance wise it doesn’t make a huge difference compared to other platforms. I made this mandelbrot renderer which has an array of 576000 object (not gameobjects) which contains several values (4 double values, one int counter and a pixel index). It iterates through all of them every frame to “advance” each pixel in the image in parallel. Yes, updating the 576000 objects is quite slow. However the more pixels settle the less objects remain in the list and it speeds up to the framerate cap which is usually 60 fps. This almost maxes out the memory available since I have to hold the Color array to update the texture and the texture itself in memory. But it should run reasonably fast on most machines.
So if you have performance issues, use the profiler where most of the frame time is spend. You haven’t really provided much details about your setup. You only genericly talk about “gameobjects” and “adding color variety” without concretely telling us what you did. Having 200 sphere meshes is a lot different from having 200 cubes. Modifying the material on every instance is way different from changing the vertex colors of the mesh. There are infinite ways how someone may approach a problem. So we can’t possibly know what you did exactly and what may cause performance issues. Debugging is up to you.