koobas.hobune.stream
Targeting multiple tiles in grid, updating with player movement
Hi all,
Currently working on a grid based project which requires the player to destroy 'bad' tiles, I'm having trouble figuring out how to handle the targeting system as it needs to update as the player(yellow and blue orb) moves with respect to its rotation. I made an attempt as you can see by the yellow outlined tiles. It is however very crude as I'm accessing a static list held by a manager object from the player script and then running a for loop to check the list against the player position(this is all being called through update, I know this is bad but I couldn't think of an alternative). 
If anyone could offer any sort of advice in terms of the approach I should take to this problem I would be extremely appreciative.
Thanks,
Renoclaf
Sounds fine to me. Since it's based on position and rotation, then every frame all 49(7x7 area?) nearby objects could possibly change. That means you absolutely have to touch each object each frame. 49 isn't that big a number (not like 100 units are all doing that.)
If the rotation is in set steps, you could do the math only when you change tiles or spin, but that would give tiny lag spikes. Running every frame would smooth it out.
For the "I'm too far away, uncolor me" objects, maybe call a slow coroutine when you first color something, which checks for "too far away." Check more frequently as distance from player increases? Have a flag "I'm running my too far away checker," to avoid double-calling. That would give a pretty, staggered winking-out effect. Alternative is to add colored items to your own watch list, but, really, the coroutine does the same thing.
Hey Owen, thanks for the reply. I forgot to specify in the original post that the grid is in fact a lot larger than this 30 x 30 at least. The main reason for me posting was that when I implemented this I was using 90%+ CPU on an i7. I do have a number of debugs running in update but I'm not sure how much that would impact things. Do you still think this is the best approach?
Thanks.
Are you coloring the entire grid each frame? I assumed only "nearby" tiles were colored.
To color all, could run a loop every frame to color nearby. Then color "6-away" on even frames, "7-away" on odd, "8-away" on multiples of 3 ... . $$anonymous$$ight look nice in that you'd see color changes "fan out" from you.
All of the tiles are initially set to blue, the idea behind the dark tiles is that they are an infection so I need to have consistent coloring. As it works now the grid is created at the beginning of the game based on user input in terms of size. From here
All tiles are then added to a 'grid' list
The perimeter tiles are added to a 'perimeter' list
The 'light'(blue tiles) list is made (gridlist - perimlist)
A coroutine is started which randoms a perimeter tile every 'X' amount of seconds which is then added to a 'dark'(black) list
The next block in the co routine randoms between finding the closest and furthermost 'Z' number of draft tiles which are added to a temporary list
Finally 'x' number of tiles are randomly chosen from the temporary lists, which then starts a function which sends the specific(based off name) tiles a message telling them to change to one of the textures they hold.
Just though i'd clarify my process in case this would have some impact. I like the idea of setting the closest tiles color, however in this case I really need to stick to this good / bad infection narrative direction.
Thanks again.
If things are only changing occasionally, on your schedule, time probably isn't an issue. Four length 30 sides isn't that big a number. One trick, to smooth time out over frames, is to have the coroutine yield one frame every 20 or so tiles (a small pain, since you have to under estimate frames until next big change.)
Are you sure it is the targeting code that is causing you the performance issues? As I read through what you are doing, I see several potential performance pitfalls. In particular if you are really changing the texture of each square (ins$$anonymous$$d of using a texture atlas and changing the UV coordinates), you will be generating up to 900 drawcalls for the plane (ins$$anonymous$$d of one batched call for a texture atlas solution). And you could boil this app down to a single mesh/game object and just change the uvs.
As for the targeting, given the regular nature of your board, I'm sure there are highly efficient methods. But how good is just leveraging Unity? That is, if you put a box collider on each tile and did a RaycastAll(), would it be good enough?
