Hello,

So I was wondering if there is any book, article, or personal opinion on some of the best ways to create a tile system for a tile based game using C++ (I'm using SDL, possibly OpenGL). What I mean is the best ways to abstract all the components to a tile map, reading them, and other optimizations that may help in the future and/or avoid personal problems you realized down the road.

E.g Finding out you couldn't support a huge map, or speeding up loading, collision, etc.

I know you can get by doing what most people are always taught when showing a tile map example, but I'm more interested in what a professional developer/team would do?. I'm just trying to figure out the best way structurally, most convenience, customizable, and efficiency wise. I haven't decided yet, but I might just read from Tiled Editor using either Lua or Json. Although, I feel like procedurally generating a map would be difficult that way? With that said the goal still remains on abstracting it all cleanly.

In Addition: Also, your thoughts on chunk systems and any great resources on accomplishing chunk systems (books, videos, articles, source codes). I also wanted to clarify there is no actual project yet as I'm finishing up my engine and ECS, so I'd like to have it as customizable as possible so if I need a hypothetical 10,000x10,000 map or a 50x50 map I have the option to do it easily.

Thanks!

Within the time you have spent to write the question here, you could have implemented it by using 2d arrays and for cycle.

LedMar said:
What I mean is the best ways to abstract all the components to a tile map, reading them, and other optimizations that may help in the future and/or avoid personal problems you realized down the road

That doesn't exist.

You make assumptions about your tiles, eg rectangular, fixed size, systematic positioning in the grid, finite size, etc. You use those assumptions to create software for handling tiles, eg rectangular fixed size tiles at a fixed position in a finite grid can be stored in an array. Now what you are saying is that anything may change, really anything (you're not limiting what may change). As a result, even for a case just described, array goes out the window since the assumptions may not hold tomorrow. Now what? A quad-tree? what if you decide tomorrow you want polar coordinates? etc. With every software structure you make some changes very difficult to impossible, there is no way around it. If anything can change, then you cannot use that in the software as it will break the software if in the future you ever decide that must change.

Thus if you want to make any possible change in the future, there is no structure left for writing software. Thus you cannot write a system. Anything you write has structure, has assumptions that may not hold tomorrow.

The best system available to us is to make an implementation that is simple enough to do what you want it to do today (and not more). Preferably it should also be the simplest possible implementation, but that is harder to reach.

So yes, tomorrow your simple system may not be enough. If you raise the requirements, “simple enough to do what you want it to do today” might break. So what you do then is enhance the implementation such that the rule applies again, and you're back to the best system you can have today.