loop or store data index for large scaling purposes?

[crimson gull]

Suppose I am making a game like Minecraft. I have a table on the server that stores the block id, position, attributes and placer. Whenever I want to delete the block I would need to get the block's position so I would need to loop through the whole table and compare each object's position. I'm planning for long term so I imagine looping through the whole table of possibly ten thousand of blocks every second or minute, depending on how frequent a block is broken, would take a toll on the server. Or, I could store the positions of each block in a separate table and send the index of the data in that table to the client so when they need that block to be deleted they could just send it back.....

After typing all this out I just realised. That if lets say there are 10 blocks placed and so there will be 10 positions in the position table. Suppose position index 5 is deleted, that will move position index 6-10 upwards making the position and the actual block data not match. So is there a better method?

[green zenith]

in minecraft, air is a block type. the same would work here. you're not removing anything from the table, you're only changing the block type from a solid to the special air block which denotes an empty block.

you also don't really need to store positions for every block as that's going to consume insane amounts of memory and datastore. minecraft uses a lot of different techniques to compress how much memory is used to store chunks

e.g instead of storing each block position, you only store the chunk position, and then the position of a block within the chunk can be inferred from its index.

[crimson gull]

in my case, I'm making something similar to Minecraft. However I don't have an air block. Air is just empty. The way my system works is just as I explained, everytime the server starts, the server fetches from the data store using the profile store module, the data of the world. For example:

{
  id = "1.29173" --unique id for every block placed because it is generated based on time
  position = { x, y, z },
  attributes = {}
}

so whenever the client breaks a block, it will be sent to the server, validate the request and then loop through the table to find the block's index and use table.remove to remove it

To counter possibly looping through a lot of block data, I decided to use the most basic approach and that is to limit the amount of blocks that can be placed. The amount is not decided yet but I wonder if there is an approach that doesn't require looping to index a block in a table fast. If I were to set the deleted block's data to a negative value, it would still take up space although not as much as a normal block data. As I see, that approach is not really reliable for the long run

[crimson gull]

unlike Minecraft my game does not have chunk generation. Instead it generates a flat world, like Minecraft and the server would generate random positions to fill in stone, gravel, whatever

wait should I be storing each block inside a dedicated chunk?

hmm instead of looping through thousands of blocks I could be looping through 10 chunks that have 100 blocks each. I think thats better

[green zenith]

i don't know what to tell you, this is a very bad idea to use time as a block index, but you do you

if you want to throw caution and best practices to the wind, well, i'm not going to stop you. just don't complain about lag later on

[crimson gull]

im doing it like this ```lua
{time()}{math.random(1000)}

so in case theres 2 players placing a block at the same time it will unlikely cause a same id

[lime mauve]

** You are now Level 4! **

[green zenith]

no i meant in terms of recording block changes, you should be using a regular grid for positions as this costs more than block changed time

and without block positions, you have this looping through block changes solution, it's just bad solution, you need position for index more than block changed for index

but you do you

[crimson gull]

wdym a regular grid for positions i dont follow

[green zenith]

i asplained here

positions are vec3, which is 3 float64's. time is just one float64, and you have to store blockid anyway. and then you get the benefit of O(1) lookup time instead of O(chunksize) lookup time for positions. compressing is worth it. if you want to further compress you can look into octrees

but that o(1) position lookup time is worth it compared to looping through all blocks

also depends on the game you're trying to make

[green zenith]

your original question sounds like a http://xyproblem.info

[crimson gull]

I think i get what u mean now, ur saying to use the block’s position as the id and when the block is deleted, just index the block table with the id. That is certainly way better and smarter than my method, thanks

[green zenith]

yeah so you end up with something like chunk[x][y][z].blocks[x][y][z]

[crimson gull]

would converting the position to a string be better? like "x.y.z" = { ... }

[green zenith]

and then because of how cubes work, you don't need to store the block's xyz position at all, you can instead infer the position from its position in the array. the formula for this is something like index=x+y*cubesize+z*cubesize*cubesize

[crimson gull]

i dont think im gonna use chunks actually

[green zenith]

then x=index//cubesize and i dont remember the others