Menu
▾
▴
Re: [Rails-devel] Tile orientation display
|
From: Edward S. R. <ed...@we...> - 2011-07-13 07:19:19
|
Having read all that, I do have to wonder about one thing - what's the problem you're trying to solve? It might just be my lack of knowledge about Rails (although I've been picking some up here and there from lurking on here and prodding the source), but I'm really not sure what the purpose of your algorithm is. Surely for any given 18xx game, there's a specified upgrade path where Tile X can be upgraded to Tile Y or Tile Z, and there's only going to be a few unique mappings based on orientation. As a side point, your algorithm might work better were you to enumerate the sides as 1, 2, 4, 8, 16, 32 (ie make it a six bit binary value) so that you avoid the problem of two different tiles having the same value (a tile with exits at 1, 2, 5 has the same value as one with exits at 1, 3, 4 for example). My two cents anyway, feel free to ignore if I've got no idea what I'm talking about! On Wed, Jul 13, 2011 at 06:55, Stefan Frey <ste...@we...> wrote: > Somehow related to the discussion and I would be happy to hear suggestions and > comments on that problem: > > After finishing the RevenueCalculation algorithms I started to design/outline > the workflow of an UpgradeTile algorithm. > > To make this efficient I intended to make the base rotation of all tiles such > that it allows the upgrades to fit with minimal rotations. > > What is the idea behind this? Take the example how Keith Thomasson built his > tile sheets for postal play. > > Check the tile sheet of: > http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm > It seems that in many cases those tiles are already orientated to allow for > easy upgrades: > > Define Facing 1 as the base rotation of an tile. Then it is the case for > example for an upgrade from tile 8 to tiles 19, 24, 29 the possible upgrade > will keep facings identical (thus no rotation of the upgraded tiles is > required). To upgrade to tile 16 and 25 one of the possible upgrades has > identical facings. > > So I came up with the idea if there is a solution that allows to define an > algorithm that defines a base rotations for all tiles such that upgrades can > be done with only a few rotations. > > At that time my idea was the following: > Id each hex side (for the example start with NW = 0, NE = 1, ... , > W = 5) > > A) Then sum up the id of all sides with at least one track leading to it. Call > that X. Compare each possible facing and choose that with minimal X as the > base rotation. > > It is easy to check that tiles 7, 8 and 9 are optimal rotated given in that > definition (and starting id=0 from NW). > > It is also the case for 16, 18, 19. However not for 20 (facing 2 has minimal > ids), and 23 (here facing 4), but again for 24. > > For tile 25 facing 1 and 3 have the same X. So a secondary criteria would be > helpful. Thus > > B) Sum up the ids of all tracks => Y > So given same X, then choose minimal Y as the base rotation. > > 25 has two tracks: Facing 1 has tracks from id=0 to id=2 and from id=0 to > id=4, thus Y = 6. Facing 3 has tracks from id=0 to id=2 and from id=2 to id=4 > thus Y=8. > > C) What about tiles with stations on it? If you have only one station which is > connected to all tracks you can easily rely on ranking by X: 57, 15, 53 have > optimal facings, for 14 facing 2 is minimal. > > If you have two stations the minimal rotation is always found by ranking with > X and Y as long as the stations have identical attributes and number of > tracks. > > However in other cases it can get more difficult and one still has to fall > back to some base rotation defined in the master database. > (One Example is tile 11 in > http://www.fwtwr.com/18xx/maps_tile_sheets/1825u123r123k1356_ts1.htm > ). Facing 1, 3 and 5 have same X and Y. > > Related to this is he issue of symmetry: For example tile 9 has a potential > facing 4 (which is the rotation by 180 degree, but as tile 9 has exactly a > symmetry there, this facing can ignored). So identity in X and Y is a > necessary condition for symmetry. For the 1830 tile set it is also a > sufficient condition (as far as I have checked, correct me if I am wrong) > > In general the identity of X and Y is not a sufficient condition for all > (existing) 18xx tiles (see example above) and if someone proposes an algorithm > that covers more cases than mine I would be very grateful. > > But for my case (an efficient algorithm) a necessary condition that is easy to > calculate is already very helpful as the more complex check is only needed for > those cases not eliminated by the simple one (similar to a hash code to test > equality). > > > On Tuesday, July 12, 2011 07:57:14 pm Erik Vos wrote: >> The currently ongoing discussion in the [18xx] group on how to describe >> tile lays is also of interest for Rails. I'm in particular referring to >> cases where the Rails (TileDesigner) tile orientation (i.e., the tile >> number placement) is different from the physical game. I just checked >> 1830 and 1856. The 1830 tile orientations are the same as in Rails (except >> tile #65), whereas with 1856 there are many differences. >> >> Take tile #23 as an example. The 1856 orientation of this tile is >> upside-down as compared with 1830 and Rails. Now assume tile #9 has been >> laid before on hex O10 (connecting SW-NE) and is upgraded to tile #23 >> (adding a connection NW-NE). Now the question is: how to display this >> upgrade in the map window and the game report? >> >> The Rails tile has the number as in 1830, on the SW side in this case, so >> the upgrade is now coded as #23/O10/SW. However, the physical tile would >> have its number on the NE side, so in an FTF game the upgrade would be >> denoted as #23/O10/NE. >> >> My question is: what do we prefer? >> >> I am thinking on adding an optional attribute to <Tile> in TileSet.xml that >> specifies the 'base rotation' of the physical tile as compared with the >> Rails tile (or vice versa). This 'base rotation' would then be added (or >> subtracted) to the internal value to calculate the displayed tile >> orientation. >> >> So, to make the laid tile in this example be described as #23/O10/NE we >> should add an attribute like 'baseRotation="3"'. >> >> Any need for this feature? Should it be an option? >> >> Erik. >> >> >> --------------------------------------------------------------------------- >> --- AppSumo Presents a FREE Video for the SourceForge Community by Eric >> Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets >> Revealed." This video shows you how to validate your ideas, optimize your >> ideas and identify your business strategy. >> http://p.sf.net/sfu/appsumosfdev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
