For the handling of buildings on a tile-based strategy game, what aproach should I use?

Question

On a tile-based game of the strategy genre, which allows the player to place buildings over the terrain tiles, there are multiple approaches that can be taken for handling such situation.

The ones that I immediately think about regarding that are:

1. Create two layers. One for the base tiles (terrain), and a second for buildings. And, for handling (operations before rendering), iterate them.
2. Create a single layer, with the tile class having both the reference to the base (terrain) and the building reference (null if no building at that tile). And for handling, iterate just one tile-map, but each iteration will then have to have an if(building!=null){...} added to it.

EDIT:

As further specification, the situation is that the game will be more focused on management and sandbox (tough combat will still be present), and every building will have many variables that are independent from the other buildings (even of the same type of building). NOTE: You can use the game "Caesar 3" as an example of what I'm going for.

For example, for "housing" buildings, they will have leveling, with a growth (level-up) based on the meeting of the required resources needed for the next level (from "materials", like wheat and wine, to access to specific "infrastructure", like public bathhouses or religious buildings), as well as the handling of such resources (current amount of "material X" stored, max amount of "material X" to be stored, consumption-ratio of "material X").

Another thing is, I don't need to literally render buildings on top of terrain (render both), and actually, I think it's probably a bad thing...So instead, I'm trying to do the handling in a way that will also not do unnecessary rendering. On the rendering loop, the building is rendered when its present, or the terrain otherwise. (This might be a worse approach instead of a better one, tough. Please tell me if so!)

EDIT 2: Please regard the part above as a note. This question is not as related to rendering as it is to handling! I'm beginning to think about removing it.

For my exemple aproaches, both would have a separated logical layer for buildings, as a single building can occupy more than a single tile (a building can be 2x2, 3x3 or 4x8 terrain-tiles, for example).

So, regarding terrain-to-building relation, approach-1 would would go:

2 iterating loops...

BUILDINGS-loop: "You are currently iterating me; I am above the following terrain-tiles: 1,2,3 and 4; My current resources are: [...]"

TERRAIN-loop: "(My coords are under a building, render that building instead!) || (I'm not under any buildings! Render me!)"

While approach-2 would go:

1 iterating loop...

TERRAIN-loop: "If you are searching for the building that was built over me, (it's null, render me!) || (its not null, proceed to the building's door, over there!)"

BUILDING: "Terrain x-y sent you to my door? (Sorry, i have already been iterated, skip me) || (Hmm, and it seems I have not been iterated yet! Alright then! My current resources are: [...]; Render me!)"

Note: The "render" parts are to be considered as just flags to be used by the rendering loop that comes after all handling is done, thus, not as the actual time the rendering happens.

END OF EDIT.

The questions are...

• Which is best overall? (why?)
• Is either best for a specific matter? (EX: "This uses more processing, but is less memory-heavy, because...")
• And, are there other (better?) approaches?

Answer 1

I prefer the first strategy because it allows a lot of liberty for rendering process. I use it for my 2D games since the day I had to make a building transparent... it avoids the massive use of conditions.

But the second method you suggest is pretty fine too. In fact it will depend of your needs and, except for specific features, both will allow you to do the same for different cost.

The important thing here is to know the important features you will have to deal with. But only the important ones. Make your choice on those features... then, when specifics will come, you will have to find a way to adapt your initial choice (and everything is possible, don't worry).

Answer 2

There is no "best overall". This is where the prohibition about premature optimization comes from; neither method is likely going to impact your performance in any measurable way.

Personally, I wouldn't make buildings tiles at all; they should be sprites. Technically, they are a modified form of unit. This allows them to act like units in meaningful ways. You can give them attacks for defensive buildings. They can die. They have a collision area. And most importantly, you can make the buildings move if you so desire (see Terran in StarCraft).

Answer 3

Assuming your buildings don't always occupy an entire tile, building over terrain is better. If the building occupies 100% of a tile and always 100% of a tile, then the building is just yet another terrain tile so that's a very simple problem.

Doing building drawn over terrain allows you to use transparency in your building tiles. That lets you do things like have buildings that don't occupy 100% of a tile. That might mean less than a single terrain, but it might mean MORE than a tile too. For example, you might want a building to cast a shadow, and that shadow extend into an adjacent tile. You can do this with semi-transparent textures.

Also, consider how you want to show tentative building placement. It's not an uncommon design to show a semi-transparent version of the building overlaid on the terrain as the user drags it around with a mouse. Letting go of the mouse (or clicking) places the building.

Depending on your game needs, you might even draw your buildings with multiple layers. Consider if you wanted to show inside of a building. You could have a graphic of the building without a roof, and then a roof graphic you draw on top of that. If you want to look inside the building, remove (or draw semi-transparent) the roof graphic. This is useful if you want the player to walk inside of a building.

Overall, the complexity of rendering terrain then tile on top is trivial compared to having to maintain a complex data/logic structure.