Menu
▾
▴
rails-devel
|
From: Erik V. <eri...@xs...> - 2011-07-12 17:57:26
|
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. |
|
From: John A. T. <ja...@ja...> - 2011-07-12 18:07:13
|
On Tue, Jul 12, 2011 at 1:57 PM, Erik Vos <eri...@xs...> 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? > Some games are not even consistent within that game (I don't remember which ones, but there was a discussion on the 18xx group many years ago) -- the same tile number can have the tile number in two different positions -- either KT or ST should be able to talk about it since they both run lots of PBeM games. However, that is hard to deal with anyway, since you have to know which one of the different ones was played. If you really want to support different orientations per game, I suggest simply having the per-game tile manifest will provide a rotation for the tile number only (or equivalently everything but the tile number), so it can be made to match the tiles supplied in the game. If the rotation isn't supplied, the game uses the orientation in the master tile database. -- John A. Tamplin |
|
From: Chris S. <chr...@gm...> - 2011-07-12 18:13:34
|
To be honest, as a player, I don't care. When I use CyberBoard and Rails, I don't bother specifying tile orientation in text. As long as there is a system that can be derived from the log, it's fine with me. -- Chris Please consider the environment before printing this e-mail. On Tue, Jul 12, 2011 at 10:57 AM, Erik Vos <eri...@xs...> 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 > |
|
From: Scott P. <sc...@re...> - 2011-07-12 18:18:07
|
On Tue, Jul 12, 2011 at 1:13 PM, Chris Shaffer <chr...@gm...>wrote: > To be honest, as a player, I don't care. When I use CyberBoard and Rails, > I don't bother specifying tile orientation in text. As long as there is a > system that can be derived from the log, it's fine with me. I agree with this. Since the entire game is contained within Rails, there is no strong need to have a uniform system. Also note that there are some games that have the tile number printed on a corner, not an edge. I believe DTG's 1826 and 1846 are like this. |
|
From: Phil D. <de...@gm...> - 2011-07-12 18:55:07
|
I'm with Scott and Chris, i find most orientation statements end up confusing someone and you need to clarify it in more verbose text so I'm not especially bothered if rails is internally consisten Phil On 12 Jul 2011, at 19:17, Scott Petersen <sc...@re...> wrote: > On Tue, Jul 12, 2011 at 1:13 PM, Chris Shaffer <chr...@gm...> wrote: > To be honest, as a player, I don't care. When I use CyberBoard and Rails, I don't bother specifying tile orientation in text. As long as there is a system that can be derived from the log, it's fine with me. > > I agree with this. Since the entire game is contained within Rails, there is no strong need to have a uniform system. > > Also note that there are some games that have the tile number printed on a corner, not an edge. I believe DTG's 1826 and 1846 are like this. > ------------------------------------------------------------------------------ > 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 |
|
From: brett l. <bre...@gm...> - 2011-07-12 18:37:32
|
If it's as easy as specifying the starting rotation in the XML, that shouldn't be too cumbersome and appears to be a usability win (for users mapping the physical game to the digital game). It sounds useful to me. :) ---Brett. On Tue, Jul 12, 2011 at 10:57 AM, Erik Vos <eri...@xs...> 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 > |
|
From: Erik V. <eri...@xs...> - 2011-07-13 15:59:30
|
To summarize: the developers think it's a good idea, but the "real users" (if I may say so) don't really see a need for it. So I suppose I will end up resting my case. Indeed implementation would be very easy. The hard work is in comparing all tiles of all games with the Rails standard and update the XML for any differences found. I would certainly not start doing that all on my own! The display options could be like (showing the result for the below example case): - Rails (default) #23/O10/SW - Game #23/O10/NE - Rails[Game] #23/O10/SW[NE] But, as said, if interest remains as low as it is, I'll drop it. Last call. Erik. > -----Original Message----- > From: brett lentz [mailto:bre...@gm...] > Sent: Tuesday, July 12, 2011 8:37 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Tile orientation display > > If it's as easy as specifying the starting rotation in the XML, that shouldn't be > too cumbersome and appears to be a usability win (for users mapping the > physical game to the digital game). > > It sounds useful to me. :) > > ---Brett. > > > > On Tue, Jul 12, 2011 at 10:57 AM, Erik Vos <eri...@xs...> 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 |
|
From: Stefan F. <ste...@we...> - 2011-07-13 05:53:27
|
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 |
|
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 > |
|
From: Erik V. <eri...@xs...> - 2011-07-13 08:02:00
|
> -----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 |
|
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 |
|
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 |
|
From: Erik V. <eri...@xs...> - 2011-07-14 09:09:38
|
Stefan, Thanks for the clarification (I didn't find it irritating, but missed the background). About the "natural" tile orientation: there has been a similar discussion in the [18xx] group a few months ago. See message #31521, where Scott pointed to John Tamplin's "canonical orientation" and Steve Thomas commented upon that. Could it be beneficial to align with that proposal? The trouble with any standard tile orientation that is different from the usual ones (with the number at S or SW), is that it is meaningless to anyone who has not internalized the algorithm to define it (and I would have trouble doing that). To fix that, we would need to change all tile rotations in TileDesigner to align with the new rule. That's not impossible, but a lot of work... I hope I'm still understanding you right... Erik. > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Thursday, July 14, 2011 7:38 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Tile orientation display > > 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 > > ---------------------------------------------------------------------------- -- > 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 |
|
From: Stefan F. <ste...@we...> - 2011-07-16 06:00:39
|
Erik: imho the canonical orientation intends to solve same issue, however it uses a different algorithm, thus there will be different orientations. And it seems that it does not orientate tile 25 (switch with two broad curves) uniquely: There are three configurations that have identical position of the exits: The switch can either be in position D, F or B, however exits are still always B, D and F. This problem arises for all tiles with symmetrical exits, but asymmetrical tracks. But maybe I have misunderstood something there (likely given the expertise of the discussants). For neither mine nor the canonical one the reference point is important and can be chosen. In any case the re-orientation will be done by programming code, not by editing all tiles with the TileDesigner ;-) I never intended to propose that. What a horrible idea ... The idea is to create an (base)orientation-attribute like you suggested previously, but not manually. Stefan The canonical orientation copied here for reference: >> As I went through tiles, I came up with new rules and simplified some >> others, so there is still much to be done to get the entire tile database >> consistent with these rules (orientations for flat-bottom tiles are A at >> the top, following clockwise from there -- flat-side tiles are rotated 30 >> degrees [ie, A is northeast and F is northwest]). >> >> 1) if a tile may only be played on a specific place on the map in a >> specific orientation, orient the tile so that up on the tile reflects up >> on the map. >> 2) one exit must be in the D position >> 3) if the exits can be arranged such that they are symmetrical across the >> vertical axis, it must be arranged so. >> 4) if the exits can be arranged to only be on A, B, C, and D, it must be >> arranged so. >> 5) prefer orientations that leave B empty over ones that leave C empty. On Thursday, July 14, 2011 11:09:23 am Erik Vos wrote: > Stefan, > > Thanks for the clarification (I didn't find it irritating, but missed the > background). > > About the "natural" tile orientation: there has been a similar discussion > in the [18xx] group a few months ago. See message #31521, where Scott > pointed to John Tamplin's "canonical orientation" and Steve Thomas > commented upon that. Could it be beneficial to align with that proposal? > > The trouble with any standard tile orientation that is different from the > usual ones (with the number at S or SW), is that it is meaningless to > anyone who has not internalized the algorithm to define it (and I would > have trouble doing that). To fix that, we would need to change all tile > rotations in TileDesigner to align with the new rule. That's not > impossible, but a lot of work... > > I hope I'm still understanding you right... > > Erik. > > > -----Original Message----- > > From: Stefan Frey [mailto:ste...@we...] > > Sent: Thursday, July 14, 2011 7:38 AM > > To: Development list for Rails: an 18xx game > > Subject: Re: [Rails-devel] Tile orientation display > > > > 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 > > --------------------------------------------------------------------------- > - -- > > > 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 |
|
From: Erik V. <eri...@xs...> - 2011-07-16 09:28:27
|
Thanks, Stefan, I now better understand what you're after. Sounds good. Erik. > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Saturday, July 16, 2011 8:03 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Tile orientation display > > Erik: > imho the canonical orientation intends to solve same issue, however it uses a > different algorithm, thus there will be different orientations. > > And it seems that it does not orientate tile 25 (switch with two broad curves) > uniquely: There are three configurations that have identical position of the > exits: The switch can either be in position D, F or B, however exits are still > always B, D and F. > This problem arises for all tiles with symmetrical exits, but asymmetrical > tracks. > But maybe I have misunderstood something there (likely given the expertise > of the discussants). > > For neither mine nor the canonical one the reference point is important and > can be chosen. > > In any case the re-orientation will be done by programming code, not by > editing all tiles with the TileDesigner ;-) I never intended to propose that. > What a horrible idea ... > > The idea is to create an (base)orientation-attribute like you suggested > previously, but not manually. > > Stefan > > > The canonical orientation copied here for reference: > > >> As I went through tiles, I came up with new rules and simplified some > >> others, so there is still much to be done to get the entire tile > >> database consistent with these rules (orientations for flat-bottom > >> tiles are A at the top, following clockwise from there -- flat-side > >> tiles are rotated 30 degrees [ie, A is northeast and F is northwest]). > >> > >> 1) if a tile may only be played on a specific place on the map in a > >> specific orientation, orient the tile so that up on the tile reflects > >> up on the map. > >> 2) one exit must be in the D position > >> 3) if the exits can be arranged such that they are symmetrical across > >> the vertical axis, it must be arranged so. > >> 4) if the exits can be arranged to only be on A, B, C, and D, it must > >> be arranged so. > >> 5) prefer orientations that leave B empty over ones that leave C empty. > > > > > > On Thursday, July 14, 2011 11:09:23 am Erik Vos wrote: > > Stefan, > > > > Thanks for the clarification (I didn't find it irritating, but missed > > the background). > > > > About the "natural" tile orientation: there has been a similar > > discussion in the [18xx] group a few months ago. See message #31521, > > where Scott pointed to John Tamplin's "canonical orientation" and > > Steve Thomas commented upon that. Could it be beneficial to align with > that proposal? > > > > The trouble with any standard tile orientation that is different from > > the usual ones (with the number at S or SW), is that it is meaningless > > to anyone who has not internalized the algorithm to define it (and I > > would have trouble doing that). To fix that, we would need to change > > all tile rotations in TileDesigner to align with the new rule. That's > > not impossible, but a lot of work... > > > > I hope I'm still understanding you right... > > > > Erik. > > > > > -----Original Message----- > > > From: Stefan Frey [mailto:ste...@we...] > > > Sent: Thursday, July 14, 2011 7:38 AM > > > To: Development list for Rails: an 18xx game > > > Subject: Re: [Rails-devel] Tile orientation display > > > > > > 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 > > > > ---------------------------------------------------------------------- > > ----- > > - -- > > > > > 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 |
|
From: John A. T. <ja...@ja...> - 2011-07-16 06:39:12
|
On Sat, Jul 16, 2011 at 2:02 AM, Stefan Frey <ste...@we...> wrote: > imho the canonical orientation intends to solve same issue, however it uses > a > different algorithm, thus there will be different orientations. > > And it seems that it does not orientate tile 25 (switch with two broad > curves) > uniquely: There are three configurations that have identical position of > the > exits: The switch can either be in position D, F or B, however exits are > still > always B, D and F. > This problem arises for all tiles with symmetrical exits, but asymmetrical > tracks. > But maybe I have misunderstood something there (likely given the expertise > of > the discussants). > The point of a canonical orientation is that there is only one (if there is more than one, such as for tile #9, then they are indistinguishable for all purposes). I'm not sure which canonical rules you are referring to, but in the one I proposed (and use) there is exactly one possible base orientation for #25, which is branches from D to B and F. You have other cases that have to be dealt with in the canonical rules, such as when there is internal connectivity, such as between multiple city clusters and external exits, but it is easy enough to extend the canonicalization rules to accomodate those. -- John A. Tamplin |
|
From: Stefan F. <ste...@we...> - 2011-07-17 06:41:41
|
> The point of a canonical orientation is that there is only one (if there is > more than one, such as for tile #9, then they are indistinguishable for all > purposes). I'm not sure which canonical rules you are referring to, but in > the one I proposed (and use) there is exactly one possible base orientation > for #25, which is branches from D to B and F. You have other cases that > have to be dealt with in the canonical rules, such as when there is internal > connectivity, such as between multiple city clusters and external exits, but > it is easy enough to extend the canonicalization rules to accomodate those. > John, thanks for the clarification. I referred to the definition from the 18xx yahoo message Erik pointed to (copied below). I now understand my mistake: The vertical axis of 3) runs perpendicular from the middle of side D to the middle of side A, instead of my understanding that it refers to the "diagonal" going from the corner between D/E to the corner A/B. But I am still wondering about the wording of 3) as it refers only to the symmetry of the exits, not of the track configuration. I checked the discussion thread again, and John David Galt came up with a good solution for that: 2.5) if the track on a tile is a "switch" (like a tree where one "trunk" splits into two or more "branches"), the D position is always the "trunk". If the tile has multiple "switches" on it, D must be one of the "trunks". Depending on the orientation (hex standing on the base D or balancing of the corner between D/E) "vertical axis" can vary. I used http://www.fwtwr.com/18xx/maps_tile_sheets/1830_ts1.htm to check the definition and got confused by that. Is there are another definition that describes the same configuration that is better suited for programming instead of having to check for symmetry against the vertical axis? My current proposal for an algorithm of the canonical orientation is the following: W can gladly ignore 1) as the orientation will be for a general database of tiles, not a game specific one (this is taken care somewhere else). On first glance it seems that assigning points (think binary if you like) to the exits or exit combinations ensures the rules. 2) Exit at D = 10000 2.5) Two tracks ending at D = 1000 3) Exits at A&D = 100 3) Exits at B&E = 100 3) Exits at C&F = 100 4+5) Exit at C= 11 4) Exit at A = 10 4) Exit at B = 10 The prefix x) refers to the rule covered by assigning points. Stefan John's Definition copied here: 1) if a tile may only be played on a specific place on the map in a specific orientation, orient the tile so that up on the tile reflects up on the map. 2) one exit must be in the D position 3) if the exits can be arranged such that they are symmetrical across the vertical axis, it must be arranged so. 4) if the exits can be arranged to only be on A, B, C, and D, it must be arranged so. 5) prefer orientations that leave B empty over ones that leave C empty. And JDG's definition again: 2.5) if the track on a tile is a "switch" (like a tree where one "trunk" splits into two or more "branches"), the D position is always the "trunk". If the tile has multiple "switches" on it, D must be one of the "trunks". |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X