Menu
▾
▴
rails-devel
|
From: Frederick W. <fre...@go...> - 2009-12-22 10:19:05
|
Hi developers, I was wondering why this feature is prioritized so low. For me, this would be THE reason to use the computer instead of a physical board. Is it that you need a good algorithm before implementing this? In such a case, please consider the following: (1) Even though the brute force algorithm wouldn't be in O(n^p), it will probably be ok for non-diesel runs. (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge graph) for route calculation is updated whenever someone lays a tile. By doing this, you get a very low constant factor of the time the algorithm needs, meaning you'll still have exponential time but you won't perceive this until the size of the graph becomes very large. What do you think about that? Best Regards, Frederick |
|
From: Aliza P. <ali...@gm...> - 2009-12-22 22:12:19
|
This would be awesome, but so many 18xx variants have variations on the calculations: dedicated destination runs special trains like the Ghan in 1848 token ignores for special routes (1873) limited-use token ignores (1860) X-to-Y bonuses (18West, 18Ardennes, others) Off-board variation by train type (1889 has offboard values reserved for Diesel trains) Requirements for route intersections Owned vs. unowned bonus tokens (1870) ... and those are just the ones I know off the top of my head. I agree, though, that automatic route calculations, or at least suggestions, would be awesome. A GUI tool to help pick routes would be a lot more programming work, but would be more useful and flexible in the long run, I think. - Aliza On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld <fre...@go...> wrote: > Hi developers, > > I was wondering why this feature is prioritized so low. For me, this would > be THE reason to use the computer instead of a physical board. > > Is it that you need a good algorithm before implementing this? In such a > case, please consider the following: > (1) Even though the brute force algorithm wouldn't be in O(n^p), it will > probably be ok for non-diesel runs. > (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge > graph) for route calculation is updated whenever someone lays a tile. By > doing this, you get a very low constant factor of the time the algorithm > needs, meaning you'll still have exponential time but you won't perceive > this until the size of the graph becomes very large. > > What do you think about that? > > Best Regards, > Frederick > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Erik V. <eri...@xs...> - 2009-12-22 22:15:24
|
Hi Frederick. Opinions on what has most priority seem to vary. I agree that your suggestion (2) would probably the way to do it. We only have to find someone willing and able and having the time to implement this feature.... Erik. _____ From: Frederick Weld [mailto:fre...@go...] Sent: Tuesday 22 December 2009 11:19 To: rai...@li... Subject: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic routecalculation Hi developers, I was wondering why this feature is prioritized so low. For me, this would be THE reason to use the computer instead of a physical board. Is it that you need a good algorithm before implementing this? In such a case, please consider the following: (1) Even though the brute force algorithm wouldn't be in O(n^p), it will probably be ok for non-diesel runs. (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge graph) for route calculation is updated whenever someone lays a tile. By doing this, you get a very low constant factor of the time the algorithm needs, meaning you'll still have exponential time but you won't perceive this until the size of the graph becomes very large. What do you think about that? Best Regards, Frederick |
|
From: brett l. <wak...@gm...> - 2009-12-22 22:19:35
|
We agree with you that route calculation is important, but so are many other things that are far easier to implement. If you're volunteering to write the code, great. Just let us know when to expect your first set of patches. Let me know if you need any help checking out the code so that you can get started helping us add this feature. ---Brett. On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld <fre...@go...> wrote: > Hi developers, > > I was wondering why this feature is prioritized so low. For me, this would > be THE reason to use the computer instead of a physical board. > > Is it that you need a good algorithm before implementing this? In such a > case, please consider the following: > (1) Even though the brute force algorithm wouldn't be in O(n^p), it will > probably be ok for non-diesel runs. > (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge > graph) for route calculation is updated whenever someone lays a tile. By > doing this, you get a very low constant factor of the time the algorithm > needs, meaning you'll still have exponential time but you won't perceive > this until the size of the graph becomes very large. > > What do you think about that? > > Best Regards, > Frederick > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Jim B. <jim...@ya...> - 2009-12-22 22:42:11
|
Frederick- Best of luck with the new feature development- what an awesome way to join the rails team !!! ;-) More seriously, do note that legal tile/track placement would be a prerequisite feature for route calculation. In our user groups- using rails for pbem- this wouldn't take priority over any of the other stuff Erik and Brett have been working on. Adding up routes is a pain, but it's a well-understood pain, and it's actually straightforward to note the stuff for pbem (works way better than f2f for this). As Aliza mentioned, route bonuses & rules get complicated really quickly, across the 18xx- we avoid critical Rails bottlenecks getting this straight, if we just/simply continue typing in the earnings each turn. I'm not saying it wouldn't be a nice feature, but it sounds like it's been carefully evaluated by the developers (here and in the yahoo group) and would be a lot of work. - jim On Dec 22, 2009, at 2:19 PM, brett lentz wrote: > We agree with you that route calculation is important, but so are many > other things that are far easier to implement. > > If you're volunteering to write the code, great. Just let us know when > to expect your first set of patches. > > Let me know if you need any help checking out the code so that you can > get started helping us add this feature. > > ---Brett. > > > > On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld > <fre...@go...> wrote: >> Hi developers, >> >> I was wondering why this feature is prioritized so low. For me, this would >> be THE reason to use the computer instead of a physical board. >> >> Is it that you need a good algorithm before implementing this? In such a >> case, please consider the following: >> (1) Even though the brute force algorithm wouldn't be in O(n^p), it will >> probably be ok for non-diesel runs. >> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge >> graph) for route calculation is updated whenever someone lays a tile. By >> doing this, you get a very low constant factor of the time the algorithm >> needs, meaning you'll still have exponential time but you won't perceive >> this until the size of the graph becomes very large. >> >> What do you think about that? >> >> Best Regards, >> Frederick >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Aliza P. <ali...@gm...> - 2009-12-22 23:04:01
|
Another thing that varies by game -- the president/director/current plunderer of a railroad may or may not be required to use the optimal route. (Yes, there are situations where you would want $10 less of income.) This is often stated in the rules as "if any shareholder can point out a better route, the director is required to use it." Another possibility for tinkering would be games where there's a payment to an owner of a map feature. In 1844 there's an explicit rule that you can't run a suboptimal route just to get the virgin run through a tunnel/mountain. Perhaps the optimal path would be a route suggestion feature; ideally this would be something you could use (and not save!) even when it's not that railroad's turn, to help people parallel-process their turns. - Aliza On Tue, Dec 22, 2009 at 2:41 PM, Jim Black <jim...@ya...> wrote: > > Frederick- > > Best of luck with the new feature development- what an awesome way to join the rails team !!! ;-) > > More seriously, do note that legal tile/track placement would be a prerequisite feature for route calculation. > > In our user groups- using rails for pbem- this wouldn't take priority over any of the other stuff Erik and Brett have been working on. > > Adding up routes is a pain, but it's a well-understood pain, and it's actually straightforward to note the stuff for pbem (works way better than f2f for this). > > As Aliza mentioned, route bonuses & rules get complicated really quickly, across the 18xx- we avoid critical Rails bottlenecks getting this straight, if we just/simply continue typing in the earnings each turn. > > I'm not saying it wouldn't be a nice feature, but it sounds like it's been carefully evaluated by the developers (here and in the yahoo group) and would be a lot of work. > > - jim > > > On Dec 22, 2009, at 2:19 PM, brett lentz wrote: > >> We agree with you that route calculation is important, but so are many >> other things that are far easier to implement. >> >> If you're volunteering to write the code, great. Just let us know when >> to expect your first set of patches. >> >> Let me know if you need any help checking out the code so that you can >> get started helping us add this feature. >> >> ---Brett. >> >> >> >> On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld >> <fre...@go...> wrote: >>> Hi developers, >>> >>> I was wondering why this feature is prioritized so low. For me, this would >>> be THE reason to use the computer instead of a physical board. >>> >>> Is it that you need a good algorithm before implementing this? In such a >>> case, please consider the following: >>> (1) Even though the brute force algorithm wouldn't be in O(n^p), it will >>> probably be ok for non-diesel runs. >>> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge >>> graph) for route calculation is updated whenever someone lays a tile. By >>> doing this, you get a very low constant factor of the time the algorithm >>> needs, meaning you'll still have exponential time but you won't perceive >>> this until the size of the graph becomes very large. >>> >>> What do you think about that? >>> >>> Best Regards, >>> Frederick >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2009-12-23 09:31:06
|
do note that legal tile/track placement would be a prerequisite feature for route calculation. That's indeed where I would start (once I have found the time and courage - perhaps after my retirement 17 months from now :-) Erik. |
|
From: Chris S. <chr...@gm...> - 2009-12-22 22:40:46
|
Run calculation algorithms were discussed at length on the 18xx YahooGroup mailing list recently. It's not a simple problem, but you are correct that it is not insurmountable. That said, many people feel such as myself feel there are LOTS of reasons to use the computer instead of a physical board. In particular, it's fairly difficult to use a physical board when I'm playing a game with someone in in Chicago and another player in Ohio, considering that I live in Oregon. However, thanks to rails, I am now playing exactly that game by email. For play-by-email, Rails has many advantages over the traditional Vassal/CyberBoard/spreadsheet/human-moderator solutions. Rules enforcement, good text logging, automatic funds distribution, turn-order tracking... the list of benefits Rails provides goes on and on and on... As on any open source software project, the developers put their time where they feel the most interest or need. Clearly, the developers are focusing on adding new games, supporting pbem, and some usability enhancements at the moment. Since they are volunteers, we have an interest in them spending their time on things that interest them, otherwise they will burn out and depart. As was noted, more developers are welcome. I personally don't have the skill or time (though I might get it together to put together some xml files for a few new games) but I very much appreciate the work of those who do. -- Chris Please consider the environment before printing this e-mail. On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld < fre...@go...> wrote: > Hi developers, > > I was wondering why this feature is prioritized so low. For me, this would > be THE reason to use the computer instead of a physical board. > > Is it that you need a good algorithm before implementing this? In such a > case, please consider the following: > (1) Even though the brute force algorithm wouldn't be in O(n^p), it will > probably be ok for non-diesel runs. > (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge > graph) for route calculation is updated whenever someone lays a tile. By > doing this, you get a very low constant factor of the time the algorithm > needs, meaning you'll still have exponential time but you won't perceive > this until the size of the graph becomes very large. > > What do you think about that? > > Best Regards, > Frederick > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: John A. T. <ja...@ja...> - 2009-12-22 23:11:49
|
On Tue, Dec 22, 2009 at 5:18 AM, Frederick Weld < fre...@go...> wrote: > (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge > graph) for route calculation is updated whenever someone lays a tile. By > doing this, you get a very low constant factor of the time the algorithm > needs, meaning you'll still have exponential time but you won't perceive > this until the size of the graph becomes very large. > Also note that PC 1830 frequently computed incorrect routes. Building the connectivity graph isn't actually the time-consuming part (and as you say, is trivial to build incrementally). Also, building a route calculation engine that didn't have to work for multiple games would probably work ok, but when you start adding things like bonuses that depend on which stops you make, trains that can skip cities, etc, all the heuristic graph algorithms go out the window. -- John A. Tamplin |
|
From: Mark S. <mar...@gm...> - 2009-12-23 00:04:28
|
One item that I have not seen discussed about route calculation is that in the board game the director is forced to calculate the route. He may, with all the best intentions, seek to find the best route, but fails. And as has been stated, there are games where another "shareholder" (or simply any other player) MAY specify a better route. It is not a rule requirement that the best route MUST be found. The other players may choose to ignore to fact the route is not the best (or they fail to find a better route that is there). My point is that within 18xx I feel it is a very important part of the game to find your optimal route. And I would look forward to the ability to select the route manually, center-by-center, tile track-by-tile track, highlighting the route as you go. And on successive turns, the previous route would be highlited (saved for re-use) and allow for modifications if the director chooses... or if the route is comprimised (a token gets laid in the center blocking it from use for example), it requires a re-evaluation. There has been talk about implementing a "route-awareness" where it would enforce tile lays that a company can perform. I would see the capability to manually select the route (and the subsequent semi-auto summing up) as a next step towards true auto-route calculation. And for those that state "I really don't want to pick my own route!"... I reply, that once the full auto-route calculation is implemented (somewhere down the road), the option to manually select the route can be an option you can turn-on or off as your preference. Mark On Tue, Dec 22, 2009 at 5:48 PM, John A. Tamplin <ja...@ja...> wrote: > On Tue, Dec 22, 2009 at 5:18 AM, Frederick Weld < > fre...@go...> wrote: > >> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge >> graph) for route calculation is updated whenever someone lays a tile. By >> doing this, you get a very low constant factor of the time the algorithm >> needs, meaning you'll still have exponential time but you won't perceive >> this until the size of the graph becomes very large. >> > > Also note that PC 1830 frequently computed incorrect routes. > > Building the connectivity graph isn't actually the time-consuming part (and > as you say, is trivial to build incrementally). Also, building a route > calculation engine that didn't have to work for multiple games would > probably work ok, but when you start adding things like bonuses that depend > on which stops you make, trains that can skip cities, etc, all the heuristic > graph algorithms go out the window. > > -- > John A. Tamplin > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Jim B. <jim...@ya...> - 2009-12-23 00:43:02
|
On Dec 22, 2009, at 4:04 PM, Mark Smith wrote: > I would look forward to the ability to select the route manually, center-by-center, tile track-by-tile track, highlighting the route as you go. And on successive turns, the previous route would be highlited (saved for re-use) and allow for modifications if the director chooses... or if the route is comprimised (a token gets laid in the center blocking it from use for example), it requires a re-evaluation. > > There has been talk about implementing a "route-awareness" where it would enforce tile lays that a company can perform. I would see the capability to manually select the route (and the subsequent semi-auto summing up) as a next step towards true auto-route calculation. > > And for those that state "I really don't want to pick my own route!"... I reply, that once the full auto-route calculation is implemented (somewhere down the road), the option to manually select the route can be an option you can turn-on or off as your preference. I also think this would be an excellent way for rails to add route awareness- allow users to specify the route(s) manually, rails saves the result (and, perhaps, offers the resulting math/total for the earnings). Other players can now see the route(s) visually, too, which makes it easier for them to verify that it's all legal (right now we have to cross-reference hex coordinates, it's painstaking). That approach would be great, and require no "route finding" algorithms or even "legal track" awareness. The user would just tie the route together manually, as Mark suggests. - jim |
|
From: Aliza P. <ali...@gm...> - 2009-12-23 01:22:35
|
An added layer of weirdness: tiles are not monolithic. split city, hitting both sides allowed (1830, 1856, 18FR, 18Mex, etc.) split city, hitting both sides not allowed (1873) split city, values differ (18Mex, 1860) optional dits: 1860 free dits: 18Mex dits count: 1830, 1856, etc. N+M trains: lots I won't even get into hex trains, this-train-class-may-not-hit-this-city, blocking vs. non-blocking tokens, etc. (I'll also note that in general, 1860 is flat out weird; I would not hold my breath for any automated implementation.) I suspect a table of all the possible properties of 18xx trains would be quite voluminous. (... and now I want to design a game with half-revenue for soft-rusted trains...) - Aliza On Tue, Dec 22, 2009 at 4:25 PM, Jim Black <jim...@ya...> wrote: > > On Dec 22, 2009, at 4:04 PM, Mark Smith wrote: > >> I would look forward to the ability to select the route manually, center-by-center, tile track-by-tile track, highlighting the route as you go. And on successive turns, the previous route would be highlited (saved for re-use) and allow for modifications if the director chooses... or if the route is compromised (a token gets laid in the center blocking it from use for example), it requires a re-evaluation. >> >> There has been talk about implementing a "route-awareness" where it would enforce tile lays that a company can perform. I would see the capability to manually select the route (and the subsequent semi-auto summing up) as a next step towards true auto-route calculation. >> >> And for those that state "I really don't want to pick my own route!"... I reply, that once the full auto-route calculation is implemented (somewhere down the road), the option to manually select the route can be an option you can turn-on or off as your preference. > > I also think this would be an excellent way for rails to add route awareness- allow users to specify the route(s) manually, rails saves the result (and, perhaps, offers the resulting math/total for the earnings). > > Other players can now see the route(s) visually, too, which makes it easier for them to verify that it's all legal (right now we have to cross-reference hex coordinates, it's painstaking). > > That approach would be great, and require no "route finding" algorithms or even "legal track" awareness. The user would just tie the route together manually, as Mark suggests. > > - jim > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
×
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