Discussion Which is the best method to detect neighboring gameobjects of a targeted gameobject?

Hello everybody,

I'm currently developing a road system for my isometric 2D game but I'm having a performance issue.

Indeed, the problem comes from the number of colliders which quickly becomes problematic because the roads quickly become numerous in a city builder.

Here's how my system works right now:

A "road" gameobject contains a main collider (in the center) and 4 other mini colliders placed in X (planned for isometrics)



Here are the settings for these 5 colliders.



Finally, the script seen from the editor for managing the display of road sprites. To put it simply, the road sprite will change depending on which colliders are activated.



This is how my script works for route display management.

Only, in view of the FPS performance of the game after the installation of some 500 road gameobjects, the game slowed down can go from 200/1000 FPS to 30FPS in the profiler.

======

My question is: Isn't there a way to create a much less resource-intensive script?

I had the idea to replace the colliders by a table grouping the coordinates of ALL the roads and to make a check to know if one or more coordinates would be the "neighbors" of a road. But I don't know if this method is good/optimized.

I research before to create an optimized and clean script/operation in order to guarantee good performances.

If you have any ideas/recommendations, I'm all ears.

Thanks!

 

Did you forget to post the script?

And I would imagine in a grid-based game, you have some form of data-representation of the entire grid, so you can easily check neighbouring cells by some simple maths.

 

Something tells me OP relies on colliders for everything. I've seen it before. It's incredible how powerful todays computers are. I imagine the tomorrow's computers will crunch the full first minute of the Big Bang model so that some kid can detect whether Ms. Pac-Man is touching a ghost.

It will come out slightly imprecise because there are bandwidths of the cosmic microwave background that will still be on the fringe, so the kid will post it here claiming that it worked yesterday, but since then the testing AI has already learned to exploit the collisions, which by unspoken standards among the youth of 2046, renders the game completely unplayable.

 

^ ^ ^ This. That's the entire point of putting it in a grid. Otherwise your grid is just something in the way of your game design.

If you want examples of spawning and storing stuff in a grid, checkout the

SpawningInAGrid

scene and script inside of my MakeGeo project. It spawns stuff in a grid, lets you move around with arrows, and uses only the grid to do business logic.

I love cosmic microwave backgrounds on the fringe but I agree that it has no place in gamedev, except maybe in the random number generator code, but that's tiny.

If you're using a grid, then use a grid.

 

My brother in christ, you don't use colliders for this. It's like using a jet engine to ventilate your dining room .

Your game is laid out in a grid, that can be represented as an array to make it easy for each cell to determine its neighbors using simple addition/subtraction of indices. Then store a cell "type" at each entry of the array, and make each cell check the value of its neighbors to determine which sprite it should be displaying.