Hello,
I have an… Unspecified game that includes mobile controls. It has 58,762 objects and counting. I need help on how to keep the cosmetics of the game and still allow lower-power devices such as tablets and Chromebooks to use the game. Thre are nearly no complicated objects, the only thing that it increasing lag is quantity and physics. If I change immobile blocks into background blocks, does that help with lag? Any tips? Thank you for any help,
Meb.
4 Likes
You could try turning on the Performance Metrics to know what’s causing the lag (it could be anything, behaviors, physics, objects, or even single proximity).
6 Likes
I mean, that right there would explain why, lol.
5 Likes
I did, everything was green. Physics occasionally went to 0.17 but that’s it.
2 Likes
Any blocks that don’t absolutely require collisions and movement should have them turned off, this way they don’t affect the physics processing at all.
For objects that do require physics:
If your level is made of static rectangular blocks with no behaviors in them, then they will get merged together into larger rectangles, making the collisions smoother and faster.
If you want me to look at it, DM or email me a link and I’ll try to provide more specific info.
EDIT: Also, lower-powered devices like phones or tablets often struggle with large textures, so if those devices in particular are struggling, make sure you don’t have excessively large sprites, or animations with a large number of frames (which creates large textures under the hood).
4 Likes
Suspicous.
2 Likes
I can assure you, it’s not this one lol.
3 Likes
The majority of these blocks are simply ground blocks, my main hypothesis as of now is that background blocks have no collision and therefore no lag, so my current project is to replace all blocks not touched by players with background blocks. Is this a valid solution? @grazer
1 Like
That would explain a lot, I noticed a lot of the game world blocks turned into backgrounds.
Wait, but background objects have behaviors, and if they have nothing in their behavior window it shouldn’t matter what layer you’re in, right?
1 Like
They still have some blocks, remember our uh, auto grass
1 Like
They still have to test for collisions for all other physics objects if I’m not mistaken.
1 Like
Oh right, I used raycasts for that, I think those cause lag, but it only triggers ‘once’
1 Like
Shifting objects into the background will remove their collisions, but you can do the same thing by unchecking “movable”, “is solid”, and “enable collisions” in the physics settings. There really isn’t a need to move them into the background.
You are definitely correct that objects with no physics will have a much smaller performance impact on the game.
3 Likes
If you have Raycasts (or any other logic) in your ground objects, this could be preventing some optimizations. So here are some details of of how things work internally that you normally don’t need to worry about, but understanding might help with making your game faster:
Smart Objects:
Objects that have behaviors (even just one) are called “smart objects”. They have to be evaluated every frame. This process is very fast, but if you have many tens of thousands of “smart objects” you might want to consider if there is an alternate approach.
Merging
Objects that meet this criteria:
- No behaviors
- Rectangle collision shape
- Not movable
- Are the same type
- Are touching
will get merged together when the game starts, so that if you have a group of objects like this:
+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+
When the game starts, they will be merged into a single shape in the physics engine like this:
+-+-+-+-+-+
| |
| |
+-+-+-+-+-+
This process makes the collision detection much faster (e.g., 1 check instead of 10 checks in that example above), and also makes the ground smoother (fewer vertices to potentially snag on)
If you have large levels with many objects, having these points in mind will help keep things running fast. Let me know if I didn’t explain anything clearly, or if you have questions about any of it.
4 Likes
That’s a lot of good information to keep in mind, I do have one question.
Are they considered smart objects if the behaviors aren’t running?
2 Likes
@meburningslime, we can just get rid of the behaviors in the ground object and do it the old-fashioned way by not having the autograss thing. It may take a long time to change but it should be faster while the game is running.
1 Like
Yes, adding any behaviors will make them smart objects. There is no way to predict whether the behaviors should be running or not without running them, since they can start back up at any time.
More optimizations for merging have been discussed, such as still allowing merging unless a certain subset of behaviors are used (e.g. destroy, position, rotation, etc) that modify the physics. This would enable blocks with auto-tiling systems in them to still be merged. They would still be smart objects, however, and get evaluated every frame.
Also, the number of Smart Objects is listed in the performance metrics panel.
4 Likes
Ok, so I deleted the behavior in the main ground block, the smart object count went down by 900. 
Not sure if this is a bug or something but I had to refresh to get the smart object number to change.
1 Like
Did this have an impact on performance, and could you tell if the main ground blocks are being merged now?
Merged ground blocks will also usually improve the collision calculations so that moving objects can slide more smoothly without snagging.
3 Likes
I think it did, I’m not sure because I didn’t have that much of a lag issue, to begin with, I think the lag mainly happened on smaller devices like Ipads and Chromebooks.
1 Like