How to Structure a Tile Based Game?

Don't derive tile types from a base class. You have a class/struct "Tile", and that class has some attributes.

At a basic level, it might have:

• Pointer to its image (shared among other tiles)
  
• A flag for collidable or not
  
• ...and a few others
  
  Your "world" is broken up into chunks. You only load each area when the player is within range of it. You don't need to have the entire world loaded at one time.
  Yes, each 'chunk' is a array of tiles. Maybe even an array of pointers to tiles, since you could probably share most the tile instances even - it depends on the game.
  
  You don't need to loop through every tile each time you want to check for collision... you just find out where the player is and check the tiles immediately surrounding the player.
  
  Have you made (completed, I should say) any game before this one? It might be a daunting task if you haven't ever completed something before.

Thank you I will consider what you've said. I think I was just over thinking the whole thing and this seems a lot simpler than what I was doing.

Quick question though for really complex tiles like water or lava should they be their own class/struct maybe called "Liquid" or whatever?

It depends on what kind of tile-based game you're making. Is it side-scrolling or overhead?

If overhead, your "Tile" class could look like this:

• Pointer to a vector of images (shared among other tiles)
  
• The current frame
  
• How much time left until the next frame
  
• A flag for collidable or not
  
• A flag for the type of noise that's made when walked on. ("Liquid", "Wood", "Stone", "Metal", etc...).
  
• A script to run every update tick when stood on (Like, "LavaDoDamage.script")
  
• ...and a few others
  
  
  That allows for basic animated tiles (Nothing fancy, no splash effects or whatever, but sufficient for some games).
  In general, don't go crazy with inheritance. Inheritance is a useful tool, but is not the solution to everything. Use it where needed, but prefer have things as member variables rather than inherited (but at the same time, don't be afraid to inherit if and when it's the better solution - just don't make it your default solution).
  
  I suppose this also depends on what programming language you're using also... my advice comes from a C++ viewpoint, and other languages may differ.
  
  How it's done really depends on the needs of the game. My WIP 2D turn-based tile-based RPG has multiple layers of tiles layered over each other, and I plan to have other special layers that aren't for images, but for things like what noise to make while walked on, or what script to trigger, separating the triggering of scripts and the playing sounds into a struct different from the ones dealing with the appearance of the tiles (because each tile in each layer doesn't need a sound, just one layer).

Ok thank you so much! I understand now.

I structured my own 2D tile map from tile types, which define all the attributes a tile has (image index to the image array, collision data, special flags, etc.).
The map itself is then a 2D array of indices to the tile types array.

This saves a whole lot of memory both while running the game, and on the disk, though the real intention was to make the map easily editable (I see editing a few tile types a whole lot easier than editing every single tile manually, but maybe that's just me).

To make empty tiles I just start the tile type indices at 1, so that every tile with value of 0 is to say "no tile type".

About collisions - you need only check the tiles around the player. You can get the exact tiles by converting your player coordinates to tile coordinates.

Suppose your player's coordinates are some point (x, y), and suppose every tile has the dimensions (w, h).
To instantly get what tile the player is on, simply divide the player's position by the tile size (x/w, y/h). This will result in the x/y indices of the tile.
For example, if the player's position is (200, 100) and the dimensions of each tile are (50, 50) then the player is on tile (4, 2).
That's converting your player's world space coordinates to tile space coordinates.

You should of course also take care of the player's dimensions. For example, if the above player's dimensions are also (50, 50), it is most likely that the player is intersecting with more than one tile, so take that into consideration.

I would say to just go with a physics engine like Box2D, but I really have no idea how optimal general physics engines are for uniform tile maps, which might have thousands to millions of tiles, yet are very, very efficient in terms of collision if done specifically for them.
You might want to check this out, as I've never yet used a physics engine.
While they are not meant specifically for uniform tile maps, they might have internal buckets (e.g. the well known quad tree) to filter out unneeded collisions, which are not as efficient as writing your own code, but are probably fast enough for you not to care.

If your game would be side scrolling then sometimes there would be empty tiles, like air...
To save memory and time of calculating you can use resizable array of pointers in current chunk which contains only solid tiles. To delete any tile from this array, for example

remove(i);

Copy last pointer in your array to i and then resize array. Pretty simple and working

If your game would be side scrolling then sometimes there would be empty tiles, like air...
To save memory and time of calculating you can use resizable array of pointers in current chunk which contains only solid tiles. To delete any tile from this array, for example

remove(i);

Copy last pointer in your array to i and then resize array. Pretty simple and working

That is good for the final representation, but for editing (if you support real time editing anyway), saving the full array is better, since otherwise you will keep deleting and allocating stuff with every change.