Menu
▾
▴
Re: [Rails-devel] Tile orientation display
|
From: Stefan F. <ste...@we...> - 2011-07-14 05:35:55
|
Edward & Erik, sorry for the (irritating) mail: Erik guessed right, this was a copy from a more extended document about my thoughts to create the complete logic for tile laying and upgrading. This would prevent any illegal tile-lay and thus needs to consider the various upgrade rules (permissive, semi-restrictive and restrictive) and cope with all the little details the human mind can easily solve, but are difficult for an algorithm. This is not yet finished as I am not satisfied with neither the text nor the proposed design. And it would require a substantial rewrote of the UI, which I would delay until it is decided which client/server model and what kind of (mobile) devices Rails will support in the future. However what I proposed below is a (very simple) rule to create a natural orientation of each tile, which is only defined by the actual track configuration of the tile. This avoids arbitrary rules like the location of tile id, which result in different orientations of the same tile between different 18xx titles (or even inside one game as reported on the yahoo list). Another advantage is that allows someone to redraw/redesign the artwork of the tile and then the algorithm would still define the same base rotation. Other than this the rule makes my (yet unpublished) algorithm to choose the allowed upgrade rotations more efficient and is part of the problem to identify symmetric orientations (there are only 3 possible orientations for the straight line, not 6). But that part was impossible to understand without the context. Stefan On Wednesday, July 13, 2011 11:30:12 am Erik Vos wrote: > Thinking about it (I should do that more often :-), Stefan is probably > working on making the rotation logic route-aware (as in: "some new track > must be part of a valid route" and all its variations). The current code > isn't. > > Erik. > > > -----Original Message----- > > From: Erik Vos [mailto:eri...@xs...] > > Sent: Wednesday, July 13, 2011 10:02 AM > > To: 'Development list for Rails: an 18xx game' > > Subject: Re: [Rails-devel] Tile orientation display > > > > > -----Original Message----- > > > From: Edward S. Rustin [mailto:ed...@we...] > > > > > > Having read all that, I do have to wonder about one thing - what's the > > > problem you're trying to solve? > > > > That also was my first question. I can imagine that some clever algorithm > > would make it easier to determine the valid rotations of a laid tile. > > Currently that's pretty messy code of my making (see GUITile.rotate()), > > and > > > if Stefan sees ways to improve/simplify that, I'm all for it. > > > > Unfortunately, I don't yet see how Stefan's calculations would improve > > the situation, so I can't provide any more substantial commentary. > > > > The allowed rotations of tiles #64-68 (the tile #59 upgrades) were > > hardest > > to > > > get right, so that's a main test case. > > > > > 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). > > > > Another side point: as we currently use S/SW=0, wouldn't it be less > > confusing > > > to stick with that start point for side numbering? Or doesn't it make a > > difference? > > > > > 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.ht > > > > > m > > > > > > > ). 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 > > --------------------------------------------------------------------------- > - > > > -- > > > > > 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 > > --------------------------------------------------------------------------- > --- 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 |
