So this is going to be a longer one, please bear with me.
So I want to make a simple procedural generated infinite runner, and it’s going ok so far.
The concept is that you control a sphere rolling on different colored cubes. These cubes are laid out so that each color has its own lane. The sphere changes color according to which lane it’s touching. So when it’s on the green lane it turns green, when it’s on the pink lane it turns pink etc.
A wall is going to pop up periodically so you have to be the color of the wall to pass through it.
My first issue is performance, which seems to be deteriorating after a few moments of cube-spawning.
My second issue is more specific. The sphere you’re controlling randomly comes to a halt as you can see in the GIF. eachperiodicchupacabra I’m lerping the boxes on the y-axis from a Random.Range(-5.0f, 0.0f) to 0, so I’m thinking it’s because the cubes aren’t completely finished lerping yet, but I really like this method, so maybe one of you know something about it…
Lastly, I’m having troubles with the script actually allowing the player to pass through walls. Right now I check every time the player changes material to see playerMaterial == wallMaterial and set the wall isTrigger = true.
This just doesn’t seem to function reliably. Sometimes it works, sometimes it doesn’t and that’s only on the first generated wall. The other walls after the first NEVER set isTrigger = true.
What I’m wondering is:
how should I instantiate these cubes and then destroy them again in a performant way? There are a lot mind you.
Is there a better way to spawn in the boxes? Should I spawn them in chunks? I guess it relates to the first question, but maybe it doesn’t.
Any of you have experience playing around with isTrigger?
If you have any questions, please ask them. If the question is too overwhelming please just focus your attention to the first with spawning and performance, that’s what I need the most help with…
You shouldn’t, if you want to be performant about it.
The reality is that you should probably only have around 5 or 10 cube instances in the game world. The actual track should ideally be a single large mesh that is just really long, and use some kind of floating origin technique/repositioning of the track as the player moves… You can use shader tricks such as alpha culling to only show part of the track at a time and use the cubes to illusorily “add” to the track, then just reuse the same cubes for the next section.
Having tons of box colliders and trying to treat them like a “seamless” surface may also be contributing to your motion woes, as occasionally some stray floating point error may cause the physics engine to believe you’ve collided with a corner of one of the boxes. That’s probably why your sphere is bouncing around so much too, though I’m not sure if that’s intentional or not?
I recognize that some of what I’m saying will mean a large rewrite of your basic mechanics. But I believe it would be the best way forward with this concept.
Ah, that’s what I feared the most, but I guess that’s the only way to really avoid the collision-bugs… I even created some algorithms I was really proud of… :((
Thank you for the reply though; I’m off to start over lmao
