koobas.hobune.stream
Optimizing endless runner - move camera and player, or move everything else?
Optimizing endless runner
I'm taking a Unity game that wasn't made with mobile in mind and optimizing it for tablets. Currently the player and camera don't move while everything else does. It's not really a runner, but it's close enough. So my question is, is it better to have everything static and take advantage of static batching, and have the player and camera move (with some compensation to avoid float overflow)? Or should the player and camera not move and everything else move?
Any suggestions?
Thanks!
It's a pretty subjective question and depends a lot on how you implemented everything, but I'd say in general less moving objects is good. And since you can only do the static batching on non-moving stuff I'm guessing there's more to gain from batching the level than the player
Thanks everyone. I've already added Object Pooling. What about batch lighting on static objects? Will that still work if I have to "recycle" objects?
If the player isn't moving, or if the player is moving, I still need to add terrain in front of the player.
If the player/camera is moving, and I take the terrain objects that are behind the camera and place them randomly in front, and the lighting is directional (outside), can I still batch the lighting? The terrain objects are mostly static, but do need to be moved in a loop.
If the player isn't moving, or if the player is moving, I still need to add terrain in front of the player.
If the player/camera is moving, and I take the terrain objects that are behind the camera and place them randomly in front, and the lighting is directional (outside), can I still batch the lighting? The terrain objects are mostly static, but do need to be moved in a loop.
Moving objects around the player is better in this situation, as there is a loss in precision when dealing with large distances from the zero world origin (0, 0, 0). Unless you plan on somehow resetting the player and camera position back to start without the player noticing, it's better to move the objects instead.
I am working on an endless runner right now, and have an object pool script that shares pooling with 3 spawn points. The objects that are spawned receive velocity on Start(), and watch their position relative to the main camera's view. When they leave the visible area, they deactivate themselves and return to the pool. The player and camera are always docked to their origin, so there is never a need to reset their positions or worry about precision loss.
i think for a simple game, having a simple structure is more important than very very small optimization (if you check the profiler, you notice that rendering consumes most of the time), so i recommend moving the camera & the player.
pooling is a must on mobile, check out this library for the most flexible pool i've ever used
Move camera with player....that has more advantage than moving ground itself...
If the player isn't moving, or if the player is moving, I still need to add terrain in front of the player.
If the player/camera is moving, and I take the terrain objects that are behind the camera and place them randomly in front, and the lighting is directional (outside), can I still batch the lighting? The terrain objects are mostly static, but do need to be moved in a loop.
Yes I will suggest to pre bake lightmaps onto those terrain then do what you planned to do
