http://ufoai.org/w/index.php?title=Mapping/Random_map_assembly&feed=atom&action=historyMapping/Random map assembly - Revision history2024-03-29T11:35:24ZRevision history for this page on the wikiMediaWiki 1.35.4http://ufoai.org/w/index.php?title=Mapping/Random_map_assembly&diff=41405&oldid=prevMattn at 20:35, 20 March 20132013-03-20T20:35:21Z<p></p>
<p><b>New page</b></p><div>==General==<br />
The '''ump''' files can be loaded via <pre>map <day|night> +[ump-filename] [theme]</pre><br />
They have to be in the {{path|base/maps}} (see [[directory tree]]) folder<br />
<br />
==ump-format==<br />
===Worldspawn===<br />
Often you want shared worldspawn settings for a theme. For this you can define the worldspawn settings in the ump file.<br />
<pre><br />
worldspawn {<br />
"key" "value"<br />
"key2" "value2"<br />
[...]<br />
}<br />
</pre><br />
<br />
See [[Mapping/Entities/Worldspawn|worldspawn]] entity article for more details on the keys/values.<br />
<br />
If you want to use this feature, there is a contract in terms of ump filename and ump directory structure. E.g. if you compile a map in {{path|base/maps/frozen}} the ump filename must be {{path|frozen.ump}}. The directory part will be taken in ufo2map to identify the related ump file.<br />
<br />
===Tiles===<br />
<br />
Each tile that is to be used in random map assembly must have a tile definition created.<br />
<br />
Here is the example I'll use for my explanations:<br />
<pre><br />
// *********************************<br />
// MIDDLE EUROPEAN VILLAGE<br />
// *********************************<br />
<br />
base villaged/vil_<br />
<br />
tile +s01<br />
{<br />
4 5<br />
<br />
0 0 c 0<br />
0 a +c a<br />
0 a +a a<br />
b +b +a a<br />
0 a a 0<br />
}<br />
</pre><br />
<br />
This describes one tile for the middle european village structure, a streetcorner running from north to west.<br />
<br />
The comments are in C-style as <code>//</code> and <code>/* comment */</code><br />
<br />
'''extends''': You can inherit tiles from other themes by extending an existing ump file. You can only reference those tiles with the full name, because the base may differ between the ump files. Only one level of inheritance is supported.<br />
<br />
'''base''': This part only gives the base string where all the other tiles are appended to<br />
tile +[some tile name]: The + means that the base part from above is to be included here. For this example, the file in question would be found in \base\maps\villaged\vil_s01.<br />
<br />
'''4 5''' defines the area of the tile with an extra border. In the case above, the tile is actually only 4 tiles total in size (the + fields), but it requires 2x3 worth of space to define it. The border defines which tiles can be next to your solid (again the + fields) tiles.<br />
<br />
Basically, '''4 5''' part defines the size of the following matrix.<br />
Note that you should always enclose all your existing map tiles with "requirement" fields (without '''+''' mark).<br />
<br />
The next part gives information about how to assemble the map. Our example tile is a L-shaped street.<br />
<br />
The fields with a '''+''' as first char tell us that there is really something that was mapped - in our case a street. Load the map in [[Mapping|UFORadiant]] and examine the map, also noting where the zero-point in coordinate plane is (lower left corner of the lower left tile). The grid in the script above makes more sense if you open the map up and block out the 256x256 'tiles' that exist on the map. If you're not sure what is meant by map tiles, please go [[Mapping/Random map parts|here]].<br />
<br />
The letters are used to indicate the type of tile:<br />
<br />
* a: placeholder for all types of tiles (generic tile)<br />
* b: street horizontal<br />
* c: street vertical<br />
* 0: no requirements to the tile<br />
<br />
These indicator codes are built on a per {{path|.ump}} file basis. The letter '''b''', in another {{path|.ump}}, could mean something completely different. The fields that don't have a '''+''' on them means that for this map to be included, that tile type must exist in that position neighbouring it. Think about it like a puzzle.<br />
<br />
Fields with '''+''' denote fields that the tile we are currently defining actually has. Fields without '''+''' denote the space around the current tile. The tile definition is a 2D matrix of our tile and it's surroundings.<br />
The character is defined in tile definition - so, '''+c''' in a location means that the specific area gets assigned letter '''c''' and that is the letter other tiles can refer to.<br />
<br />
These chars can be a single '''a''', '''b''' or '''c''' or, for example, '''ab''' to define an combination of allowed tiles.<br />
<br />
For an example, the third line down is '''b +b +a a'''. This means there '''must''' be a 'street horizontal' from another tile to the left, there '''exists''' a 'street horizontal' at the second position, there '''exists''' a 'generic tile' in the third position, and there '''must''' be a 'generic tile' in the fourth position. This expands horizontally and vertically.<br />
<br />
The generic tile is the most common here, the '''a''' tile. Our generic tile-definition is a tile from the village - it could be houses, parks, anything not a street according to the current definitions.<br />
<br />
As described, there may be more than one char in a grid position - lets look at a little 1x1 curve.<br />
<br />
In the example '''+bc''' means that the tile properties for horizontal and vertical are existing in the built tile.<br />
<br />
Notice how the c is only above, and the b only to the left, of the 'real' tile. This will ensure that we only get our vertical street from above and our horizontal street from the left. The two '''a''''s will make sure we don't get a horizontal or vertical from the right or below, where the curve doesn't actually connect.<br />
<br />
<pre><br />
tile +s05<br />
{<br />
3 3<br />
<br />
0 c 0<br />
b +bc a<br />
0 a 0<br />
}<br />
</pre><br />
<br />
There may be also more than one char in the demand-field (the surrounding indicators).<br />
<pre><br />
tile +r01<br />
{<br />
4 4<br />
<br />
0 ab ab 0<br />
ac +a +a ac<br />
ac +a +a ac<br />
0 ab ab 0<br />
}<br />
</pre><br />
Only one demand must be fulfilled. In the example of tile '''r01''' there may be horizontal street <br />
above or/and below or a gap-filler (e.g. a playground), therefore ab is used. The '''ac''' makes sure only vertical streets and generic tiles are to the left and right.<br />
<br />
If you want a particular tile to always appear at the edge of a map, use a symbol that is not supplied anywhere (for example, use "z", but don't define any tile as "+z").<br />
<br />
===Assembly===<br />
Each random map definition file must have at least one assembly. If the file has several assemblies and none is specified when the map is loaded, one of the existing assemblies is chosen randomly.<br />
<pre><br />
assembly residential<br />
{<br />
size "6 6"<br />
grid "2 2"<br />
+s01 "1 2"<br />
+s02 "0 2"<br />
[..]<br />
+drop "1 1"<br />
}<br />
</pre><br />
To start a map you can type <code>map +villagen residential</code>. <br />
The '''residential''' parameter will chose a '''residential''' assembly-theme from the '''ump-file'''.<br />
<br />
Now lets talk about the format. As you see in the above example for '''assembly residential''' you can define which size the map theme should have. <br />
This is done with the parameter '''size''' ([[V_POS]] - 2 dimensional vector for x and y).<br />
<br />
Size parameter specifies the grid size of the assembled, final map without "requirement" fields specified before. For example, if you had two tiles, each with size "4 4", putting them together would require size of "2 4" (or "4 2", depending on orientation).<br />
<br />
<pre><br />
tile +h01<br />
{<br />
4 4<br />
<br />
0 a a 0<br />
a +a +a a<br />
a +a +a a<br />
0 a a 0<br />
}<br />
<br />
assembly double<br />
{<br />
size "2 4"<br />
+h01 "2 2"<br />
}<br />
</pre><br />
<br />
Notice how tile definition has size "4 4", but actual tile is only 2x2, thus allowing only two possible rectangle formations, one of whom is used in the assembly - "2 4".<br />
<br />
You can also specify a '''grid''' parameter ([[V_POS]]) to optimize the assemby as long as all your tiles have the same size or are multiples of it.<br />
<br />
After this parameter all available tiles can be listed with a min and max value for their amount of appearance (min and max).<br />
<br />
You can also place tiles via the '''fix''' parameter:<br />
<pre><br />
assembly this_has_a_fixed_tile<br />
{<br />
size "5 5"<br />
fix +s01 "2 2"<br />
+s02 "1 2"<br />
}<br />
</pre><br />
<br />
The numbers in "" behind the fix parameter show you the position (x-y-Coordinate) of your tile in the mapgrid. With its origin "0 0" in the bottom left corner of the map.<br />
<br />
You can also replace fixed tileids with cvars<br />
<pre><br />
assembly this_has_a_cvar_tile<br />
{<br />
size "5 5"<br />
[..]<br />
*this_is_the_cvar_name this_is_the_default_value "1 1"<br />
}<br />
</pre><br />
Now the assembly function will use the value of {{cvar|this_is_the_cvar_name}} as tile id - if no value is given via this cvar - the default value '''this_is_the_default_value''' will be used. The min and max values are the same as for the other tile ids.<br />
It's a naming convention to start these cvar names with the prefix '''rm_''' (as in '''r'''andom '''m'''ap) - e.g. {{cvar|rm_dropship}}.<br />
<br />
Of note, you need to include enough smaller tile maps to fill in holes left if the bigger ones are used. If you build a 3x2 map, and the L shaped tile map from the first example is used, you'd need a 2x1, or 2 1x1, maps to fill in the hole.<br />
<br />
Multiplayer only maps can be defined, too. Just add a line like:<br />
<pre><br />
assembly this_has_a_multiplayer_only_tile<br />
{<br />
[..]<br />
multiplayer +s02<br />
}<br />
</pre><br />
to your assembly.<br />
<br />
===Tilesets===<br />
You can define tilesets to define a set of tiles that should be used in the same was as you would define to be used tiles in an assembly - just not a tile id, but a tileset id. The format would be:<br />
<pre><br />
tileset mytileset <br />
{<br />
[...]<br />
+mytile1<br />
+mytile2<br />
+mytile3<br />
}<br />
<br />
assembly uses_a_tileset<br />
{<br />
[..]<br />
tileset mytileset "0 1"<br />
}<br />
</pre><br />
<br />
==Missions with map assembly==<br />
You can define your missions that should be generated with the random map assembly algorithm in the [[UFO-Scripts/maps.ufo|maps definition]] script file.<br />
<br />
==Available themes/assemblies==<br />
* [[Mapping/africa|africa]]<br />
* [[Mapping/cemetery|cemetery]]<br />
* [[Mapping/city_disco|city_disco]]<br />
* [[Mapping/country|country]]<br />
* [[Mapping/desert|desert]]<br />
* [[Mapping/farm|farm]]<br />
* [[Mapping/forest|forest]]<br />
* [[Mapping/frozen|frozen]]<br />
* [[Mapping/ice|ice]]<br />
* [[Mapping/industrial|industrial]]<br />
* [[Mapping/oriental|oriental]]<br />
* [[Mapping/tropic|tropic]]<br />
* [[Mapping/ufocrash|ufocrash]]<br />
* [[Mapping/village|village]]<br />
<br />
:also see [[Mapping/List of Maps]]<br />
<br />
==Links==<br />
* [[Mapping/Random map assembly/Algorithm|RMA Algorithm]] By Gerd Heiße<br />
* [[Mapping/List_of_Maps#Mapassembly_Themes|Map assembly themes]]<br />
* [[Mapping:Random map parts|Random map parts tutorials]]<br />
* [[Mapping]]<br />
<br />
[[Category:Mapping]]<br />
[[Category:Contribute]]</div>Mattn