-
Notifications
You must be signed in to change notification settings - Fork 22
Tile Creation
Revised July 2017 by Erik Vos
1 TileDesigner
2 Tile identifiers
3 Working with TileDesigner
3.1 Introduction
3.2 Directory structure
3.3 Designing tiles
3.4 Exporting images
3.4.1 Fixing images
3.5 'Handmade' images
3.5.1 Instructions for Inkscape
3.6 Publishing images
4 Creating XML tile descriptions
4.1 Exporting XML from TileDesigner
4.2 Making Tiles.xml
4.2.1 The overall Tiles.xml file
4.2.2 The per-game Tiles.xml file
5 Infrequently asked questions
To create the SVG images and the XML descriptions of 18xx tiles in Rails we use the program TileDesigner 1.3.1 by Marco Rocci (see http://www.rails18xx.it/software.html ). This program has not been maintained since 2004, and we do not have the source code, but currently this program is all we have to create tiles, and the quality of the images is very good, so we have chosen to live with its limitations and bugs.
Some of its limitations are:
- tile identifiers must be numeric;
- graphics like water and mountain symbols are not supported;
- the strangest omission is that pointy tracks, as occur on off-board hexes, are not supported;
- invisible connections, such as occur in some 1830 Reading variant cities, are not supported.
For this and other reasons, it is sometimes necessary to edit SVG tile descriptions manually, and/or to have two versions of the same tile: an "internal" version, to generate the XML connectivity description, and an "external" version, to create the SVG file being displayed.
The program comes with a tile database, originally containing 442 tiles, mostly tiles with IDs as defined in Blackwater Station's Tile Encyclopedia. It also contains the preprinted 1830 hexes as tiles with negative numbers. We have continued this approach when new tiles were added for other games, initially without much of a system, but in a later stage we have started to use a more systematic approach using large negative numbers for preprinted tiles. The total tile set now adds up to 559 tiles.
For the real (positive) tiles we follow the physical tile IDs where possible, adding 1000/2000/3000 in case of duplicate IDs (as did the original Tile Encyclopedia). The occasional alphanumeric ID has to be replaced by some number; there isn't yet a rule for that.
Since some time it is possible to display a different ("external") number than the (internal) tile ID to identify tiles textually in all Rails windows, and from the next release this external ID can be alphanumeric (see 1830 Coalfields, in progress). However, the tile images still display internal IDs only. I suppose the SVG tiles could be tweaked manually to show alphanumeric IDs well, but I haven't looked into that. (BTW the internal IDs are omitted on the preprinted tiles, TileDesigner has a seperate 'export' option for that).
Since Francis Tresham created the first 18xx game (1829), tiles have been identified by a number printed on one face side identification. To make a long story short, the numbering of tiles in the growing 18xx genre was not a linear affair. We can read and see the fruits of efforts by individuals in the Tile Encyclopedia on Blackwater Station.
Some consequences for the Rails projects are:
- No tile identifiers exist for preprinted tracks on the maps; for these "preprinted tiles" we follow Marco Rocci's approach by assiging negative numbers to such tiles, which, however, must not be displayed. (Note: even though in some we have a background graphic that includes such tracks, we still need a tile definition to describe connectivity in XML).
- The same identifier has sometimes been used for different tiles (in different games); here we follow the Tile Encyclopedia by adding a thousandfold (1000, 2000, 3000) to the numbers of later published tiles.
- Some tile identifiers have alphabetic characters, but TileDesigner only accepts numbers; to my knowledge this has not yes occurred in Rails games, but when it occurs, the best approach could be to assing unused 4-digit numbers of which the final digits correspond to the final digits on such tiles.
The approach to circumvent these limitations is, since the "Storm and Stress"-phase till today, not standardized in Rails. Mainly it was up to the volunteers to come to a solution day by day. Erik Vos wrote a nice summary that can be found on Excerpts#Excerpt_002
This section describes the setup and actions that are used by Erik Vos on his local Windows PC in creating tile images and XML. Not all of the mentioned files and scripts have been stored in the repository.
Most 18xx tiles for Rails are created with TileDesigner, a program written by Marco Rocci (see http://www.rails18xx.it/software.html ). This program has not been maintained for many years, and we don't have the source code. But this program is currently all we have to create tiles, and the quality of the images is very good, so we have chosen to live with its limitations and bugs.
TileDesigner is used to create both the tile images, and the XML files that describe each tile for the purpose of route and revenue calculation. Only the SVG image format is currently supported by Rails. It is possible to create SVG tile images in other ways (e.g. by editing existing SVG files in a text editor, or by Inkscape), but any new tile IDs created this way cannot be used as primary tile identifiers in the descriptive XML. See below for more details.
Not prescriptive, but for information only
My local directory structure, to which I will refer below, is shown here. Only files relevant to the tile creation process are mentioned. Only directories and files shown in bold are in the repository.
tiles
|
+----------------------+-------------+-----------------+----------------+
| | | | |
| svg TDwithID TDwoID handmade
TileDesigner.exe | | | |
TileDictionary.18t | +------+ +------+ |
TileDictionary.xml | | | | | |
Tiles.xml tile#.svg tile#.svg | tile#.svg | tile#.svg
CombineTiles.pl | |
FixInvisibility.pl TileDictionary TileDictionary
tileset.bat | |
tilexml.bat tile#.svg tile#.svg
TileDesigner is not very well documented; a few hints on Marco Rocci's site is all we have. In its first run, the program uses the Italian language. For those who don't master that language: English can be selected under Modifica | Opzioni (Edit | Options), select Inglese (English).
The user interface will not be described here. It has some quirks, but it is not too difficult to sort that out. (If necessary, details can be added here in a later stage.)
The order of tile numbers in the database (named TileDesigner.18t) is not sequential. The database contains Marco's original tile set followed by all tiles created for Rails in chronological sequence. To create a new tile, select the final tile id and press Ins. Then go ahead drawing junctions and tracks. It is essential that all track end points are either on a tile edge or on a junction (city, town), otherwise route calculation will fail.
To export SVG image files:
Select File | Export | Images. Select or enter the following details:
Folder: where you want to store the images.
(note: TD creates a subdirectory named TileDictionary below the directory
that is entered here and saves all image files in that subdirectory.)
Image format: SVG
Scale: 1
Tile size: 170
Tile elements:
ID: either checked or unchecked, see below.
Grid: unchecked
Frame: checked
File name template: tile<c0>
(note: this is essential, and deviates from the factory setting).
Leave all other options unchecked, except the Top checkboxes.
Finally press OK.
Preprinted tiles are exported to directory TDwoID. Uncheck the ID checkbox to ensure that the tile IDs are suppressed. Layable tiles are exported to directory TDwithID. Check the ID checkbox to ensure that the tile IDs are included. Export overwrites existing images in the TileDictionay subdirectories without warning.
For unknown reasons, TileDesigner includes 'xmlns=""', which makes the tiles invisible (note: this was not originally the case; I don't know what triggered it). To fix this, run the Perl script FixInvisibility.pl with the path to the relevant TileDictionary directory as a command-line argument. E.g.
perl FixInvisibility.pl TDwithID/TileDictionary
This script removes the xmlns attribute. A free Windows Perl implementation can be downloaded from http://www.activestate.com/activeperl.
Many special tiles cannot be created by TileDesigner, which pretty much is limited to creating the kind of tiles known shortly after 2000. Other tiles can be created in various ways:
- By editing an SVG file in a text editor (SVG is based upon XML).
- By creating a new tile, or editing an existing tile in Inkscape (the leading SVG editor). In this case, special instructions apply (see below).
Any tiles created or modified this way should be stored separately, to avoid being overwritten by a new export from TileDesigner. I am storing such tiles in the directory handmade.
If tiles are modified with Inkscape, before saving, set the following properties before saving the new image:
Under File | DocumentProperties:
First press 'Fit page to selection'. For edited images, this should change
the size to Width=393.00 and Height=341.00.
For unknown reasons, TileDesigner adds extra whitespace below the tile image.
To emulate this, change the Height to 357.50.
Then save the tile.
For newly created tiles, make sure that the size ends up identically, i.e. Width=393.00 and Height=357.00
Note: I remember having had problems with using tiles newly created by Inkspace. That is why modifying existing tiles is recommended.
To be included in the repository, the tile images must be copied to the svg directory. Usually I only copy new or changed tiles, first from TileDictionary to TDwithID/TDwoID (the contents of the latter serve as a backup up to that point). Then the relevant tiles from TDwithID (positive numbers), TDwoID (negative numbers and zero) and handmade are copied to svg.
A Perl script named CombineTiles.pl exists that can do this job, but using it is not recommeded, as it overwrites all images in svg, which can cause excessive updates to the repository. These days, I'm only (manually) copying new or changed tiles.
The file TileDictionary.xml contains all tile definitions in a TD-specific XML format. To export this file:
Select File | Export | XML.
Press OK.
For this export action, it does not matter what options are selected or entered; everything is ignored. In particular, the contents of the Folder field is entirely ignored. TileDesigner always exports XML to the directory where the executable TileDesigner.exe is located. For this reason, it is recommended to store the executable in the Tiles directory.
TileDictionary.xml is created as a one-line XML file. To properly format it, use the Perl script <tools_path>/formatxml.pl, or load the file in Eclipse and format it with XMLBuddy.
As explained elsewhere in this Wiki, Rails uses two types of files named Tiles.xml. The processes to create these files are explained below.
Warning: never modify Tiles.xml files manually; such modifications will mercilessly be overwritten when the processes described below are executed. All additional tile properties must find a place in either TileSet.xml or Map.xml, as best fits the needs.
The overall Tiles.xml file is located in the tiles directory. It is created by running Java class tools.ConvertTilesXML, which is included in the Rails repository. I use the following Windows script (named tilexml.bat):
java -Dconfigfile=<properties_path>.properties -cp <classes_path>\classes;<lib_path>\log4j-1.2.14.jar tools.ConvertTilesXML perl <tools_path>\formatxml.pl <tiles_path>\Tiles.xml pause
where the properties file includes the log4j configuration (I suppose this is not really necessary).
The Java program creates a one-line XML file. The Perl script formatxml.pl should properly format it. Alternatively, load it in Eclipse and format it with XMLBuddy.
Each game has its own subset of tile descriptions in a file that is also named Tiles.xml, but is located in data/. This type of file is created by running Java class tools.MakeGameTileSets, and uses the information in TileSet.xml (which must already exist) to create the per-game Tile.xml. The game name(s) must be provided as argument(s). I use the following Windows script, named tileset.bat:
java -cp <classes_path>\classes;<lib_path>\log4j-1.2.14.jar tools.MakeGameTileSets %1 %2 %3 %4 %5 %6 %7 %8 %9 for %%A in (%*) do ( perl <tools_path>\formatxml.pl <data_path>%%A\Tiles.xml ) pause
Again, the Java program creates one-line XML files. The Perl script formatxml.pl should properly format each file. Alternatively, load each Tiles.xml file in Eclipse and format it with XMLBuddy.
Why do we have separate TileSet.xml and Tiles.xml?
TileSet.xml contains the game-specific tile properties, and Tiles.xml has the game-independent tile properties. The latter file is generated by rails.util.MakeGameTileSets (a stand-alone Java class/program) from TileSet.xml and the overall Tiles.xml file that has all tiles (this file and several other files that I'm going to mention are in directory 18xx/tiles of the CVS repository on Sourceforge). This program also checks TileSet.xml against Map.xml for consistency.
Why do we have separate XMLand SVG files?
That is because we use an SVG renderer that understands SVG, whereas both I and the Java code I have written only understand XML. And I doubt if the twain will ever meet.
Where do Tiles.xml and the SVG files come from?
Ultimately everything comes from a tile database named TileDesigner.18t created by Marco Rocci's TileDesigner program (see http://www.rails18xx.it/software.html). In the mean time I have added a lot of tiles to Marco's original tile set. From that database I export both the SVG tiles and an XML descriptive file called TileDesigner.xml.
The SVG export is somewhat buggy. Originally Brett fixed that by a procedure that I don't have the details of. I have recently taken over and I'm now using a procedure described in the comments of a Perl script named CombineTiles.pl. That script builds the Rails SVG file set by combining parts from three sets of SVG files: - tiles with ID > 0 (layable tiles, the ID is printed on the tile). - tiles with ID <=0 (preprinted tiles, no ID on the tile; this is a separate export from TileDesigner) - special tiles that I have modified manually with Inkscape (such as the red off-board tiles -901 throught -903, which TileDesigner cannot create with "arrows". So for these tiles the XML does not exactly correspond with the SVG!).
The XML export (TileDesigner.xml) is converted by another Java program/class named rails.util.ConvertTiles into the overall Tiles.xml that I mentioned before. I'm doing this conversion because I think that the latter format is better suitable for use in Rails.
Why is this procedure so complex?
Well, we're doing the best we can with the limited knowledge and imperfect tools that we have.
Is there any routine to display all of the SVG files?
No. Only TileDesigner has everything.