The rest of this page describes (though not fully) the contents of the tilespec file and related files. This is intended as developer reference, and for people wanting to create/compile alternative tilesets and modpacks for Freeciv.
Overview of Editing a Tileset
The purpose of the tilespec file and related spec files is to allow the detailed layout of the graphics within the files to be flexible and not hard-coded into Freeciv, and to allow add-ons to conveniently provide additional graphics.
There are two layers to the tilespec files:
The top-level file is named, eg: trident.tilespec. The basename of this file (here, trident) corresponds to the parameter of the --tiles command-line argument for the Freeciv client, as described above.
The top-level tilespec file contains general information on the full tileset, and a list of files which specify information about the individual graphics files. These filenames must be located somewhere in the data path, though not necessarily the same place as the top-level tilespec file. Note that with this system the number and contents of the referenced files are completely flexible at this level.
An exception is that the intro graphics must be in individual files, as listed in the tilespec file, because Freeciv treats these specially: these graphics are freed after the game starts, and reloaded later as necessary.
Graphics formats
Different clients support different graphics formats. All of them should support PNG, however, so this is what you should use. The XAW client only supported indexed PNGs in previous versions, but as of 2.1 and later supports full palette PNGs. For compatibility with older version, follow the steps below.
Using GIMP, you can use the following steps to convert an image to an indexed PNG:
- Choose the menu entry Image→Mode→Indexed (alt-I).
- Choose the Generate Optimal Palette option, with no color dithering.
- Accept these options.
- Choose the menu entry File→Save As...
- Save the file as xxx.png.
- I recommend choosing a high level of compression.
Tileset options
In the top-level tilespec file you can set options for the tileset. Each of these should go within the [tilespec] section. Currently options include:
Strings (enclosed in "")
- options
- A capability string, currently +Freeciv-2.3-tilespec
- name
- the name of the tileset
- city_names_font
- an X font string
- city_productions_font
- an X font string
- main_intro_file
- GFX file for the intro graphics
- minimap_intro_file
- GFX file for the radar screen intro graphics
Integers
- normal_tile_width
- the width of terrain tiles
- normal_tile_height
- the height of terrain tiles
- small_tile_width
- the width of icon sprites
- small_tile_height
- the height of icon sprites
- roadstyle
- Specifies how roads and rail are drawn:
- 0
- A single sprite is drawn for every connection the tile has; only 8 sprites are needed.
- 1
- A single sprite is drawn for all cardinal connections and a second sprite is drawn for all diagonal connections; 32 sprites are needed.
- 2
- One sprite is drawn to show roads in all directions. There are thus 256 road and 256 rail sprites (64 for a hex tileset).
- fogstyle
- Specifies how fog is drawn:
- 0
- A single fog sprite is drawn on top of all other sprites for fogged tiles. The tx.fog sprite is used for this.
- 1
- Each sprite for a fogged tile is drawn fogged. The tx.fog sprite may be used for the fog drawing (but clipped by the mask of the underlying sprite).
- 2
- No fog, typically used in conjunction with darkness_style 4.
- darkness_style
- Specifies how "encroaching darkness" is drawn:
- 0
- No darkness.
- 1
- A single sprite can be split into 4 parts, each containing the darkness for that particular cardinal direction. (Iso-view only.)
- 2
- Four different sprites exist, each holding the darkness for a particular direction. Any or all of the sprites may be drawn.
- 3
- The sprite is chosen based on the vector sum of the darkness in all 4 cardinal directions. 15 different sprites are needed.
- 4
- Darkness and fog are handled by 3^4=81 fogged, unknown, and known cardinally adjacent tiles, i.e., the four ordinary (N-E-S-W) or isometric (NE-SE-SW-NW) neighbors of a given tile. The kkkk combination (all known and no fog) is unused. TBD: Not yet supported for hex. tilesets.
- flag_offset_x
- flag_offset_y
- Gives an offset from the tile origin at which to draw flags behind units and cities. With isometric tilesets this should be non-zero so that the flag is placed correctly behind the unit/city.
- hex_side
- When is_hex is specified (see is_hex, below), this value gives the length of the extra side of the hexagon. This extra side will be on the top/bottom of the tile if is_isometric (below) is given, or on the left/right of the tile otherwise. The actual dimensions of the hex tile are determined from the normal_tile_width/normal_tile_height of the tileset as well as the hex side. The normal dimensions give the X and Y offsets between adjacent tiles in the tileset - this is not the same as the dimensions of the tile itself. The dimension of the bounding box of the hexagonal tile will be equal to the normal dimension minus the hex_side. For instance normal dimensions of 64x32 with a hex_side of 16 for an iso-hex tileset will give hexagons of size 48x32.
Booleans (FALSE or TRUE)
- is_isometric
- set to TRUE for an iso-view tileset
- is_hex
- set to TRUE for a hexagonal tileset. If is_isometric is also specified then you have an iso-hex tileset. Hex tilesets should be used with "Hexagonal" topologies and iso-hex tilesets with "Hexagonal" + "Isometric" topologies.
String lists (a comma-separated list of strings)
- files
- A list of .spec files to scan for sprites. See individual spec files, below.
Terrain options
The top-level tilespec file also contains information on how to draw each terrain type. For each terrain type include a section terrain_<terrain> (e.g., terrain_plains). This section contains information on how to draw this terrain type. (The terrain types are specified in the server ruleset file under the graphic and graphic_alt flags.)
[terrain_XXX] options
- is_blended
- If set, this terrain will be blended with adjacent terrains. Blending is done civ2-style with a dither mask. Only iso-view currently supports blending. Only the base graphic will be blended. Blending is drawn on top of the first layer (see below). The blending mask has sprite t.dither_tile.
- For 2.5 and later versions this will be blend_layer, because that reflects what it always was; blending in layer 0 or 1, but 2 is also possible. It's not a boolean value.
- num_layers
- The number of layers in the terrain. This value must be 1, 2, or 3. Each layer is drawn separately. The layerN options below control the drawing of each layer (N can be 0, 1, or 2, respectively, for up to three layers).
- layerN_match_type
- If 0 or unset, no terrain matching will be done and the base sprite will be drawn for the terrain. If non-zero, then terrain matching will be done. A matched sprite will be chosen that matches all cardinally adjacent tiles whose terrain has the same match_type.
- layerN_match_style
- A string telling how matching is to be done for this layer:
- none
- No matching is to be done.
- bool
- Matching is done based only on whether the adjacent tile has the same match type.
- full
- Matching is done against all possible match types of adjacent tiles.
- layerN_cell_type
- With traditional tilesets each tile is drawn using one sprite. Which sprite to use may be specified using a match_type, and there may be multiple layers (each having one sprite). This method corresponds to cell_type single. A more sophisticated drawing method breaks the tile up into 4 rectangles. Each rectangular cell is adjacent to 3 different tiles. Each adjacency is matched, giving 8 different sprites for each of the 4 cells.
Additionally the top-level tilespec file should contain information about the drawing of each layer. This is needed because the way each layer is drawn must be consistent between different terrain types. As an example you can mix boolean and no matching but you cannot mix full and boolean matching. You may not have more than 2 layers (either in this section or in the [terrain_XXX] sections).
[layerN] options
- match_style
- Gives the match style for this layer:
- none
- no matching.
- bool
- terrains may use none or bool for matching.
- full
- terrains may only use full matching.
- match_types
- Gives a string list of all different match types. This list must include every possible match_type used by terrains for this layer.
Individual spec files
Each spec file describes one graphics file (PNG format is standard, although some clients may accept other formats as well) as specified in the spec file. The graphics file must be in the Freeciv data path, but not necessarily in the same location as the spec file. Note you can have multiple spec files using a single graphics file in different ways.
The main data described in the spec file is in sections named [grid_*], where * is some arbitrary tag (but unique within each file). A grid corresponds to a regular rectangular array of tiles. In general one may have multiple grids in one file, but the default tilesets usually only have one per file. (Multiple grids would be useful to have different size tiles in the same file.) Each grid defines an origin (top left) and spacing, both in terms of pixels, and then refers to individual tiles of the grid by row and column. The origin, and rows and columns, are counted as (0,0) = top left.
Each individual tile is given a "tag", which is a string which is referenced in the code and/or from ruleset files. A grid may be sparse, with some elements unused (simply don't mention their row and column), and a single tile may have multiple tags (eg, to use the same graphic for multiple purposes in the game): just specify a list of comma-separated strings.
If a given tag appears multiple times in the spec files, the *last* such tag is used. (That is, in the order of files listed in the tilespec file, and order within each file.) This allows selected graphics to be "overridden" by listing a replacement spec file near the end of the 'files' list in the toplevel tilespec file, without having to modify earlier files in the list.
Tag prefixes
To help keep the tags organised, there is a rough prefix system used for standard tags:
| f. | national flags |
| r. | road/rail |
| s. | general small |
| u. | unit images |
| t. | basic terrain types (with _n0s0e0w0 to _n1s1e1w1) |
| ts. | terrain special resources |
| tx. | extra terrain-related |
| gov. | government types |
| unit. | unit overlays: hp, stack, activities (goto, fortify etc) |
| upkeep. | unit upkeep and unhappiness |
| city. | city related (city, size, sq.-prod., disorder, occupied) |
| cd. | city defaults |
| citizen. | citizens, including specialists |
| explode. | explosion graphics (nuke, units) |
| spaceship. | spaceship components |
| treaty. | treaty thumbs |
| user. | crosshairs (in general: user interface?) |
In general, graphics tags hard-wired into Freeciv must be provided by the spec files, or the client will refuse to start. Graphics tags provided by ruleset files (at least for the standard rulesets) should also be provided, but generally the client will continue even if they are not, though the results may not be satisfactory for the user. To work properly tags should correspond to appropriately sized graphics. (The basic size may vary, as specified in the top-level tilespec file, but the individual tiles should be consistent with those sizes and/or the usage of those graphics.)
Sprites
Depending on the information given here the tileset must/may contain certain sprites.
Theme Sprites
- citizen sprites
- This provides citizen graphics. Each citizen has one or more sprites which are shown in the city dialog. The types of citizen are happy, content, unhappy, and angry. The tag name is citizen.<type>_<n>. <type> is one of the listed types. <n> is the number of the graphic (numbered starting with 0, unlike most other graphics) which allows more than one sprite to be used. No more than 6 sprites per citizen may be used.
- Currently the citizen and specialist sprites may not have any transparency, as this is ignored in much of the drawing. This is considered a bug.
- specialist sprites
- These provide specialist graphics just like the citizen graphics. However specialist types come from the ruleset and may be changed in modpacks. The sprite name is specialist.<type>_<n>. Again <type> is the type of specialist (currently elvis, scientist, taxman) while <n> is the sprite number. See citizen sprites above.
- progress indicators
- There are three types of progress indicator. science_bulb indicates progress toward the current research target. warming_sun indicates progress toward global warming. cooling_flake indicates progress toward nuclear winter. Each indicator should have 8 states, numbered 0 (least) through 7 (most). The sprite names are s.<type>_<n>.
- government icons
- There should be one icon for each government. Its name is gov.<gov>, where <gov> is the government name. Government types come from governments.ruleset (currently anarchy, despotism, monarchy, communism, fundamentalism, republic, democracy).
- tax icons
- One icon for each tax type. These are used to show the tax rates. The sprites are s.tax_luxury, s.tax_science, s.tax_gold. Commonly the specialist sprites are reused for this.
- right arrow
- A sprite s.right_arrow is used on the panel when more units are present than can be shown.
Terrain sprites
- base sprite
- If the terrain has no match type or is layered, a base sprite is needed. This sprite has tag t.<terrain>1 (e.g., t.grassland1). More than one such sprite may be given (t.grassland2, etc.) in which case one will be chosen at random for each tile.
- matched sprites
- If the terrain has a match type or is layered, a set of matched sprites is needed. This consists of 16 sprites with tags t.<terrain>_n<V>e<V>s<V>w<V> (e.g., t.hills_n0e0s1w0. Each direcional value <V> is either 0 or 1. Note that the directions are in map coordinates, so n (north) in iso-view is northeast on the mapview. (Note this only applies for cell_type single.)
- cell sprites
- For matched terrains that have cell_type rect, 32 different sprites are needed. Each sprite is a rectangle corresponding to one cell, and there are 8 different sprites per cell. Each sprite has a name like t.ocean_cell_u110 where ocean is the terrain, u means up (north on the map) and 110 indicates which of the adjacent tiles are mismatched. For instance u110 means
/\ /B \ /\ 1/\ / A\/C \ \1 /\ 0/ \/D \/ \ / \/
- a matching terrain exists at C but not at A or B. In this case D is the current tile.
Examples
; This specifies a civ2-like grassland tile. A single sprite ; t.grassland is needed; it will be drawn blended. [terrain_grassland] is_blended = 1 num_layers = 1 layer0_match_type = 0 ; This specifies a civ1-like mountain tile. 16 sprites ; t.mountains_n0s0e0w0 ... t.mountains_n1s1e1w1 are needed. One of them ; will be drawn to match the adjacent tiles. Assuming only mountains ; has this match_type, adjacent mountains will match. [terrain_mountains] is_blended = 0 num_layers = 1 layer0_match_type = 7 ; This specifies a civ2-like hills tile. A base sprite t.hills will be ; needed, plus 16 matching sprites. The base sprite will be drawn, ; dithered with adjacent base sprites, and the matching sprite will be ; drawn on top. (In most civ2 tilesets the base sprite is the grassland ; sprite). [terrain_hills] is_blended = 1 num_layers = 2 layer0_match_type = 0 layer1_match_type = 8 ; This specifies a civ2-like ocean tile. Ocean is drawn via a cell-based ; system as explained above. [terrain_ocean] is_blended = 1 num_layers = 1 layer0_match_type = 6 layer0_cell_type = "rect"
Terrain Special Sprites
- farmland/irrigation
- tx.farmland and tx.irrigation provide the basic sprites for farmland and irrigation. Additionally, there is support for drawing continuous farmland and irrigation (as is used in Civ3). Here there are 16 irrigation sprites (and the same for farmland), starting with tx.s_irrigation_n0s0e0w0 and running through tx.s_irrigation_n1s1e1w1.
- An appropriate sprite will be chosen depending on which adjacent tiles also have farmland/irrigation. If any of these sprites are not present, the default sprite will be used as a fallback.
City Sprites
- Basic city sprites
- You may have up to 8 graphics for each city style. Each has a tag like "city.<style>_<size>" where <style> is the city style and <size> is the size. Each such sprite will be used for all cities of that style of size <size> or larger until the next such sprite is found. Current styles include "european", "classical", "industrial", "modern", "postmodern", "asian", and "tropical" (at the start of the game each nation chooses a city style; other styles become available when certain techs are reached). For example if you have a city.asian_1 and city.asian_8 then all cities of sizes 1-7 will use the first and cities of sizes 8 or more will use the second.
- Other city sprites
- Other city sprites are included as well, such as for city walls, etc. Documentation for these is needed.
Flag Sprites
- See nations.
See also
Template:UpdateNavbox