Hello forum!

I have a grid, let's say 20x20. Every object (but GUI and alike) are part of this grid.

Since every grid-slot has a fixed size, I can easily determine whether a mouse-click interacts with a grid-slot. But there is one problem with this:

Do I serialise the grid-slot or the actual-position?

Actual position:

+ Easy to deserialise, since no further conversion is required, coordinates are pretty much done.

- It is unclear on where to insert this onto the grid, would require calculation.

Position in the grid:

+ Easy to place on the grid.

- Requires calculation to find the true coordinates.

Serialise grid as well and keep coordinates as values per entity:

+ Contains everything needed.

- Data redundancy, because both values could be converted anyway during runtime.

- Slower serialising and slower deserialising.

I assume serialising the grid-position for grid-elements is better?

Not really sure how to progress or what class should be responsible for interpreting/converting/changing grid-positions to real coordinates.

Thanks for your time : )

The game logic evaluates the grid/slot-position : ) But instead of accessing the actual entities, it uses the datastructure-vector/list/... storing them.

Coordinates-values pursue two use-cases at the moment:

1) To help the loader to insert them into the grid-datastructure.

2) To be displayed on the screen, because at some point, the painter-class will iterate over them and render them, wherever they are at the moment. One entity would be the player, in order to allow smooth transition between two tiles, I require the actual coordinates that can be transformed/synced with their animation.

I'd store the actual positions, and not the grid. The advantage is that you can change the grid without breaking all savegames (or if you prepared for changes in the savegame format, without a savegame change).

Oh, but how would you identify where to place an entity within the grid-datastructure?

Would you simply calculate that?

E.g. coordinates are x = 64 and y = 64, one grid is 32x32. Simply doing x/32 and y/32 would give me the grid-slots. But that sounds so awkward to do, haha.

Sadly, I cannot rely on the order within the serialised file, as there might be empty grids and these are of course not part of the savegame.

20 hours ago, Angelic Ice said:

Oh, but how would you identify where to place an entity within the grid-datastructure?

Would you simply calculate that?

E.g. coordinates are x = 64 and y = 64, one grid is 32x32. Simply doing x/32 and y/32 would give me the grid-slots. But that sounds so awkward to do, haha.

Why is that awkward? You claim you are not going to store empty girds. Therefore, apparently, the grids themselves have nothing of interest to store, only the objects they contain are of interest.

So create the grid structure first, and load the objects into them.

20 hours ago, Angelic Ice said:

Sadly, I cannot rely on the order within the serialised file, as there might be empty grids and these are of course not part of the savegame.

How is that a problem? You won't get an object for an empty grid, or it wouldn't be empty.

Of course if you don't store empty grids, then after loading you have a bunch of spots without grid, so you can't go there in the game, unless you fill the holes in some way before you need them.

Yes, not storing empty grids is actually a problem for me. Let's say we have one row of this grid, slot 1 2 3 and 4. Now, 1, 2 and 4 are filled, therefore not empty. Only 1, 2 and 4 are being serialised, because why store empty spots?

Sadly, when we deserialise the file, these contents lack their original grid-position as e.g. x = 32 and y = 0 mean nothing in a grid-world. The first object would go in grid-slot 1, 2nd in 2, but the original 4th positioned object would go in grid-slot 3, because there is nothing left. First read first placed, kind of sorting behaviour. Because the level-loader cannot know, whether a grid will be used, the serialised-file contains no information about what grid-slots to avoid.

I define empty as, no object has been inserted at a given grid-slot. A user could create a 20x20 grid, but use only a few slots within this 20x20 grid. Hence not used grid-slots are empty.

2 hours ago, Alberth said:

How is that a problem? You won't get an object for an empty grid, or it wouldn't be empty.

At the moment, the game cannot know if a grid will be empty. It would be just a NULL'd element within a list/vector. That is the actual problem for me.

Should I just serialise empty grid-slots? Sounds like an immense waste of space, but that would allow me to serialise in order (grid-slot 1 to last) and deserialise in the same pattern.

obj_1 = { .. some values ..}
obj_2 = { .. some values ..}
obj_3 = { empty }
obj_4 = { .. some values ..}

2 hours ago, Alberth said:

Why is that awkward? You claim you are not going to store empty girds. Therefore, apparently, the grids themselves have nothing of interest to store, only the objects they contain are of interest.

To re-interpret coordinates to grid-slots just sounded odd to me, but that technique would help me to avoid serialising empty grid-slots. And math is probably faster than meddling with disk-speed, haha.

Anything with IO is slow as hell anyway. You can add XML encoding of the information to make extra sure it's slow enough

Tbh, I am somewhat surprised that the grids themselves have no coordinates, then you could store them at the right spot. The simpler option is however likely just serialize empty grids too, it's empty anyway, so not much additionally content gets written.

You seem to worry much about size and speed for no good reason. Disks are always the limiting factor rather than processor speed, I don't think it's possible to keep a CPU hot from writing a file to disk. Also, disks go for 1TB / 50 euro, and likely even less nowadays. I'd start worrying when you get savegames of around a GB. Until that time, disk-space is a non-issue.

I decided to go with a vector/list, because I do not need any physics-calculation but "give left/right/... neighbour of grid-slot"-logic.

Oh, I worry about size and speed because this application should run on phones, too. Just trying to provide rather light-weight level-files and keep loading/saving times low, as multiple levels could be downloaded.

Overall, I just got curious if there is already a similar way of handling this case : ) Thanks for your input!

8 hours ago, Angelic Ice said:

I decided to go with a vector/list, because I do not need any physics-calculation but "give left/right/... neighbour of grid-slot"-logic.

That seems like a good idea, and indeed you don't need coordinates in a grid there.

That does not mean however that you cannot have coordinates in a grid in a file, imho. Nobody said there has to be a 1-to-1 mapping between an object in memory and that same object in a file.

I usually design both cases separately (while keeping in mind that making them more equal simplifies matters), and then write a conversion between both formats for loading and saving.