I have been working on a music based game where things move across the screen at a speed relating to the music. The player controls an avatar that always remains at 0 on transform.position.x
The music blocks travel towards the player from positive x.
At the moment I have a collider on both the player and the blocks. When the blocks collider enters the players collider, I use OnTriggerEnter to check weather or not the player hit the block. (The player can move in the z axis so if not lined up properly with the block, they can miss it.
Sometimes, after a certain amount of time has passed, the blocks get a bit out of sync. I think this may have something to do with the amount of things in my scene.
It got me wondering if using colliders is the best way to go about this.
Since the check always happens on weather or not the player was at 0 on the x axis when the block hits 0 on the x axis, would it be cheaper and better for performance to just use an
(if block.transform.position.x <=0) then do stuff rather than a collider doing the check?
There are usually about 50 blocks at once in the stage.
Is checking update every frame for an objects position better than a collider checking every frame for a collision?
Just a few colliders shouldn’t make that much of an impact on the performance. It sounds as if you do not destroy the past blocks after they left the screen. If you implement this I think your performance will increase very much!
If you’re not trying to mimic physics of any kind, like gravity or objects with specific shapes pushing or blocking each other or reacting to collision forces, you may not need colliders/triggers.
There’s a mindset that Unity kind of suggests with its Hierarchy view, that there needs to be objects and they need to behave in a self-contained manner, and probably physically.
If you think about your game and you think it’s abstract (and simple?) enough to represent with simple changing variables and equations, then you may be able to just implement the logic with those simple variables. No colliders and rigidbodies. Just abstract objects with changing x and z, and a player position with a z.
Your scene GameObjects can then be just purely for visualization. Just a bunch of renderers with positions.
(Regarding your blocks becoming out of sync. What do you mean by that? Out of sync with what? The music? What would that have to do with the number of objects? Are you using Update or FixedUpdate? Do you know how timesteps work?)
If I’m visualizing your scenario correctly, creating a generic List for the blocks that you are generating will imply that you just need to check whether the block that is on top of the list (nearest to the avatar by order of creation) has collided.
That should result in just one check regardless of the number of blocks in your scene.
The above optimization trick will work only if your blocks in the scene have equal speed.
You can now use both physical colliders (recommended because its easier to debug and shape things visually) or a simple transform position comparison.
For physical colliders, your boxes should come without colliders. Then simply add a collider component to the box on top of the list.
When a box collides, remove it from the list (or add it back to a pool after removing its collider) .
Tip: As Pharan mentioned, for this application, you will need a thorough understanding how timing works in physics in relation to frame updates. These ensure that things don’t go out of sync even if you jump multiple frames due to performance. Here are the docs on that: Unity - Manual: Important Classes - Time