As the topic states I am trying to write a top-down tile-based game, something like RimWorld or Prison Architect. Where the player can manipulate the world in different ways.

But before I just go ahead and start writing code I am trying to decide on the structure of the world. There are multiple ways of dealing with this I know, but maybe someone can put me on the right track.

For one option I was thinking of having a two-dimensional array of Tile objects

Each tile has a position as well as having a collection of Entities.

Each entity having a position and rotation relative to the Tile as well as a texture to draw. This way I can find a tile instance from the Map, add a table, and put a vase on top if it very easily.

To draw I would just call Tile.Draw() and it would draw all it's entities.

I see alot of advantages with this approach, like I only have to check if the Tile is on screen before I draw it. Plus it's really easy to detect what items the user wants to manipulate.

On the downside it makes it harder to place bigger entities, like a table that spans 2x4 tiles, Especially if the player can move/place/remove items in the world.

What other ways are good? I could keep a big list of entities, maybe grouped by position, so for each 25x25 tiles I will have one list containing everything in that area. But again I would have to keep in mind some items may span multiple areas.

It all ends with me being confused as to what is the best/a good/an acceptable way to store and manipulate a world where everything can be moved, rotated, removed and added And when I am confused I get unproductive.

I have been trying to google but I guess I keep searching for the wrong keywords, because I can't find much usefull information. So any hints and pointers are very welcome.

What's left for the tiles? Indices to the image. These could be stored directly, so you end up with a much simpler two dimensional array.

Indices to animations, which contain indices to the image? You'll want to animate your tiles - especially for things like water.

Also, for things like walls, you might want collision data baked into the tile data - maybe (it depends on your game's requirements).

So what you probably end up with is that the map is an array of indices to some kind of tile data struct, which is shared between all "tiles" in maps in the game.

struct TileDetails
{
    std::vector<ImageSubrect> animationFrames;
    Type type; //For whatever logic your game needs - 'Water', 'Lava', 'Wall', 'Trap', etc...
};

You do run into some cases where you need data directly at a specific location in a map - teleporting (where does it warp the player to?), and script triggers (which script does it trigger?) - but those kinds cases could be handled separately than the grid-based regular tiles.