Voxel worlds like Minecraft can use many tricks. Such as using hierarchical representations to cull or combine objects (things like octrees to cull hidden blocks, combining 100 blocks with the same texture into one block and batching it into one draw call, etc.).

Yeah, you could probably eliminate all kinds of things like areas and who knows what, but those things are only important in a large game. If it is a small game, it is fine. I would rather be doing other things and get a game done. I try to only attach scripts to parent objects. When you are making the equivalent of a chess board, you do not need the same programming as an open world game.

This is not a chess board. It's 10,000 squares, look at the photo in the first post.

It's borderline, I'll go that far, but I still think you won't even notice it, even with areas or static bodies connected. And it is convenient having areas connected. Sure, you could do it without them, but for selecting and everything, it's nice to have them. At what point do you draw the line using a grid game, that's pretty close to it right there if you ask me, otherwise you would use some kind of moveable graph. Anyway, he's that far, why not just try it out?

You can select things on a plane just fine (if the hit point is 362, 427 and the grid is 100 x 100, then you know it's block 3, 4 just doing some simple math).

Also, you can store data in an array or dictionary on a main script, you don't need physical objects to store data.

Granted, I agree you shouldn't optimize early, but you also shouldn't waste performance if there are simple solutions available.

    cybereality I've done it on a square grid, it is trivial for math, but I would experiment with it and see what happens because it might not always be a square grid, or it might lead to other ideas. That's the whole thing about prototyping. When it got to hexes and shifting them by the sine of 30 degrees or whatever, I didn't debate very long about it. I haven't seen one tutorial where coders used something other than individual hexes. It's kind of like telling coders to use a state machine when they are doing a platformer or whatever. It's not necessary for what they are doing and it will work fine. They got that far, why not finish it. If it's slow, use it on the next iteration. And really, he might find out less is more with that grid size.

      Tiling, be it rectangular or hexagonal, is a simple form of space partitioning. In other words a grid structure already is an optimization in space management. If you just need scattered objects without any access optimizations, then why call it a grid?

      I think the OP should specify more precisely what they're after to get better advice. Otherwise we're just guessing. But judging from what they wrote so far, looks like they're not aware of the benefits you actually get from using a regular grid (e. g. player's cell is always implicitly defined form the position, so no need at all for thousands of areas, which is an enormous overkill btw)

      The goal is that the player can walk to a tile, store that tile information to a variable, and can build turrets, walls, etc on that tile. Atm, I use the tile position and add the turret with the position of the tile, if the tile is full, can't build on it.
      If the tile is empty, the color of that tile is green.
      If full, red.

      The player has an area3D and when an area of group "cell" enters it, it gets stored as the current tile he is positionned on. It works, but I'm always on interested in other ways to do things 🙂

      • xyz replied to this.

        Loxyrak You always know on which tile the player is standing simply by looking at player's position.

            xyz If it was a simple grid in 1 object you mean ?

            • xyz replied to this.

                If you are mousing over and you want to know what grid you are on, it's easy if it's a square, but it's hard if it's a hex. I know it can be done. Even with mine, I used circles for static bodies. I'm sure I could have done something like it mathematically, but I had enough trouble just lining up the stupid hexes on the grid. Attaching astar neighbors was bad. I was OK until I hit the end of the rows, etc. because the hex is shifted on the next row so there might be one to the left or to the right. Sure, maybe I'll try it sometime, but not tomorrow.

                Utilize the instancing feature in Godot to create a large grid efficiently. By creating a single grid cell as a scene, you can then instance it multiple times in a grid pattern using the InstanceMesh or InstancePlaceholder nodes. This method reduces memory usage and improves performance when dealing with extensive grids.
                found information