1 ----------------------------------------------------------------------
2 Freeciv Graphics, and Tile Specification Files
3 ----------------------------------------------------------------------
8 To use different graphics with Freeciv, use the '--tiles' argument to
9 the Freeciv client. Eg, to use the 'engels' graphics, start the
12 freeciv-gtk3 --tiles engels
14 What Freeciv actually does in this case is look for a file called
15 'engels.tilespec' somewhere in your Freeciv data path. (See the file
16 INSTALL for some information on the Freeciv data path.) That tilespec
17 file contains information telling Freeciv which graphics files to use,
18 and what those graphics files contain.
20 That is all you need to know to use alternative graphics provided by
21 Freeciv or by third-party add-ons. The rest of this file describes
22 (though not fully) the contents of the tilespec file and related
23 files. This is intended as developer reference, and for people
24 wanting to create/compile alternative tilesets and modpacks for
27 ----------------------------------------------------------------------
31 The purpose of the 'tilespec' file and related 'spec' files is to
32 allow the detailed layout of the graphics within the files to be
33 flexible and not hard-coded into Freeciv, and to allow add-ons to
34 conveniently provide additional graphics.
36 There are two layers to the tilespec files:
38 The top-level file is named, eg: 'trident.tilespec'. The basename of
39 this file (here, 'trident') corresponds to the parameter of the
40 '--tiles' command-line argument for the Freeciv client, as described
43 The top-level tilespec file contains general information on the full
44 tileset, and a list of files which specify information about the
45 individual graphics files. These filenames must be located somewhere
46 in the data path, though not necessarily the same place as the
47 top-level tilespec file. Note that with this system the number and
48 contents of the referenced files are completely flexible at this
51 An exception is that the intro graphics must be in individual files,
52 as listed in the tilespec file, because Freeciv treats these
53 specially: these graphics are freed after the game starts, and
54 reloaded later as necessary.
56 ----------------------------------------------------------------------
60 All clients currently use 24/32 bit PNGs.
62 ----------------------------------------------------------------------
66 In the top-level tilespec file you can set options for the tileset.
67 Each of these should go within the [tilespec] section. Currently
70 Strings (enclosed in "")
71 ------------------------
72 options : A capability string, this should be "+Freeciv-a.b-tilespec", where
73 "a.b" it the current freeciv version.
74 name : the name of the tileset
75 type : general type of tileset, different types have
76 quite different format. Supported types are
77 "overhead" and "isometric"
78 city_names_font : an X font string
79 city_productions_font : an X font string
80 main_intro_file : GFX file for the intro graphics
81 minimap_intro_file : GFX file for the radar screen intro graphics
85 preferred_themes : List of preferred client themes to use with this
90 priority : when user does not specify tileset, client
91 automatically loads available compatible tileset
92 with highest priority.
93 normal_tile_width : the width of terrain tiles
94 normal_tile_height : the height of terrain tiles
95 unit_width : unit sprite width. Default is always ok, setting is
96 provided just for symmetry with unit_height
97 unit_height : unit sprite height if more than 1.5x terrain tile
98 height in isometric tileset
99 small_tile_width : the width of icon sprites
100 small_tile_height : the height of icon sprites
101 fog_style : Specifies how fog is drawn.
102 "Auto" : Code automatically adds fog.
103 "Sprite : A single fog sprite is drawn on top of all
104 other sprites for fogged tiles. The
105 tx.fog sprite is used for this.
106 "Darkness" : No fog, or fog from darkness_style = 4.
107 darkness_style : Specifies how "encroaching darkness" is drawn.
108 "None" : No darkness.
109 "IsoRect" : A single sprite can be split into 4
110 parts, each containing the darkness
111 for that particular cardinal direction.
113 "CardinalSingle" : Four different sprites exist, each
114 holding the darkness for a particular
115 direction. Any or all of the sprites
117 "CardinalFull" : The sprite is chosen based on the vector
118 sum of the darkness in all 4 cardinal
119 directions. 15 different sprites are
121 "Corner" : Corner darkness & fog, 81 sprites needed.
122 unit_flag_offset_x : Gives an offset from the tile origin at which to
123 unit_flag_offset_y draw flags behind units or cities. With isometric
124 city_flag_offset_x tilesets this should be non-zero so that the flag
125 city_flag_offset_y is placed correctly behind the unit/city.
126 occupied_offset_x : Gives an offset from the tile origin at which to
127 occupied_offset_y draw city occupied icon (in many tilesets placed above the flag)
128 unit_offset_x : Gives an offset from the tile origin at which to
129 unit_offset_y draw units.
130 activity_offset_x : Gives an offset from the tile origin at which to
131 activity_offset_y draw normal unit activity icons. "Auto" icons are not
132 affected by this as they are usually wanted in different
133 offset than real activity icons for both to appear simultaneously
134 unit_upkeep_offset_y : Gives an offset from the unit origin at which to draw
135 the upkeep icons when they are shown along the unit. The upkeep
136 icons can safely extend below the unit icon itself.
137 If this value is omitted, normal tile height is used instead;
138 - Upkeep icons appear below the unit icon if the unit icons are
139 equal to tile height (typical in overhead tileset)
140 - Upkeep icons overlay lower part of the unit icon, if unit icon
141 is higher than tile height (typical in iso tilesets)
142 unit_upkeep_small_offset_y:
143 Like unit_upkeep_offset_y, but to be used in case there's only small
144 space for the overall icon produced. Defaults to unit_upkeep_offset_y -
145 not having alternative layout.
146 citybar_offset_y : Gives an offset from city tile origin at which to
148 hex_side : When is_hex is specified (see is_hex, below), this
149 value gives the length of the "extra" side of the
150 hexagon. This extra side will be on the top/bottom
151 of the tile if is_isometric (below) is given, or
152 on the left/right of the tile otherwise. The actual
153 dimensions of the hex tile are determined from the
154 normal_tile_width/normal_tile_height of the tileset
155 as well as the hex side. The "normal" dimensions
156 give the X and Y offsets between adjacent tiles in
157 the tileset - this is not the same as the dimensions
158 of the tile itself. The dimension of the bounding
159 box of the hexagonal tile will be equal to the
160 "normal" dimension minus the hex_side. For instance
161 "normal" dimensions of 64x32 with a hex_side of 16
162 for an iso-hex tileset will give hexagons of size
164 city_names_font_size : Font size used in drawing city name
165 city_production_font_size : Font size used in drawing city production
167 Booleans (FALSE or TRUE)
168 ------------------------
169 is_hex : set to TRUE for a hexagonal tileset. If is_isometric
170 is also specified then you have an iso-hex tileset.
171 Hex tilesets should be used with topologies 8-11 and
172 iso-hex tilesets with topologies 12-15.
174 String lists (a comma-separated list of strings)
175 ------------------------------------------------
176 files : A list of .spec files to scan for sprites.
177 See "individual spec files", below.
180 ----------------------------------------------------------------------
184 The top-level tilespec file also contains information on how to draw each
185 terrain type. For each terrain type include a section "[tile_xxx]".
186 This section contains information on how to draw this terrain type.
187 (The terrain types are specified in the server ruleset file.)
191 tag : Tag of the terrain this drawing information refers
192 to. That must match the "graphic" or "graphic_alt"
193 field given in the ruleset file.x
194 blend_layer : If non-zero, given layer of this terrain will be
195 blended with adjacent terrains. Blending is done
196 civ2-style with a dither mask. Only iso-view
197 currently supports blending. Only the base graphic
199 The blending mask has sprite t.dither_tile.
200 is_reversed : Draw layers in reverse order.
201 num_layers : The number of layers in the terrain. This value
202 must be 1, 2 or 3. Each layer is drawn
203 separately. The layerN options below control the
204 drawing of each layer (N should be 0, 1 or 2)
205 layerN_is_tall : Left right corner of terrain sprites is not based
206 on normal_tile_width and normal_tile_height, but
207 to corner of the full tile.
208 layerN_offset_x : Offset for terrain sprites
210 layerN_match_type : If 0 or unset, no terrain matching will be done and
211 the base sprite will be drawn for the terrain. If
212 non-zero, then terrain matching will be done. A
213 matched sprite will be chosen that matches all
214 cardinally adjacent tiles whose terrain has the same
216 layerN_match_with : List of match_types to match against
217 layerN_sprite_type : With traditional tilesets each tile is drawn using
218 one sprite. This default sprite_type is "whole".
219 Which sprite to use may be specified using a
220 match_type, and there may be multiple layers
221 (each having one sprite). This method corresponds
222 to sprite_type "single".
223 A more sophisticated drawing method breaks the tile
224 up into 4 rectangles. Each rectangular cell is
225 adjacent to 3 different tiles. Each adjacency is
226 matched, giving 8 different sprites for each of the
227 4 cells. This sprite_type is "corner".
229 Additionally the top-level tilespec file should contain information about
230 the drawing of each layer. This is needed because the way each layer is
231 drawn must be consistent between different terrain types. You may not have
232 more than 3 layers (either in this section or in the [tile_XXX] sections).
236 match_types : Gives a string list of all different match types.
237 This list must include every possible match_type
238 used by terrains for this layer.
239 First letter of the match_type must be unique
245 Tilespec should define style of extra graphics for each extra type in
246 section [extras] like:
251 "road", "RoadAllSeparate"
252 "rail", "RoadAllSeparate"
254 "tx.irrigation", "Cardinals"
257 RoadAllSeparate : A single sprite is drawn for every connection the tile has;
258 only 8 sprites are needed.
259 RoadParityCombined : A single sprite is drawn for all cardinal connections and
260 a second sprite is drawn for all diagonal connections;
261 32 sprites are needed.
262 RoadAllCombined : One sprite is drawn to show roads in all directions.
263 There are thus 256 sprites (64 for a hex tileset).
264 River : Cardinal connections are drawn, as well as delta at the coast
265 Single1 : Single sprite at layer Special1
266 Single2 : Single sprite at layer Special2
267 3Layer : 3 Sprites, tagged <name>_bg, <name>_mg, and <name>_fg
268 Cardinals : Sprite for each cardinal connection
270 ----------------------------------------------------------------------
271 Individual spec files:
272 ----------------------
274 Each spec file describes one graphics file (PNG format is standard,
275 although some clients may accept other formats as well) as specified in
276 the spec file. The graphics file must be in the Freeciv data path, but
277 not necessarily in the same location as the spec file. Note you can have
278 multiple spec files using a single graphics file in different ways.
280 The main data described in the spec file is in sections named
281 [grid_*], where * is some arbitrary tag (but unique within each file).
282 A grid corresponds to a regular rectangular array of tiles. In
283 general one may have multiple grids in one file, but the default
284 tilesets usually only have one per file. (Multiple grids would be
285 useful to have different size tiles in the same file.) Each grid
286 defines an origin (top left) and spacing, both in terms of pixels, and
287 then refers to individual tiles of the grid by row and column. The
288 origin, and rows and columns, are counted as (0,0) = top left.
290 x_top_left : x-coordinate of the leftmost pixel of the leftomost cell
291 y_top_left : y-coordinate of the topmost pixel of the topmost cell
294 pixel_border : Number of pixels between cells, unless overridden by axis specific value
295 pixel_border_x : Number of pixels between cells in x-direction, overrides pixel_border
296 pixel_border_y : Number of pixels between cells in y-direction, overrides pixel_border
297 tiles : Table of tags, each line having "row", "column", and "tag"
300 x_top_left = 1 ; Border (in x=0) also in left side of the entire grid
301 y_top_left = 1 ; Border (in y=0) also in top side of the entire grid
305 tiles = { "row", "column", "tag"
313 Each individual tile is given a "tag", which is a string which is
314 referenced in the code and/or from ruleset files. A grid may be
315 sparse, with some elements unused (simply don't mention their row and
316 column), and a single tile may have multiple tags (eg, to use the same
317 graphic for multiple purposes in the game): just specify a list of
318 comma-separated strings.
320 If a given tag appears multiple times in the spec files, the *last*
321 such tag is used. (That is, in the order of files listed in the
322 tilespec file, and order within each file.) This allows selected
323 graphics to be "overridden" by listing a replacement spec file near
324 the end of the 'files' list in the top-level tilespec file, without
325 having to modify earlier files in the list.
327 ----------------------------------------------------------------------
331 To help keep the tags organised, there is a rough prefix system used
338 t. basic terrain types (with _n0s0e0w0 to _n1s1e1w1)
339 ts. terrain special resources
340 tx. extra terrain-related
341 gov. government types
342 unit. unit overlays: hp, stack, activities (goto, fortify etc)
343 upkeep. unit upkeep and unhappiness
344 city. city related (city, size, sq.-prod., disorder, occupied)
346 citizen. citizens, including specialists
347 explode. explosion graphics (nuke, units)
348 spaceship. spaceship components
349 treaty. treaty thumbs
350 user. crosshairs (in general: user interface?)
352 In general, graphics tags hard-wired into Freeciv _must_ be provided
353 by the spec files, or the client will refuse to start. Graphics tags
354 provided by ruleset files (at least for the "standard" rulesets)
355 should also be provided, but generally the client will continue even
356 if they are not, though the results may not be satisfactory for the
357 user. To work properly tags should correspond to appropriately sized
358 graphics. (The basic size may vary, as specified in the top-level
359 tilespec file, but the individual tiles should be consistent with
360 those sizes and/or the usage of those graphics.)
362 ----------------------------------------------------------------------
366 Depending on the information given here the tileset must/may contain certain
374 This provides citizen graphics. Each citizen has one or more sprites
375 which are shown in the city dialog. The types of citizen are "happy",
376 "content", "unhappy", and "angry". The tag name is "citizen.<type>_<n>".
377 <type> is one of the listed types. <n> is the number of the graphic
378 (numbered starting with 0, unlike most other graphics) which allows more
379 than one sprite to be used. No more than 6 sprites per citizen may be
382 Currently the citizen and specialist sprites may not have any
383 transparency, as this is ignored in much of the drawing. This is
388 These provide specialist graphics just like the citizen graphics. However
389 specialist types come from the ruleset and may be changed in modpacks.
390 The sprite name is "specialist.<type>_<n>". Again <type> is the
391 type of specialist (currently "elvis", "scientist", "taxman") while <n>
392 is the sprite number. See "citizen sprites" above.
396 There are three types of progress indicator. "science_bulb" indicates
397 progress toward the current research target. "warming_sun" indicates
398 progress toward global warming. "cooling_flake" indicates progress
399 toward nuclear winter. Each indicator should have 8 states, numbered
400 0 (least) through 7 (most). The sprite names are "s.<type>_<n>".
404 There should be one icon for each government. Its name is "gov.<gov>",
405 where <gov> is the government name. Government types come from
406 governments.ruleset (currently "anarchy", "despotism", "monarchy",
407 "communism", "fundamentalism", "republic", "democracy").
411 One icon for each tax type. These are used to show the tax rates. The
412 sprites are "s.tax_luxury", "s.tax_science", "s.tax_gold". Commonly
413 the specialist sprites are reused for this.
417 A sprite "s.right_arrow" is used on the panel when more units are
418 present than can be shown.
422 base sprite : If the terrain has no match type or is layered, a
423 base sprite is needed. This sprite has tag
424 "t.<terrain>1" (e.g., "t.grassland1"). More than
425 one such sprite may be given ("t.grassland2", etc.)
426 in which case one will be chosen at random for each
428 matched sprites : If the terrain has a match type or is layered, a
429 set of matched sprites is needed. This consists of
430 16 sprites with tags "t.<terrain>_n<V>e<V>s<V>w<V>"
431 (e.g., "t.hills_n0e0s1w0". Each direcional value
432 <V> is either 0 or 1. Note that the directions are
433 in map coordinates, so n (north) in iso-view is
434 northeast on the mapview. (Note this only applies
435 for cell_type "single".)
436 cell sprites : For matched terrains that have cell_type "rect",
437 32 different sprites are needed. Each sprite is
438 a rectangle corresponding to one cell, and there are
439 8 different sprites per cell. Each sprite has
440 a name like "t.ocean_cell_u110" where "ocean" is the
441 terrain, "u" means up (north on the map) and
442 110 indicates which of the adjacent tiles are
443 mismatched. For instance u110 means
454 a matching terrain exists at C but not at A or B. In
455 this case D is the current tile.
459 ; This specifies a civ2-like grassland tile. A single sprite
460 ; t.grassland is needed; it will be drawn blended.
464 layer0_match_type = 0
466 ; This specifies a civ1-like mountain tile. 16 sprites
467 ; t.mountains_n0s0e0w0 ... t.mountains_n1s1e1w1 are needed. One of them
468 ; will be drawn to match the adjacent tiles. Assuming only mountains
469 ; has this match_type, adjacent mountains will match.
473 layer0_match_type = 7
475 ; This specifies a civ2-like hills tile. A base sprite t.hills will be
476 ; needed, plus 16 matching sprites. The base sprite will be drawn,
477 ; dithered with adjacent base sprites, and the matching sprite will be
478 ; drawn on top. (In most civ2 tilesets the base sprite is the grassland
483 layer0_match_type = 0
484 layer1_match_type = 8
486 ; This specifies a civ2-like ocean tile. Ocean is drawn via a cell-based
487 ; system as explained above.
491 layer0_match_type = 6
492 layer0_cell_type = "rect"
494 Terrain Special Sprites
495 -----------------------
499 tx.farmland and tx.irrigation provide the basic sprites for farmland
500 and irrigation. Additionally, there is support for drawing continuous
501 farmland and irrigation (as is used in Civ3). Here there are 16
502 irrigation sprites (and the same for farmland), starting with
503 tx.irrigation_n0s0e0w0 and running through tx.irrigation_n1s1e1w1.
504 An appropriate sprite will be chosen depending on which adjacent tiles
505 also have farmland/irrigation. If any of these sprites are not present,
506 the default sprite will be used as a fallback.