Author Topic: Tile Groups  (Read 2181 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Tile Groups
« on: November 14, 2006, 02:36:32 AM »
Well, I've been taking a look at the tile groups found at the end of .map files again recently. When it was first discovered what that data represented, it seemed very useful for people making new maps. But even with the use of those tile groups, it's still very laborious to make new maps. I took a second look at them recently to see how useful they might be for more automated tools for map generation. The main complaint here being that the tilesets and tile groups don't really have any meta data associated with them that's useful for an automated tool. Such as, what are all the tiles of a given terrain type? What tileset transitions are appropriate where? Some findings were good, others not so much.


First of all, every tile in all the tilesets is found in some tile group. Yes, there are no unused tiles in the tilesets (with respect to the tile groups). (Even though there are some tiles that are never used in any of the maps).

Secondly, aside from a few tiles in the lava tileset, no tile appears more than once. That is, every tile (outside of the lava tileset) appears exactly once, in exactly one tile group.


Another observation is that only tiles in the lava tileset are animated.

Ok, so what does this mean? Well, if we ignore the lava tileset for the moment, then things get simpler. No animated tiles, and every tile appears exactly once in all the tile groups. Also, since no map uses the tiles in the lava tileset (at the initial startup stored in the map file), it's quite reasonable for someone making a map to ignore this tileset. (Yes, you COULD place lava on a map. But that doesn't usually get placed until after a volcano has erupted after the start of a level.) So, I'll just ignore the oddities of the lava tileset for the rest of this.


That means the tile groups form a nice partition of all available tiles into groups of related tiles. This is useful for automated generation, since you can know what the exact use of each tile is, (that is, what group it belongs to), and place it where it's best suited. Granted, some more work could be done grouping tile groups into groups. Some groups represent small sections of ridges. These ridge groups might be combined into a collection of all ridges for a certain terrain type. Then when ridges need to be placed on a certain terrain type, the tool would know where to look. You might even go farther, and order the groups according to the directionality of the ridges.

Terrain transitions are also grouped nicely. So when trying to get edges between say, rock and mud, or mud and sand, you have only to look in the group that contains all tiles for that purpose. Each transition type has an associated group of 48 tiles. They appear to be mostly in a set order. There are a few oddball entries where the directionality among the different transition groups doesn't seem to match up between corresponding tiles. That's a big pain in the butt for an automated tool. But maybe it's close enough that you wouldn't notice it too much. Pretty much all the built in maps have areas with rough edges that don't quite look like they match up right. I guess you can at least hope to do no worse.

Another problem with the terrain transitions is that there isn't an obvious ordering to them. They appear largely consistent across the different transition groups, but it's not obvious how to automatically select the right tile from any group given a specific transition situation.


There are various "doodads" that can be placed on the map. (I'll use the SC editor terminology here). Some of them are usually marked as impassible in the built in maps, while other are usually marked as passable. This type of information is not present anywhere in the tilesets or tile groups. But given a tile group, it generally wouldn't be too hard for a person looking at it to guess and assign a value. If this data were saved, it could be used in an automated tool.

Cliffs also have a low side and a high side associated with them. That data isn't present anywhere in the tilesets or tile groups, and is needed to place tile correctly and have them function as expected in the game. This is similar to the above passability issue though, since it's the same data field that controls it.

An automated scan of the built in map files could help reassociate this data, but when attempted a while back, it was found that any given tile could have a number of celltypes (passability, cliff high side/low side, etc.) associated with it. Combine that with the fact that not every tile was used in the original maps means that not every tile will have an associated celltype from such a scan. Thus we have the problem of tiles have 0, or more than 1 celltype associated with it. How would an automated tool select the right celltype? And would you trust it if it did?

I guess that leads me to think we should try to regenerate this data by hand so that each tile has exactly 1 celltype associated with it. That would make it much easier for a tool to properly handle celltypes.


Another issues is that some tile groups are meant to be placed in one big lump together, while other tile groups are meant to have a single tile from them placed. This is the different between placing a large volcanoe, or a large crater, or a large boulder, as opposed to placing a small crater (there are a bunch of single tile, small craters, all placed in the same group), or a terrain transition tile (all transition tiles between a given set of terrain types are in the same group). To be really useful, these two types of tile groups will need to be sorted out.


There is also the issue of overlapping tile groups. That is, you can place a tile group down on a map, and then place another tile group on the map that partially overlaps the first one. It might still look good, or it might not. Most of the ridges that appear in the game actually fall into the case of overlapping tile groups. It allows for much more varied ridge configurations, and branching than non overlapping tile groups would allow. This means that a tool to automatically place ridges is either going to be limited, or likely produce very ugly results. Definately some more work will be needed to auto place nice ridges.

The above discussion on ridge placement is also ignoring directionality. Even if two ridge tile groups don't overlap, they might not look good palced next to each other. More meta data is needed to specify where adjacent ridge tile groups can/need to be placed. At least the directionality should be obvious from where placement is needed. (I hope).


I also did some analysis of builtin maps. I wanted to see how well they could be decomposed into tile groups. I started by identifying all groups that appear exactly the same in a map. Then I would remove them and replace those sections with the blue tile (tile 0). Then I repeated the tile group finding algorithm, where a blue tile matched as a don't care condition. A helpful speed up to this matching process was that each tile appeared in exactly one tile group in exactly one place. So given a non blue tile, I could lookup in an array what tile group it belonged to, and at which (x,y) offset within that group, and then do a compare with that tile group on the surrounding tiles (at an offset so the given tile matched up with where it should be in the group). If a match was found, using the blue tile as a don't care condition, then I replaced the non blue tiles in that match with blue tiles. (Had to ignore the dummy tile groups containing only blue tiles, as they were becomming a problem). I also allowed single tiles in specific groups to always match. So terrain transitions would always match on single tiles, since you've never find the entire group of transitions all at once. I did this for a few other groups where it seemed obvious, or possibly likely. I basically iterated this procedure a few times and took a look at how much of the map would go away. I did this for a few maps to see what the results would be.

One thing I noticed is that ridges almost always remained. They never appeared to be a simple overlap case. That is, they never appeared to be a case where a finite number of tile groups could be overlapped to form the graphics for the ridges. In other words they did a lot of partial mixing where part of one tile group was placed next to part of another tile group, rather than an entire tile group being placed next to, or partly over another tile group. This seems to be more bad news for ridge placement.

The other thing that didn't tend to go away, was vegetation. Often the vegetation didn't seem right and was graphically ugly, but not always. It seems vegatation was placed in a haphazard way, somewhat similar to ridges. There was also the ugly boulder overlaps that you can usually tell just weren't done right and are graphically ugly.

Another thing I noticed, was there were a significant number of groups that matched for the base terrain types, but unless you allowed single tiles in these groups to match, most of the terrain didn't go away. I haven't checked into the probability of the entire groups matching given terrain that was placed randomly one tile at a time though. Maybe those matches are just a case of dumb luck. Although, from my initial observations, I'm led to believe they occur much too frequently, and terrain was placed (at least some of the time) using the tile groups to place big blocks all at once. (Often overlapping blocks). However, like I said earlier, much of the terrain didn't go away without individual tile matching, so there was obviously a lot of single tile placement, or partial tile group placement.



Hopefully someone else can use some of these findings to further development of automated tools for map making.
 

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
Tile Groups
« Reply #1 on: November 14, 2006, 02:11:34 PM »
The one thing I've noticed, when you talk about the vegetation tiles, is that most of the base tiles for a certain type of terrain (one of the 6 'base' terrains like the rocky plains, sand dunes, etc) can be intermixed with no regard to what tile goes next to what, and it will still look for the most part accurate / correct (if you look closely you might see minor imperfections however).

Yeah, the ordering of the transitions in those transition groups makes me think there had to be some sort of preset logic for each piece (i.e. the tile at (3,1) of roctomud can be used in a certain predefined way).

I do have a few of the dialog, cursor and bitmap resources from their map editor (it was in the OP2 pre-release demo) but it doesn't really tell much. However, as I was telling Hooman last night, it didn't appear that they could edit the tile groups in the editor itself (like they were imported from some sort of external data file into all maps). (Although that doesn't explain why the data is tacked onto the end of the map files)

I believe the tile groups were known as 'landforms' in the Dynamix editor. The dialog I believe consisted of a list box (presumably holding names of the different tile groups).

There has to be some sort of meta data somewhere else as well (or more predefined / hardcoded rules for dealing with parts of the tile groups) since some of the tile groups are just a series of tubes / walls / lava animation 'frames'... some how the map editor probably dealt with those using more external data.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Tile Groups
« Reply #2 on: November 14, 2006, 05:39:18 PM »
Keep in mind that the map editor didn't really have to deal with a lot of those tiles. Tubes, walls, bulldozed terrain, and lava never appear in any of the map files. They just need to be included in the referenced tilesets, and in a certain order, so they game can place them correctly on the map after the level has started. I think maybe some of it was just hardcoded into the game, and the map editor didn't really need to know or care about some of that stuff.



Here's some rough sorting of tile groups that I used in some of my tests.


The following tile groups are the base tile groups:
---
1 mudbas1
2 mudbas2
73 rocbas1
74 rocbas2
75 rocbas3
76 rocbas4
77 rocbas5
124 sanbas1
125 sanbas2
126 sanbas3
127 sanbas4
128 sanbas5
---


The following tile groups are transition tile groups:
---
92 roctola3
93 roctomud
170 santomud
171 santoroc
---


The following tile groups are groups of (non special) single tiles:
---
50 mudrock5
51 mudrock6
89 rocroc4
129 sancrat1
162 sanrok03
163 sanrok04
203 snowroc9
---


The following tile groups are groups of (special) single tiles:
---
14 mudlavw
33 mudmicw
52 mudrub01
53 mudrub02
55 mudwall1
56 mudwall2
57 mudwall3
84 roclavw
85 rocmicw
90 rocrub01
91 rocrub02
100 rocwall1
101 rocwall2
102 rocwall3
123 roczlav
141 sanlavw
159 sanmicw
168 sanrub01
169 sanrub02
173 sanwall1
174 sanwall2
175 sanwall3
206 muddoz2
207 mudtube2
208 rocdoz2
209 roctube2
210 sandoz2
211 santube2
212 LEFT_LAVA
213 midd_lava
214 RIGHT_LAVA
215 mudburn
216 rocburn
217 sanburn
---


The following tile groups contain only the tile 0
(should probably ignore these) :
---
0 BLUE
13 muddoz
54 mudtubes
83 rocdoz
94 roctubes
140 sandoz
172 santube
---



Basically you can ignore the empty tile groups that only contain the tile 0, and the special tile groups that contain a bunch of related, but single, tiles. Everything else seems to have been fair game for placing on a map though.

That's not to say you can't place that stuff on a map. It's just it never has been placed on a map in the built in levels, and you can do perfectly fine without it. It's also the type of stuff you wouldn't really want to place on a map with an autmated tool. At least not a general one. You'd only want to do that stuff for oddball special case maps.

All the groups not listed above appear to be blocks of tiles that form some larger object. They're the types of groups you'd want to place all at once. They all contain entire objects, except for the ridge ones, which would have to be chained together somehow.


Oh, and one of the vegetation tile groups has rough edges, and there don't appear to be other vegetation tile groups that can be placed next to it to smooth out the edges. It sort of reminds me of the how you have to deal with the ridge tile groups, except this vegetation tile group doesn't have any other related tile groups to link up the edges with.
 

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Tile Groups
« Reply #3 on: November 17, 2006, 12:43:49 AM »
I played around with the terrain transitions in the map editor today. I was trying to see how well I could get certain edges to line up nicely. It didn't go so well. There were a few tiles that I just couldn't seem to place anything next to and still have it look right.

I'm also not really sure how to properly select the right transition tile automatically. There seems to be order in the groups, but nothing I can pick out that would be useful in an automated tool for selecting the right tile.

Here's the transition sets for anyone else who want's to take a look.




Oh, and maybe I'm crazy here, but if you look REALLY closely at the transition groups, and compare them to the base terrain types, it appears they were reusing tiles. It looks like they just sort of overlaid the other terrain type, and did a bit of blending.

If you enlarge this image, you'll see what I mean.


It also interesting to note the periodicity. It looks like they pasted the base terrain group 4 times for the mud terrain, and then used some kind of mask or alpha blending to overlay the rock terrain tiles to create the transitions. It would also explain some of the uniformity among the transitions between the different tile sets.

On the other hand, it makes me wonder even more about the few tiles that don't quite seem to be the same. Even their directionality seems to be different. For instance, if the top left corner of each transition group is (1,1), then take a look at (4, 5) in the image at the top, and compare the mud to rock transition group with the mud to sand and roc to sand transition groups. It looks like the directionality is completely different.


I also played around with the first group of plants in the editor. I only found one tile that looks like it meets up with one of the edges properly. The other edges don't seem to have any tiles that can be placed adjacent to them and still look right.
« Last Edit: November 17, 2006, 12:44:53 AM by Hooman »