Menu
▾
▴
RE: [Rails-devel] proposed structure for tile information
|
From: Erik V. <eri...@hc...> - 2005-10-14 14:03:47
|
John,
I'll try to look into this in more detail later.
For now I would like to add, that I have been adding some
additional preprinted tiles (for 1870 and 18AL) to the
Marco's TileDesigner database (and many more will follow).
Such tiles have negative numbers, and I have been trying
to extend Marco's numbers sensibly.
Perhaps we should start to standardize these numbers too?
Erik.
> -----Original Message-----
> From: rai...@li...
> [mailto:rai...@li...] On Behalf Of
> John A. Tamplin
> Sent: 11 October 2005 17:14
> To: rai...@li...
> Subject: [Rails-devel] proposed structure for tile information
>
> Hello -- I have developed my own software for generating
> print-ready tiles
> from the TileDesigner source and database, and I have been
> encouraged to
> contribute that code to rails. Here is an outline of my
> proposal, and if
> the developers agree that this is of interest I will port my
> current perl
> code to Java and submit it. Note that at present I am not
> committing to
> integrate it with the rest of the project or even implement the GUI
> interface, but at least it will get a common code base in
> place and be
> easy to extend to other renderers. Everything is vector
> based so it is
> scalable to any size or resolution. This message will contain the
> definition of what goes into a tile, and later messages will
> include the
> object factoring for the code to manipulate and draw tiles.
>
> Currently, my tile data is kept in an Informix database and
> is derived
> from the original TileDesigner database as well as PS18XX
> data. The tile
> data has been modified to get print-ready output and to allow layout
> tweaks at database import time rather than strictly when it
> is rendered,
> so manual changes can be made (especially needed for very
> crowded tiles)
> while simple tiles require little intervention.
>
> I propose to create an XML DTD for tile information that
> represents all
> information required for a tile, including everything
> required to draw the
> tile as well as any data necessary for gameplay. This is
> intended to be
> an interchange format rather than a storage format, although
> it could be
> used that way until a proper database is created. I know
> there is an XML
> format that is currently in place that does part of this, but
> it needs to
> include much more.
>
> Here is the current database schema for the tile database. Note that
> there is some derived data in here, such as connectivity
> information --
> the derived data is treated as a cache and would not be
> present in the
> exchange format, rather it would be generated on import. All
> positions
> are defined in polar coordinates -- (ang,dist) is the angle
> and distance
> from the center of the tile, with distance being scaled by
> the radius of
> the tile. So, (0,1) is the right-most point on a flat-bottom tile.
>
> tiles
> =====
> tile_id serial unique identifier
> tile_code char(16) code of tile, not necessarily unique
> tile_shape char(4) hex etc
> printed_number char(4) number actually printed on tile
> color varchar(20,6)
> label char(20) TileDesigner calls it category
> label_ang smallfloat Coordinates of label
> label_dist smallfloat
> label_rotate smallfloat rotation of label relative to tile
> label_font char(1) choice of which font to draw
> (limited set)
> label_justify char(2) justification of label
> long_name char(32) full descriptive name of tile
> origin varchar(32,0) original game using tile
> edge_conn integer bitmap of inter-edge connections
> d0-d4=AB-AF, d5-d9=BC-BA, ...
> relatively easy to rotate with tile
> junc_edge_conn integer bitmap of connections
> from junctions to edges
> d30-d31: two-bit type field
> 00: normal; d0-d5=J0/A - J0/F,
> d6=J1/A...
> 01: 6-way; always connected to nearest
> edge, d0-d4=J0/J1 - J0/J5, ...
> 1x: reserved
> interjunc_conn integer bitmap of connections
> between junctions
> d0-d4=J0/J1 - J0/J5, ...
>
> tile_junctions
> ==============
> tile_id integer foreign key into tiles
> junction_num smallint tile_id,junction_num is primary key
> junction_type char(4) type of junction, including
> number of tokens
> junction_ang smallfloat polar coordinates of junction
> junction_dist smallfloat
> junction_rotate smallfloat rotation of junction
> relative to tile
> null for whistlestops means draw it
> with a dot rather than a bar
> junction_revenue char(4) revenue (can mean other things for some
> junction types such as
> refueling junctions)
> revenue_ang smallfloat polar coordinates of revenue label
> revenue_dist smallfloat null means don't draw it
>
> tile_jun_annot (typically home tokens or reserved slots)
> ==============
> tile_id integer tile_id,junction_num
> foreign key to
> tile_junctions
> token_slot smallint index from 1 into token slots
> in junction
> annotation_id integer foreign key into annotations
>
> tile_connections
> ================
> tile_id integer foreign key into tiles
> pos1_ang smallfloat polar coordinates of 1st end
> pos1_dist smallfloat
> pos2_ang smallfloat polar coordinates of 2nd end
> pos2_dist smallfloat rules for canonical choice of
> 1st/2nd ends
> conn_type char(8) connection type (includes
> gauge, ferries,..)
> conn_level smallint drawing order for overlapped connections
> basic rule - if two connections meet at
> some point, their levels must
> be within 1.
> If they cross, their levels must be at
> least 2 apart.
> conn_radius smallfloat radius to draw connection.
> negative means
> it curves away from the center, positive
> curves toward the center of the tile. A
> typical 7 tile would be -.5, while #8
> would be -1.5. A 0 radius results in a
> straight line.
>
> tile_annotations
> ================
> tile_id integer foreign key into tiles
> tile_annot_num smallint tile_id,tile_annot_num
> is primary key
> annotation_id integer foreign key into annotations
> annot_ang smallfloat polar coordinations of annotation
> annot_dist smallfloat
> annot_scale smallfloat scale to draw annotation
> annot_rotate smallfloat orientation of annotation
> base_level boolean true if drawn as part of tile background
>
> annotations
> ===========
> annotation_id serial unique key
> annot_desc char(40) text description of annotation
> annot_text varchar(255) Postscript code to draw annotation
>
> tile_upgrades
> =============
> base_tile integer foreign key into tiles
> upgrade_tile integer foreign key into tiles
> base_tile,upgrade_tile is primary key
>
> game_tiles
> ==========
> game_id integer foreign key into games
> tile_id integer foreign key into tiles
> orientation smallint rotation relative to canonical
> orientation
> quantity smallint number of tiles present, 0 indicates it
> is a tile on the map, a negative number
> indicates the given number are supplied
> but are treated as infinite.
> tile_number char(4) number printed on tile in this game
> game_upgrades boolean use game-specific upgrades
> rather than std
> spec_upgrades boolean does game require special upgrade info
>
> The annotations table would likely need to be modified to
> include other
> ways of drawing the annotation, as well as gameplay
> interactions (ie, a
> river annotation needs to somehow include the fact that it
> costs money to
> build on that hex).
>
> So, a sample subset of an XML file for a couple of tiles:
>
> <tile id=27 code="7" origin="1829" color="yellow">
> <conn pos1="(330,.866025388)" pos2="(270,.866025388)"/>
> </tile>
> <tile id=32 code="14" origin="1829N" color="green">
> <junction type="2" revenue="30"/>
> <conn pos1="(270,.866025388)" pos2="(0,0)"/>
> <conn pos1="(90,.866025388)" pos2="(0,0)"/>
> <conn pos1="(30,.866025388)" pos2="(0,0)"/>
> <conn pos1="(330,.866025388)" pos2="(0,0)"/>
> </tile>
> <tile id=312 orientation="ew" code="1830-PRR" printed=""
> origin="1830"
> color="fixed" label="Philadephia" label_pos="(90,.3)"
> label_justify="c" label_font="A">
> <junction type="1" revenue="10">
> <annotation code="PRR_token">
> </junction>
> <conn pos1="(0,.866025388)" pos2="(0,0)"/>
> <conn pos1="(180,.866025388)" pos2="(0,0)"/>
> <conn pos1="(0,.866025388)" pos2="(330,.5)" radius=-.5/>
> <conn pos1="(330,.5)" pos2="(270,.5)" radius=.5/>
> <conn pos1="(180,.866025388)" pos2="(210,.5)" radius=-.5/>
> <conn pos1="(210,.5)" pos2=("270,.5)" radius=.5/>
> </tile>
>
> Note that many of the parameters are defaulted when the
> import code can
> figure them out easily. We might also make aliases for the edges for
> position codes to avoid the normal value of sqrt(3), such as
> sideA etc.
>
> Also note that the tile database includes tiles from all games, and
> additional tables define which tiles are present in which games, and
> game-specific modifications (such as orientation changes,
> text labels, or
> different upgrade paths). If no game-specific upgrades are
> provided, the
> subset of upgrade possibilities that are present in the game
> are used.
> Additional work needs to be done to have location-specific
> upgrades in
> particular games, such as those who take normal tiles in
> early stages of
> the game but have special brown or gray upgrades.
>
> The map object maintains a connectivity graph between junctions, and
> incrementally updates it when tiles are laid or upgraded. It
> provides an
> interface to the route calculation code to find the reachable
> subgraph of
> all junctions reachable from a given companies tokens (taking
> into account
> blocking by tokens and special game rules like 1860 allowing
> one blocked
> junction to be run through). This would also be used by the user
> interface code for playing tiles and tokens (with some
> additional work for
> tile placement since you have to look at tiles you can lay from the
> frontiers of the reachability graph). The route calculation
> code would be
> responsible for figuring out which of those are reachable by
> a particular
> train according to the game's rules and computing the optimal route.
>
> Next I will send the object breakdown for tile rendering.
>
> --
> John A. Tamplin ja...@ja...
> 770/436-5387 HOME 4116 Manson Ave
> Smyrna, GA 30082-3723
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
|
