Labeling Areas on a map

Question

I've been wondering how you would go about labeling an area on a 2D tile map. What I'd like to do is associate tiles with an area i.e Forest Area, Desert Area, etc.

Keep in mind this is an idea, so far I've been thinking that one way to go about this is to have each area store tile positions as the pivot points and you need at least four of these pivot points before it is a valid area. This way would allow for some of the granularity I would like as my first idea was to just associate every tile with an area id, which is pretty inefficient time-wise, though the task would have been alleviated somewhat with a map editor that I am going to build (i.e. just paint a tile with an area color/number).

What are your ideas on this?

Also, the map, areas, and etc will be stored in an sql database FYI.

Answer 1

I've done something similar to this using an abstract concept of Area. An Area is just basically collection of Tiles, calculated at run time, but will allow you to work with that collection much easier. An Area made up of a collection of individual Tiles will also allow you to have irregular (not just square) areas of forests and deserts.

Using this concept, you can also join up Areas if say for example, a tree grows between two adjacent forests. Your code can then determine whether it joins two areas, and if so, combine them into one.

The Area would not be persisted into a database, but calculated at run time. The Tiles themselves are the actual data that would be stored (and created in your map editor). The Area would just make working with a large collection of tiles easier. A Tile knows nothing about the Area it is contained within. All game logic would then deal with the concept of Area rather than Tile. This should be much faster as there are usually a lot less Areas than Tiles.

In your game, you might want to know what Area your player is in, and assign associated values to the size of that Area. For example if your player is in a large forest (Area.GetSize() returns the actual number of Tiles), then the chance of encountering a more lethal enemy might increase. Likewise, entering a small desert might drain the players endurance less.

In order to work out the areas to begin with, you would need to iterate over every tile in your map when you load the map. If that Tile was not next to an Area of the same type, create a new Area and add that Tile to it. If the Tile is next to an similar Area, just add that Tile to it.

If a Tile is adjacent to more than one Area of the same type, combine all Tiles contained in all of those Areas into one Area.

Then if you are simulating a growing / changing world and a new forest does sprout, just use the same method as above to see whether that Tile is adjacent to an Area and act accordingly.

Answer 2

Not sure if associating each tile to its type should be a major concern in terms of execution speed. You'll only be doing this when the game loads, not on every frame. Regarding how I'd do it:

I would define simple rectangle structures in case there are none defined in your environment:

structure Rect has components:
    XPosition : integer
    YPosition : integer
    Width : integer
    Height : integer

and extend this to:

structure AreaTypeRect has components:
      <components from Rect>
      AreaType[] : symbol

And store them in a SQL (since you're using it) table. Map each rectangle to the level it belongs to with a foreign key.

Basically, the rectangle with XPosition = 5, YPosition = 5, Width = 10, Height = 10 means the tiles in the rectangle defined by the points (5, 5), (5, 15), (15, 5), (15, 15). Why did I define AreaType as array? You may define it as a single value-type if you absolutely won't need terrain type blending. But you might reach some nice effects with multiple types per tile. For example, you could mark a particular tile to be of the type Grass and then add the type Water to it. This could result in a Grass tile with some Water stains on it, as if it rained a lot.

I might be overthinking this though. Perhaps a single AreaType per tile is enough for your needs. AreaType can be any kind of symbol, but you must tell your game how to interpret it. I would go with integers and map them like this:

(integer AreaTypeID, Texture TileSprite)

or with colors, as you mentioned you'll be using in the editor (blending colors from multiple terrain types is even easier):

(integer AreaTypeID, Color TileColor)

e.g.

(0, GrassTile)
(1, WoodTile)

You can do this mapping in a SQL table, if you do store things such as textures in the SQL database. I'd store artwork on the hard drive though.

Answer 3

Just add another column (of type string) to your 'tiles' table to allow you to enter values such as 'The valley of uncanny'?