Menu
▾
▴
Re: [Rails-devel] Tile orientation display
|
From: Erik V. <eri...@xs...> - 2011-07-13 09:30:21
|
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 |
