You can subscribe to this list here.
2005 |
Jan
|
Feb
(25) |
Mar
(84) |
Apr
(76) |
May
(25) |
Jun
(1) |
Jul
(28) |
Aug
(23) |
Sep
(50) |
Oct
(46) |
Nov
(65) |
Dec
(76) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(60) |
Feb
(33) |
Mar
(4) |
Apr
(17) |
May
(16) |
Jun
(18) |
Jul
(131) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
2007 |
Jan
(71) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
(40) |
Aug
(38) |
Sep
(7) |
Oct
(58) |
Nov
|
Dec
(10) |
2008 |
Jan
(17) |
Feb
(27) |
Mar
(12) |
Apr
(1) |
May
(50) |
Jun
(10) |
Jul
|
Aug
(15) |
Sep
(24) |
Oct
(64) |
Nov
(115) |
Dec
(47) |
2009 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(132) |
Dec
(93) |
2010 |
Jan
(266) |
Feb
(120) |
Mar
(168) |
Apr
(127) |
May
(83) |
Jun
(93) |
Jul
(77) |
Aug
(77) |
Sep
(86) |
Oct
(30) |
Nov
(4) |
Dec
(22) |
2011 |
Jan
(48) |
Feb
(81) |
Mar
(198) |
Apr
(174) |
May
(72) |
Jun
(101) |
Jul
(236) |
Aug
(144) |
Sep
(54) |
Oct
(132) |
Nov
(94) |
Dec
(111) |
2012 |
Jan
(135) |
Feb
(166) |
Mar
(86) |
Apr
(85) |
May
(137) |
Jun
(83) |
Jul
(54) |
Aug
(29) |
Sep
(49) |
Oct
(37) |
Nov
(8) |
Dec
(6) |
2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(14) |
May
(5) |
Jun
(15) |
Jul
|
Aug
(38) |
Sep
(44) |
Oct
(45) |
Nov
(40) |
Dec
(23) |
2014 |
Jan
(22) |
Feb
(63) |
Mar
(43) |
Apr
(60) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(57) |
Sep
(36) |
Oct
(2) |
Nov
(30) |
Dec
(27) |
2015 |
Jan
(5) |
Feb
(2) |
Mar
(14) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(63) |
Sep
(31) |
Oct
(26) |
Nov
(11) |
Dec
(6) |
2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
(1) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(20) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(4) |
2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Erik V. <eri...@xs...> - 2011-03-17 11:20:41
|
My remarks on train buying in Rails (see inclusion below) came hidden behind a post on a different topic, which is probably why these remarks has not drawn any attention. It's about how to incorporate complex features like double-sided train cards (like the 2/1G in 18VA) and trains that come with privates (18GA). I would add now: built-in trains, as some 1825 minors have. The new TrainCertificate objects would normally be hidden and created automatically from existing XML code like <Train name="2" majorStops="2" cost="80" amount="6" /> For double-sided trains I would propose something like (for 18VA): <TrainCertificate name="2/1G" cost="100" quantity="6"> <Train name="2" majorStops="2"/> <Train name="1G" majorStops="1"> <Score towns="yes"/> </Train> </TrainCertificate> Perhaps one or more additional attributes could to be added to denote Mine and CMD access and scoring details, but actually I think these details are so game-specific that these might as well be hardcoded. In any case, I leave that to Stefan Frey to decide and work out. In the above case, the price is in the <TrainCertificate> tag, but in 18Scan it will be in the <Train> tags because there the two trains on one card have different prices. (And I would replace the ambiguous 'amount' by the explicit 'quantity' throughout. Perhaps also 'cost' by 'price'?). I'm not yet sure how to incorporate the 18GA OSR special property (extra 2-train). It's not a SpecialProperty in the Rails sense of the word, as it's invocation isn't a separate user action; it happens automatically at some point, as a side effect of another action. Part of the new approach to train buying would be, that new Train objects are created when acquired by a company, not at the start of the game. That nicely fits with how the 18GA OSR SP works. The extra 2-train creation could be entirely hardcoded, or we could add a TrainCertificate to the <StartPacket><Item> or the <Company> tags. I'm looking for a solution that would also cover the built-in trains of some 1825 minors. I'm also not yet sure if this approach will keep old saved files backwards compatible, although that would be a goal. But at some point we'll have to bite the bullet. Ideas welcome. Otherwise I'll work it out by myself (later). Erik. > -----Oorspronkelijk bericht-----> Van: Erik Vos [mailto:eri...@xs...] > As an example, I've already concluded that my suggestion to Adam about the > 18GA OSR free 2-train is too simple and will not work that way. And there is > another looming problem with trains: the two-way train certificates as exist > in e.g. 18VA and 18Scan. My current thinking is that we need to separate > buyable trains from actual trains throughout. The former could be named > TrainCertificates. For example: an 18Scan 4/3+3-train certificate would then > be linked to two actual trains. At buying time, the player must decide which > train is actually bought, and that train is acquired by the company; the other > one is lost. Similarly in 18GA, a extra 2-train certificate would not normally be > buyable, but be linked to the OCR private. > Once this idea has been programmed, all usual cases would still be > configurable in the XML. For 18GA, extra Java programming will then be > required only to accomplish the automatic transfer of the train, either to the > company or to the scrapheap, at the time that the private is bought by a > company (even that could be made configurable, but I'm reluctant to add > code to the generic code base that's applicable to one game only). |
From: Chris S. <chr...@gm...> - 2011-03-16 05:05:11
|
Sounds like, in addition to the rest, an admin correction mode that allows adjusting the train roster would be a good idea. -- Chris Please consider the environment before printing this e-mail. On Tue, Mar 15, 2011 at 9:30 PM, John A. Tamplin <ja...@ja...> wrote: > On Wed, Mar 16, 2011 at 12:21 AM, Aliza Panitz <ali...@gm...>wrote: > >> In 1848 certain company actions trigger removing the cheapest >> permanent train, whether or not it is yet available for purchase. > > > Likewise 1834, and I believe there are others where the count of a certain > train available is reduced by mergers. > > -- > John A. Tamplin > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: John A. T. <ja...@ja...> - 2011-03-16 05:01:57
|
On Wed, Mar 16, 2011 at 12:21 AM, Aliza Panitz <ali...@gm...>wrote: > In 1848 certain company actions trigger removing the cheapest > permanent train, whether or not it is yet available for purchase. Likewise 1834, and I believe there are others where the count of a certain train available is reduced by mergers. -- John A. Tamplin |
From: Aliza P. <ali...@gm...> - 2011-03-16 04:21:47
|
In 1848 certain company actions trigger removing the cheapest permanent train, whether or not it is yet available for purchase. On Tue, Mar 15, 2011 at 10:30 AM, Chris Shaffer <chr...@gm...> wrote: > In 1880, trains are only removed if no train was purchased during the > current OR. It's fairly complicated though, as there is no discreet OR. > And the full rank of trains is removed - so if all companies in sequence > decline to buy a T3, then when the final company operates, all T3 are > removed, a SR occurs, and the game continues during the train buying phase > of the acting company. > I think for now, the generic case is "remove a train at the beginning of the > SR" and the others could be specific classes. > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Tue, Mar 15, 2011 at 9:59 AM, Justin Rebelo <jus...@gm...> > wrote: >> >> If this was to become a generic piece of code where the specific game >> implementation is defined by XML, then we should probably list off the >> likely needed variations on the functionality. Some I can think of >> are: >> >> In most cases, the removal is only triggered at the end of a set of >> ORs, there are exceptions to this, though (1880?). >> >> 1. The top train is removed regardless of any other criteria. >> >> 2. The top train is removed only if no company purchased a train this >> OR (1880? I could have the rule wrong) >> >> 3. The top train is removed only if it is the last train of its type >> (I could be wrong, but I think there's a game that does this). >> >> 4. Special company (Russian Govt) buys the train if it can afford it. >> I imagine this likely belongs in a game specific class. >> >> Chris, any other specific suggestions of implementations which could >> be made generic for covering most games that use such a mechanism? >> >> >> On Mon, Mar 14, 2011 at 6:59 AM, Chris Shaffer <chr...@gm...> >> wrote: >> > Many of the O&O games (e.g. 1844, 1880include an automatic train >> > discard, >> > and other designers (e.g. 1817) are copying the mechanic. I'd say it's >> > generic. >> > -- >> > Chris >> > >> > Please consider the environment before printing this e-mail. >> > >> > >> > On Mon, Mar 14, 2011 at 4:05 AM, Erik Vos <eri...@xs...> wrote: >> >> >> >> There doesn’t yet seem to be a Correction mode option to shuffle or >> >> discard trains, so your special company probably is the only available >> >> workaround at this stage. >> >> >> >> >> >> >> >> Implementing an automatic train discard action at some predefined point >> >> is >> >> pretty trivial in Java, the main question (again) is: should this be >> >> made >> >> configurable in XML, or can it better be hardcoded in some >> >> game-specific >> >> subclass? To decide such questions, we would need an inventory of >> >> which >> >> variations exists, and in which games these occur. >> >> >> >> >> >> >> >> Erik. >> >> >> >> >> >> >> >> >> >> >> >> Van: John A. Tamplin [mailto:ja...@ja...] >> >> Verzonden: zondag 13 maart 2011 14:19 >> >> Aan: Development list for Rails: an 18xx game >> >> Onderwerp: Re: [Rails-devel] Foreigners Buy Trains >> >> >> >> >> >> >> >> On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen <sc...@re...> >> >> wrote: >> >> >> >> Any ideas on how to implement the "foreigners buy a train at the end of >> >> the set of ORs" rules that some Double-O games use (at least >> >> 1824/1844)? I >> >> am doing a workaround for my prototype by putting a well-funded company >> >> that >> >> starts in the bottom left space of the stock market. That way it >> >> always >> >> runs last and is in the yellow zone so it doesn't count as a >> >> certificate for >> >> the President. Luckily, it is an infinite bank, so no issue with cash >> >> movements. It seems to work in the meantime until I finalize the >> >> design, >> >> but does anyone have a more elegant way of doing this? It would be >> >> worth >> >> implementing this mechanism at some point. I will probably work on >> >> 1824 as >> >> my next Rails project. >> >> >> >> For those that are not familiar, the "foreigners buy" rule is that at >> >> the >> >> end of a set of ORs, the top train on the stack is discarded from the >> >> game. >> >> This could trigger the start of a new phase. 18FR-RCE does something >> >> similar, but allows the foreigners to discard two trains if they are of >> >> different rank. Another variant on this is to have the foreigners buy >> >> a >> >> train after every OR rather than set--I'm still experimenting with >> >> that. >> >> >> >> >> >> >> >> I think it is going to require Java code to implement. When >> >> implementing, >> >> consider variations, such as 1861 where the Russian state railroad buys >> >> trains as it has cash available. >> >> >> >> >> >> >> >> -- >> >> John A. Tamplin >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Colocation vs. Managed Hosting >> >> A question and answer guide to determining the best fit >> >> for your organization - today and in the future. >> >> http://p.sf.net/sfu/internap-sfd2d >> >> _______________________________________________ >> >> Rails-devel mailing list >> >> Rai...@li... >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Colocation vs. Managed Hosting >> > A question and answer guide to determining the best fit >> > for your organization - today and in the future. >> > http://p.sf.net/sfu/internap-sfd2d >> > _______________________________________________ >> > Rails-devel mailing list >> > Rai...@li... >> > https://lists.sourceforge.net/lists/listinfo/rails-devel >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Erik V. <eri...@xs...> - 2011-03-15 22:34:27
|
OK, this was simple enough to do on the fly. Adding tag <RemoveTrainBeforeSR/> under <Component name="TrainManager" ... > will do it. The train removal is triggered in GameManager (which knows when rounds change), but the execution is in OperatingRound. I suppose the complex games where such features and its variants play a role will almost always have specialized GameManager and OperatingRound subclasses, so implementing any variants will not be a big deal. Erik. Van: Erik Vos [mailto:eri...@xs...] Verzonden: dinsdag 15 maart 2011 21:36 Aan: 'Development list for Rails: an 18xx game' Onderwerp: Re: [Rails-devel] Foreigners Buy Trains I agree. A condition is that at least one train must have been bought, so it doesn't apply to SR1. Erik. Van: Chris Shaffer [mailto:chr...@gm...] Verzonden: dinsdag 15 maart 2011 18:31 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Foreigners Buy Trains In 1880, trains are only removed if no train was purchased during the current OR. It's fairly complicated though, as there is no discreet OR. And the full rank of trains is removed - so if all companies in sequence decline to buy a T3, then when the final company operates, all T3 are removed, a SR occurs, and the game continues during the train buying phase of the acting company. I think for now, the generic case is "remove a train at the beginning of the SR" and the others could be specific classes. -- Chris Please consider the environment before printing this e-mail. On Tue, Mar 15, 2011 at 9:59 AM, Justin Rebelo <jus...@gm...> wrote: If this was to become a generic piece of code where the specific game implementation is defined by XML, then we should probably list off the likely needed variations on the functionality. Some I can think of are: In most cases, the removal is only triggered at the end of a set of ORs, there are exceptions to this, though (1880?). 1. The top train is removed regardless of any other criteria. 2. The top train is removed only if no company purchased a train this OR (1880? I could have the rule wrong) 3. The top train is removed only if it is the last train of its type (I could be wrong, but I think there's a game that does this). 4. Special company (Russian Govt) buys the train if it can afford it. I imagine this likely belongs in a game specific class. Chris, any other specific suggestions of implementations which could be made generic for covering most games that use such a mechanism? On Mon, Mar 14, 2011 at 6:59 AM, Chris Shaffer <chr...@gm...> wrote: > Many of the O&O games (e.g. 1844, 1880include an automatic train discard, > and other designers (e.g. 1817) are copying the mechanic. I'd say it's > generic. > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Mon, Mar 14, 2011 at 4:05 AM, Erik Vos <eri...@xs...> wrote: >> >> There doesn't yet seem to be a Correction mode option to shuffle or >> discard trains, so your special company probably is the only available >> workaround at this stage. >> >> >> >> Implementing an automatic train discard action at some predefined point is >> pretty trivial in Java, the main question (again) is: should this be made >> configurable in XML, or can it better be hardcoded in some game-specific >> subclass? To decide such questions, we would need an inventory of which >> variations exists, and in which games these occur. >> >> >> >> Erik. >> >> >> >> >> >> Van: John A. Tamplin [mailto:ja...@ja...] >> Verzonden: zondag 13 maart 2011 14:19 >> Aan: Development list for Rails: an 18xx game >> Onderwerp: Re: [Rails-devel] Foreigners Buy Trains >> >> >> >> On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen <sc...@re...> >> wrote: >> >> Any ideas on how to implement the "foreigners buy a train at the end of >> the set of ORs" rules that some Double-O games use (at least 1824/1844)? I >> am doing a workaround for my prototype by putting a well-funded company that >> starts in the bottom left space of the stock market. That way it always >> runs last and is in the yellow zone so it doesn't count as a certificate for >> the President. Luckily, it is an infinite bank, so no issue with cash >> movements. It seems to work in the meantime until I finalize the design, >> but does anyone have a more elegant way of doing this? It would be worth >> implementing this mechanism at some point. I will probably work on 1824 as >> my next Rails project. >> >> For those that are not familiar, the "foreigners buy" rule is that at the >> end of a set of ORs, the top train on the stack is discarded from the game. >> This could trigger the start of a new phase. 18FR-RCE does something >> similar, but allows the foreigners to discard two trains if they are of >> different rank. Another variant on this is to have the foreigners buy a >> train after every OR rather than set--I'm still experimenting with that. >> >> >> >> I think it is going to require Java code to implement. When implementing, >> consider variations, such as 1861 where the Russian state railroad buys >> trains as it has cash available. >> >> >> >> -- >> John A. Tamplin >> >> >> ---------------------------------------------------------------------------- -- >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > > ---------------------------------------------------------------------------- -- > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ---------------------------------------------------------------------------- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@xs...> - 2011-03-15 20:36:12
|
I agree. A condition is that at least one train must have been bought, so it doesn't apply to SR1. Erik. Van: Chris Shaffer [mailto:chr...@gm...] Verzonden: dinsdag 15 maart 2011 18:31 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Foreigners Buy Trains In 1880, trains are only removed if no train was purchased during the current OR. It's fairly complicated though, as there is no discreet OR. And the full rank of trains is removed - so if all companies in sequence decline to buy a T3, then when the final company operates, all T3 are removed, a SR occurs, and the game continues during the train buying phase of the acting company. I think for now, the generic case is "remove a train at the beginning of the SR" and the others could be specific classes. -- Chris Please consider the environment before printing this e-mail. On Tue, Mar 15, 2011 at 9:59 AM, Justin Rebelo <jus...@gm...> wrote: If this was to become a generic piece of code where the specific game implementation is defined by XML, then we should probably list off the likely needed variations on the functionality. Some I can think of are: In most cases, the removal is only triggered at the end of a set of ORs, there are exceptions to this, though (1880?). 1. The top train is removed regardless of any other criteria. 2. The top train is removed only if no company purchased a train this OR (1880? I could have the rule wrong) 3. The top train is removed only if it is the last train of its type (I could be wrong, but I think there's a game that does this). 4. Special company (Russian Govt) buys the train if it can afford it. I imagine this likely belongs in a game specific class. Chris, any other specific suggestions of implementations which could be made generic for covering most games that use such a mechanism? On Mon, Mar 14, 2011 at 6:59 AM, Chris Shaffer <chr...@gm...> wrote: > Many of the O&O games (e.g. 1844, 1880include an automatic train discard, > and other designers (e.g. 1817) are copying the mechanic. I'd say it's > generic. > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Mon, Mar 14, 2011 at 4:05 AM, Erik Vos <eri...@xs...> wrote: >> >> There doesn't yet seem to be a Correction mode option to shuffle or >> discard trains, so your special company probably is the only available >> workaround at this stage. >> >> >> >> Implementing an automatic train discard action at some predefined point is >> pretty trivial in Java, the main question (again) is: should this be made >> configurable in XML, or can it better be hardcoded in some game-specific >> subclass? To decide such questions, we would need an inventory of which >> variations exists, and in which games these occur. >> >> >> >> Erik. >> >> >> >> >> >> Van: John A. Tamplin [mailto:ja...@ja...] >> Verzonden: zondag 13 maart 2011 14:19 >> Aan: Development list for Rails: an 18xx game >> Onderwerp: Re: [Rails-devel] Foreigners Buy Trains >> >> >> >> On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen <sc...@re...> >> wrote: >> >> Any ideas on how to implement the "foreigners buy a train at the end of >> the set of ORs" rules that some Double-O games use (at least 1824/1844)? I >> am doing a workaround for my prototype by putting a well-funded company that >> starts in the bottom left space of the stock market. That way it always >> runs last and is in the yellow zone so it doesn't count as a certificate for >> the President. Luckily, it is an infinite bank, so no issue with cash >> movements. It seems to work in the meantime until I finalize the design, >> but does anyone have a more elegant way of doing this? It would be worth >> implementing this mechanism at some point. I will probably work on 1824 as >> my next Rails project. >> >> For those that are not familiar, the "foreigners buy" rule is that at the >> end of a set of ORs, the top train on the stack is discarded from the game. >> This could trigger the start of a new phase. 18FR-RCE does something >> similar, but allows the foreigners to discard two trains if they are of >> different rank. Another variant on this is to have the foreigners buy a >> train after every OR rather than set--I'm still experimenting with that. >> >> >> >> I think it is going to require Java code to implement. When implementing, >> consider variations, such as 1861 where the Russian state railroad buys >> trains as it has cash available. >> >> >> >> -- >> John A. Tamplin >> >> >> ---------------------------------------------------------------------------- -- >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > > ---------------------------------------------------------------------------- -- > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ---------------------------------------------------------------------------- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Chris S. <chr...@gm...> - 2011-03-15 17:31:05
|
In 1880, trains are only removed if no train was purchased during the current OR. It's fairly complicated though, as there is no discreet OR. And the full rank of trains is removed - so if all companies in sequence decline to buy a T3, then when the final company operates, all T3 are removed, a SR occurs, and the game continues during the train buying phase of the acting company. I think for now, the generic case is "remove a train at the beginning of the SR" and the others could be specific classes. -- Chris Please consider the environment before printing this e-mail. On Tue, Mar 15, 2011 at 9:59 AM, Justin Rebelo <jus...@gm...>wrote: > If this was to become a generic piece of code where the specific game > implementation is defined by XML, then we should probably list off the > likely needed variations on the functionality. Some I can think of > are: > > In most cases, the removal is only triggered at the end of a set of > ORs, there are exceptions to this, though (1880?). > > 1. The top train is removed regardless of any other criteria. > > 2. The top train is removed only if no company purchased a train this > OR (1880? I could have the rule wrong) > > 3. The top train is removed only if it is the last train of its type > (I could be wrong, but I think there's a game that does this). > > 4. Special company (Russian Govt) buys the train if it can afford it. > I imagine this likely belongs in a game specific class. > > Chris, any other specific suggestions of implementations which could > be made generic for covering most games that use such a mechanism? > > > On Mon, Mar 14, 2011 at 6:59 AM, Chris Shaffer <chr...@gm...> > wrote: > > Many of the O&O games (e.g. 1844, 1880include an automatic train discard, > > and other designers (e.g. 1817) are copying the mechanic. I'd say it's > > generic. > > -- > > Chris > > > > Please consider the environment before printing this e-mail. > > > > > > On Mon, Mar 14, 2011 at 4:05 AM, Erik Vos <eri...@xs...> wrote: > >> > >> There doesn’t yet seem to be a Correction mode option to shuffle or > >> discard trains, so your special company probably is the only available > >> workaround at this stage. > >> > >> > >> > >> Implementing an automatic train discard action at some predefined point > is > >> pretty trivial in Java, the main question (again) is: should this be > made > >> configurable in XML, or can it better be hardcoded in some game-specific > >> subclass? To decide such questions, we would need an inventory of which > >> variations exists, and in which games these occur. > >> > >> > >> > >> Erik. > >> > >> > >> > >> > >> > >> Van: John A. Tamplin [mailto:ja...@ja...] > >> Verzonden: zondag 13 maart 2011 14:19 > >> Aan: Development list for Rails: an 18xx game > >> Onderwerp: Re: [Rails-devel] Foreigners Buy Trains > >> > >> > >> > >> On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen <sc...@re...> > >> wrote: > >> > >> Any ideas on how to implement the "foreigners buy a train at the end of > >> the set of ORs" rules that some Double-O games use (at least > 1824/1844)? I > >> am doing a workaround for my prototype by putting a well-funded company > that > >> starts in the bottom left space of the stock market. That way it always > >> runs last and is in the yellow zone so it doesn't count as a certificate > for > >> the President. Luckily, it is an infinite bank, so no issue with cash > >> movements. It seems to work in the meantime until I finalize the > design, > >> but does anyone have a more elegant way of doing this? It would be > worth > >> implementing this mechanism at some point. I will probably work on 1824 > as > >> my next Rails project. > >> > >> For those that are not familiar, the "foreigners buy" rule is that at > the > >> end of a set of ORs, the top train on the stack is discarded from the > game. > >> This could trigger the start of a new phase. 18FR-RCE does something > >> similar, but allows the foreigners to discard two trains if they are of > >> different rank. Another variant on this is to have the foreigners buy a > >> train after every OR rather than set--I'm still experimenting with that. > >> > >> > >> > >> I think it is going to require Java code to implement. When > implementing, > >> consider variations, such as 1861 where the Russian state railroad buys > >> trains as it has cash available. > >> > >> > >> > >> -- > >> John A. Tamplin > >> > >> > >> > ------------------------------------------------------------------------------ > >> Colocation vs. Managed Hosting > >> A question and answer guide to determining the best fit > >> for your organization - today and in the future. > >> http://p.sf.net/sfu/internap-sfd2d > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > > > > > > > ------------------------------------------------------------------------------ > > Colocation vs. Managed Hosting > > A question and answer guide to determining the best fit > > for your organization - today and in the future. > > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Justin R. <jus...@gm...> - 2011-03-15 16:59:54
|
If this was to become a generic piece of code where the specific game implementation is defined by XML, then we should probably list off the likely needed variations on the functionality. Some I can think of are: In most cases, the removal is only triggered at the end of a set of ORs, there are exceptions to this, though (1880?). 1. The top train is removed regardless of any other criteria. 2. The top train is removed only if no company purchased a train this OR (1880? I could have the rule wrong) 3. The top train is removed only if it is the last train of its type (I could be wrong, but I think there's a game that does this). 4. Special company (Russian Govt) buys the train if it can afford it. I imagine this likely belongs in a game specific class. Chris, any other specific suggestions of implementations which could be made generic for covering most games that use such a mechanism? On Mon, Mar 14, 2011 at 6:59 AM, Chris Shaffer <chr...@gm...> wrote: > Many of the O&O games (e.g. 1844, 1880include an automatic train discard, > and other designers (e.g. 1817) are copying the mechanic. I'd say it's > generic. > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Mon, Mar 14, 2011 at 4:05 AM, Erik Vos <eri...@xs...> wrote: >> >> There doesn’t yet seem to be a Correction mode option to shuffle or >> discard trains, so your special company probably is the only available >> workaround at this stage. >> >> >> >> Implementing an automatic train discard action at some predefined point is >> pretty trivial in Java, the main question (again) is: should this be made >> configurable in XML, or can it better be hardcoded in some game-specific >> subclass? To decide such questions, we would need an inventory of which >> variations exists, and in which games these occur. >> >> >> >> Erik. >> >> >> >> >> >> Van: John A. Tamplin [mailto:ja...@ja...] >> Verzonden: zondag 13 maart 2011 14:19 >> Aan: Development list for Rails: an 18xx game >> Onderwerp: Re: [Rails-devel] Foreigners Buy Trains >> >> >> >> On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen <sc...@re...> >> wrote: >> >> Any ideas on how to implement the "foreigners buy a train at the end of >> the set of ORs" rules that some Double-O games use (at least 1824/1844)? I >> am doing a workaround for my prototype by putting a well-funded company that >> starts in the bottom left space of the stock market. That way it always >> runs last and is in the yellow zone so it doesn't count as a certificate for >> the President. Luckily, it is an infinite bank, so no issue with cash >> movements. It seems to work in the meantime until I finalize the design, >> but does anyone have a more elegant way of doing this? It would be worth >> implementing this mechanism at some point. I will probably work on 1824 as >> my next Rails project. >> >> For those that are not familiar, the "foreigners buy" rule is that at the >> end of a set of ORs, the top train on the stack is discarded from the game. >> This could trigger the start of a new phase. 18FR-RCE does something >> similar, but allows the foreigners to discard two trains if they are of >> different rank. Another variant on this is to have the foreigners buy a >> train after every OR rather than set--I'm still experimenting with that. >> >> >> >> I think it is going to require Java code to implement. When implementing, >> consider variations, such as 1861 where the Russian state railroad buys >> trains as it has cash available. >> >> >> >> -- >> John A. Tamplin >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: brett l. <bre...@gm...> - 2011-03-15 15:07:53
|
On Mon, Mar 14, 2011 at 11:31 PM, Bill Rosgen <ro...@gm...> wrote: > Hello, > > Is anyone working on implementing 1848? If not, I would like to start the process. I'm aware that this will require some Java code to enforce the special rules (which I'm prepared to attempt to write). As far as I'm aware, nobody is working on 1848. 18VA, 18GA, 1825, and 1856 have been the most recently talked about games. I think you're the first to mention 1848. > > Does anyone know Double-O objects to the implementation of their games in rails (if no one knows, I'll ask, but I'd hate to pester them if they have a well-known stance)? > We've had no direct contact with them that I'm aware of. It's certainly appreciated if we obtain their blessing, but that might be complicated by any contracts they already have. So far, we haven't been actively contacting game designers outside of the 18xx mailing list, but we do have a standing policy to remove game support if we receive any word from the designer or publisher that we've infringed. > Bill Rosgen ---Brett. |
From: Bill R. <ro...@gm...> - 2011-03-15 06:31:14
|
Hello, Is anyone working on implementing 1848? If not, I would like to start the process. I'm aware that this will require some Java code to enforce the special rules (which I'm prepared to attempt to write). Does anyone know Double-O objects to the implementation of their games in rails (if no one knows, I'll ask, but I'd hate to pester them if they have a well-known stance)? Bill Rosgen |
From: Erik V. <eri...@xs...> - 2011-03-14 21:30:55
|
OK, the 18VA map should be OK now apart from the handcrafted tiles. Indeed the code for displaying impassable hex sides was totally wrong for NS-oriented hex maps. It now works. The problems with not displaying home cities, and some tile-not-found errors in the log, were all caused by the game name still being "1830" in Game.xml. Because of that, some 1830 XML files were used. Erik. Van: Erik Vos [mailto:eri...@xs...] Verzonden: maandag 14 maart 2011 17:01 Aan: 'Development list for Rails: an 18xx game' Onderwerp: RE: [Rails-devel] 18VA Progress I have updated these files for the new tiles (TileDesigner versions) and added the off-map values to the map XML. The map shows up decently, except that - The impassable hex sides show up at wrong places - that must be a generic error, which I will try to debug. Not all impassable sides have been defined yet. - Indeed home cities are not shown; I'm not sure why. I'll have a look. On tiles 171/172: upgrades can be made hex-dependent, see 1851 or 1870 for examples. Erik. Van: Scott Petersen [mailto:sc...@re...] Verzonden: zondag 13 maart 2011 8:52 Aan: Development list for Rails: an 18xx game Onderwerp: [Rails-devel] 18VA Progress I have gotten as far as I'm going to in the near term for creating 18VA XML files and am passing on my current progress. 18VA has a rather simple version of the partial capitalization and 5-share to 10-share company conversion that Hecht uses in many of his games, so it is probably a good place to start. However, there are some chrome rules that might be tough to implement like double sided trains and somewhat complex bonuses depending on where the trains run. I have attached the following files: CompanyManager - Private companies are entered, but 18VA uses a different type of auction (bid until all players pass). - Private company special powers are not implemented. - Public companies are entered. - I noticed that the companies are not showing up in their home hexes--which may be because the Tiles.xml file is not complete (I used the one from 18EU, which is a superset of the 18VA tiles except 171/172). Game.xml Most of this should be correct, but I have not put much time into testing it. Stockmarket.xml Should be correct including available starting values. TileSet.xml Should all be correct including upgrades, but for some reason the tile quantities are mostly showing as zero available--again maybe something with using the 18EU Tiles.xml. I don't know how to implement the restriction on laying tiles 171 and 172 in the gray phase. One goes on Richmond, one goes on Washington. We could just leave that up to the players to do correctly. Map.xml See my previous email requesting new tiles. I have used the -800 tile as a placeholder for the red offboards and ports. The blocked hexsides are not working properly--I don't know why. Overall, a lot of it is there, but I guess until the map/tiles get fixed up, I can't do much more testing to verify the XML rules. I think the private companies can be ported over from other games with little trouble. Erik, could you generate a Tiles.xml for me? Here is text to add to the Gameslist.xml <Game name="18VA"> <Note>Not yet playable</Note> <Description>18VA - Steam, Steel and Stars: The Railroads Come to Virginia (c) 2001-2005 David G.D. Hecht Published 2005 by Deep Thought Games, LLC Not yet implemented: - 5-share companies, mechanism to convert to 10-share - Private auction - G-trains - CMDs - Two types of trains - Offboards should double value if company has a token there - Various bonuses for ports and CMDs </Description> <Players minimum="2" maximum="5"/> </Game> |
From: Erik V. <eri...@xs...> - 2011-03-14 16:00:48
|
I have updated these files for the new tiles (TileDesigner versions) and added the off-map values to the map XML. The map shows up decently, except that - The impassable hex sides show up at wrong places - that must be a generic error, which I will try to debug. Not all impassable sides have been defined yet. - Indeed home cities are not shown; I'm not sure why. I'll have a look. On tiles 171/172: upgrades can be made hex-dependent, see 1851 or 1870 for examples. Erik. Van: Scott Petersen [mailto:sc...@re...] Verzonden: zondag 13 maart 2011 8:52 Aan: Development list for Rails: an 18xx game Onderwerp: [Rails-devel] 18VA Progress I have gotten as far as I'm going to in the near term for creating 18VA XML files and am passing on my current progress. 18VA has a rather simple version of the partial capitalization and 5-share to 10-share company conversion that Hecht uses in many of his games, so it is probably a good place to start. However, there are some chrome rules that might be tough to implement like double sided trains and somewhat complex bonuses depending on where the trains run. I have attached the following files: CompanyManager - Private companies are entered, but 18VA uses a different type of auction (bid until all players pass). - Private company special powers are not implemented. - Public companies are entered. - I noticed that the companies are not showing up in their home hexes--which may be because the Tiles.xml file is not complete (I used the one from 18EU, which is a superset of the 18VA tiles except 171/172). Game.xml Most of this should be correct, but I have not put much time into testing it. Stockmarket.xml Should be correct including available starting values. TileSet.xml Should all be correct including upgrades, but for some reason the tile quantities are mostly showing as zero available--again maybe something with using the 18EU Tiles.xml. I don't know how to implement the restriction on laying tiles 171 and 172 in the gray phase. One goes on Richmond, one goes on Washington. We could just leave that up to the players to do correctly. Map.xml See my previous email requesting new tiles. I have used the -800 tile as a placeholder for the red offboards and ports. The blocked hexsides are not working properly--I don't know why. Overall, a lot of it is there, but I guess until the map/tiles get fixed up, I can't do much more testing to verify the XML rules. I think the private companies can be ported over from other games with little trouble. Erik, could you generate a Tiles.xml for me? Here is text to add to the Gameslist.xml <Game name="18VA"> <Note>Not yet playable</Note> <Description>18VA - Steam, Steel and Stars: The Railroads Come to Virginia (c) 2001-2005 David G.D. Hecht Published 2005 by Deep Thought Games, LLC Not yet implemented: - 5-share companies, mechanism to convert to 10-share - Private auction - G-trains - CMDs - Two types of trains - Offboards should double value if company has a token there - Various bonuses for ports and CMDs </Description> <Players minimum="2" maximum="5"/> </Game> |
From: Erik V. <eri...@xs...> - 2011-03-14 14:31:53
|
I have added TD versions of these new tiles to the repository, including their main purpose: a version of Tiles.xml that includes these tiles. If you want you could use the .svg versions of these tiles as a basis for your beautification work. I have chosen the following tile numbers: ax.svg: -1911/2/3 bx.svg: -1921/2/3 portx.svg: -4001/2/2 I'll now start looking at your 18VA XML, and will check if (after updating Map.xml and TileSet.xml, and generating Tiles.xml) anything shows up. Erik. Van: Erik Vos [mailto:eri...@xs...] Verzonden: maandag 14 maart 2011 11:54 Aan: 'Development list for Rails: an 18xx game' Onderwerp: RE: [Rails-devel] New Tiles Request Scott, See the attached screen shot fragment that shows how your single-port tile ends up in 18EU. Apparently it doesn't have the right size. Best advice I can give to create a new tile that can't be done with TileDesigner, is to start with an existing Rails tile (or create a close lookalike in TD), and then modify the SVG by hand or by some other program, taking care that the tile and image* sizes are not changed in any way. For such special tiles, an equivalent in TD must be made anyway, to form the basis for creating Tiles.xml. If you compare the TD version of tile -901, and the version that is actually displayed, you'll see that these are different. I can do the TD version for you. * The image is larger than the tile. That is a workaround for a TileDesigner bug, which cannot save a good tile image otherwise. Erik. Van: Scott Petersen [mailto:sc...@re...] Verzonden: zondag 13 maart 2011 8:22 Aan: Development list for Rails: an 18xx game Onderwerp: [Rails-devel] New Tiles Request In working through the XML files for 18VA and my prototype, I ran into the need for a few tiles (svgs are attached). * tile-911.svg: Single red offboard city with one full connection--this looks like the probable name, 912 and 913 already exist. * a1.svg-a3.svg: Single red offboard city with 1-3 triangular connections (18VA uses the one connection tile, but I'm sure the two connection one is used elsewhere, the three connection one is included for good measure, but not immediately needed). * b1.svg-b3.svg: Double red offboard city with 1-3 triangular connections (18VA uses the one and two connection tiles). * port1.svg-port3.svg: A different color (blue) off-map city. 18EU uses ports, but they always count as 10 value dot-towns, so the -800 tile is okay. 18VA has variable values for the ports so the -800 tile will not work. |
From: Rick W. <wes...@pu...> - 2011-03-14 14:03:34
|
----- Original Message ----- > I have no problem adding two-player variants, but it would be > preferable if > some consensus about the parameters could be achieved. Ah, my Eric's and my email crossed. I will write up the parameters later tonight and send them to the group. > If necessary, a comment about the status of such variants could be > added to > the game description and/or the <Players> tag. Yes indeed. -- Rick > Erik. > > > -----Oorspronkelijk bericht----- > > Van: Gmail [mailto:de...@gm...] > > Verzonden: maandag 14 maart 2011 14:09 > > Aan: Development list for Rails: an 18xx game > > CC: Development list for Rails: an 18xx game > > Onderwerp: Re: [Rails-devel] Unofficial game modifications > > > > I think we already have the 1889 2 player variant built in? I'm all > > for > keeping > > them in, most of these are just simple XML switches which are very > > easy to > > add and don't take away from the existing games. > > > > > > > > On 13 Mar 2011, at 21:31, Rick Westerman <wes...@pu...> > > wrote: > > > > > What should be done in regards to unofficial game modifications. > > > In > > particular I am wondering about modifications to allow 2-player > > play. My > > buddy John and myself have been having lots of fun lately doing > > 2-player > > 1889, 2-player 18AL, 2-player 1851, etc. But for the latter two I've > > had > to add > > a 2-player option in the XML files via extrapolating starting cash > > and > ending > > certificates. These modifications are "unofficial" since the > designer/publisher > > of the game did not create them nor have they been published anyway > > (as > > the 1830 Coalfields variant was). On the other hand I think that it > > would > be > > nice to keep the variants within the Rails eco-system. But the rest > > of you > > might not agree. Any opinions on this? > > > > > > > > > -- > > > Rick |
From: Rick W. <wes...@pu...> - 2011-03-14 14:01:44
|
----- Original Message ----- > I think we already have the 1889 2 player variant built in? Yes. But the 1889 rules (my gaming group owns a copy) explicitly has 2-player starting conditions. So the author/publisher of the game has supposedly play-tested the starting conditions and put an official "seal of approval" on them. What I am more concerned about are my own personal modifications to the Rails version of 18AL and 1851 in order to make them 2-player. These modifications have only be lightly tested and, not being official, may be subject to debate as to their utility. On the other hand, I hate the idea of have my own personal 'fork' of the rails project for my modifications. So is there a good way to handle this? I agree that the modifications are just "simple XML switches" that have no affect on the official rules so, technically, there are no problems with the modifications. The problem, if any, is more in the area of policy. > I'm all > for keeping them in, most of these are just simple XML switches which > are very easy to add and don't take away from the existing games. > > > > On 13 Mar 2011, at 21:31, Rick Westerman <wes...@pu...> wrote: > > > What should be done in regards to unofficial game modifications. > > In particular I am wondering about modifications to allow 2-player > > play. My buddy John and myself have been having lots of fun lately > > doing 2-player 1889, 2-player 18AL, 2-player 1851, etc. But for > > the latter two I've had to add a 2-player option in the XML files > > via extrapolating starting cash and ending certificates. These > > modifications are "unofficial" since the designer/publisher of the > > game did not create them nor have they been published anyway (as > > the 1830 Coalfields variant was). On the other hand I think that > > it would be nice to keep the variants within the Rails eco-system. > > But the rest of you might not agree. Any opinions on this? > > > > > > -- > > Rick > > > > ------------------------------------------------------------------------------ > > Colocation vs. Managed Hosting > > A question and answer guide to determining the best fit > > for your organization - today and in the future. > > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel -- Rick Westerman wes...@pu... Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building |
From: Chris S. <chr...@gm...> - 2011-03-14 14:00:15
|
Many of the O&O games (e.g. 1844, 1880include an automatic train discard, and other designers (e.g. 1817) are copying the mechanic. I'd say it's generic. -- Chris Please consider the environment before printing this e-mail. On Mon, Mar 14, 2011 at 4:05 AM, Erik Vos <eri...@xs...> wrote: > There doesn’t yet seem to be a Correction mode option to shuffle or discard > trains, so your special company probably is the only available workaround at > this stage. > > > > Implementing an automatic train discard action at some predefined point is > pretty trivial in Java, the main question (again) is: should this be made > configurable in XML, or can it better be hardcoded in some game-specific > subclass? To decide such questions, we would need an inventory of which > variations exists, and in which games these occur. > > > > Erik. > > > > > > *Van:* John A. Tamplin [mailto:ja...@ja...] > *Verzonden:* zondag 13 maart 2011 14:19 > *Aan:* Development list for Rails: an 18xx game > *Onderwerp:* Re: [Rails-devel] Foreigners Buy Trains > > > > On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen <sc...@re...> > wrote: > > Any ideas on how to implement the "foreigners buy a train at the end of the > set of ORs" rules that some Double-O games use (at least 1824/1844)? I am > doing a workaround for my prototype by putting a well-funded company that > starts in the bottom left space of the stock market. That way it always > runs last and is in the yellow zone so it doesn't count as a certificate for > the President. Luckily, it is an infinite bank, so no issue with cash > movements. It seems to work in the meantime until I finalize the design, > but does anyone have a more elegant way of doing this? It would be worth > implementing this mechanism at some point. I will probably work on 1824 as > my next Rails project. > > For those that are not familiar, the "foreigners buy" rule is that at the > end of a set of ORs, the top train on the stack is discarded from the game. > This could trigger the start of a new phase. 18FR-RCE does something > similar, but allows the foreigners to discard two trains if they are of > different rank. Another variant on this is to have the foreigners buy a > train after every OR rather than set--I'm still experimenting with that. > > > > I think it is going to require Java code to implement. When implementing, > consider variations, such as 1861 where the Russian state railroad buys > trains as it has cash available. > > > > -- > John A. Tamplin > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Erik V. <eri...@xs...> - 2011-03-14 13:59:40
|
I have no problem adding two-player variants, but it would be preferable if some consensus about the parameters could be achieved. If necessary, a comment about the status of such variants could be added to the game description and/or the <Players> tag. Erik. > -----Oorspronkelijk bericht----- > Van: Gmail [mailto:de...@gm...] > Verzonden: maandag 14 maart 2011 14:09 > Aan: Development list for Rails: an 18xx game > CC: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Unofficial game modifications > > I think we already have the 1889 2 player variant built in? I'm all for keeping > them in, most of these are just simple XML switches which are very easy to > add and don't take away from the existing games. > > > > On 13 Mar 2011, at 21:31, Rick Westerman <wes...@pu...> > wrote: > > > What should be done in regards to unofficial game modifications. In > particular I am wondering about modifications to allow 2-player play. My > buddy John and myself have been having lots of fun lately doing 2-player > 1889, 2-player 18AL, 2-player 1851, etc. But for the latter two I've had to add > a 2-player option in the XML files via extrapolating starting cash and ending > certificates. These modifications are "unofficial" since the designer/publisher > of the game did not create them nor have they been published anyway (as > the 1830 Coalfields variant was). On the other hand I think that it would be > nice to keep the variants within the Rails eco-system. But the rest of you > might not agree. Any opinions on this? > > > > > > -- > > Rick > > > > ---------------------------------------------------------------------- > > -------- > > Colocation vs. Managed Hosting > > A question and answer guide to determining the best fit for your > > organization - today and in the future. > > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ---------------------------------------------------------------------------- -- > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit for your > organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Gmail <de...@gm...> - 2011-03-14 13:09:41
|
I think we already have the 1889 2 player variant built in? I'm all for keeping them in, most of these are just simple XML switches which are very easy to add and don't take away from the existing games. On 13 Mar 2011, at 21:31, Rick Westerman <wes...@pu...> wrote: > What should be done in regards to unofficial game modifications. In particular I am wondering about modifications to allow 2-player play. My buddy John and myself have been having lots of fun lately doing 2-player 1889, 2-player 18AL, 2-player 1851, etc. But for the latter two I've had to add a 2-player option in the XML files via extrapolating starting cash and ending certificates. These modifications are "unofficial" since the designer/publisher of the game did not create them nor have they been published anyway (as the 1830 Coalfields variant was). On the other hand I think that it would be nice to keep the variants within the Rails eco-system. But the rest of you might not agree. Any opinions on this? > > > -- > Rick > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Erik V. <eri...@xs...> - 2011-03-14 11:06:05
|
There doesn’t yet seem to be a Correction mode option to shuffle or discard trains, so your special company probably is the only available workaround at this stage. Implementing an automatic train discard action at some predefined point is pretty trivial in Java, the main question (again) is: should this be made configurable in XML, or can it better be hardcoded in some game-specific subclass? To decide such questions, we would need an inventory of which variations exists, and in which games these occur. Erik. Van: John A. Tamplin [mailto:ja...@ja...] Verzonden: zondag 13 maart 2011 14:19 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Foreigners Buy Trains On Sun, Mar 13, 2011 at 4:28 AM, Scott Petersen < <mailto:sc...@re...> sc...@re...> wrote: Any ideas on how to implement the "foreigners buy a train at the end of the set of ORs" rules that some Double-O games use (at least 1824/1844)? I am doing a workaround for my prototype by putting a well-funded company that starts in the bottom left space of the stock market. That way it always runs last and is in the yellow zone so it doesn't count as a certificate for the President. Luckily, it is an infinite bank, so no issue with cash movements. It seems to work in the meantime until I finalize the design, but does anyone have a more elegant way of doing this? It would be worth implementing this mechanism at some point. I will probably work on 1824 as my next Rails project. For those that are not familiar, the "foreigners buy" rule is that at the end of a set of ORs, the top train on the stack is discarded from the game. This could trigger the start of a new phase. 18FR-RCE does something similar, but allows the foreigners to discard two trains if they are of different rank. Another variant on this is to have the foreigners buy a train after every OR rather than set--I'm still experimenting with that. I think it is going to require Java code to implement. When implementing, consider variations, such as 1861 where the Russian state railroad buys trains as it has cash available. -- John A. Tamplin |
From: Rick W. <wes...@pu...> - 2011-03-14 01:39:45
|
I just wrote an incomplete post and thought that started: > If I may offer yet another suggestion which may be only semantic in nature. Instead of having ow about a Please ignore that. I hit the send button by mistake. I am still thinking about my suggestion to see if it has any merits. -- Rick |
From: Rick W. <wes...@pu...> - 2011-03-14 01:37:45
|
----- Original Message ----- > Any rule variation to be implemented in Rails poses the same question: > is it worth while to make it configurable in XML, or is it so heavily > tied to just one game (or maybe two) that it can as well be hardcoded > in a game-specific class? If I may offer yet another suggestion which may be only semantic in nature. Instead of having ow about a > > See below for the status of the cases raised. > > Erik > > Van: John A. Tamplin [mailto:ja...@ja...] > Verzonden: zondag 13 maart 2011 19:28 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Variations on share price modification > after sales > > On Sun, Mar 13, 2011 at 4:17 AM, Scott Petersen <sc...@re...> > wrote: > Is there a way to implement these fairly common rules that about how > to modify share price after sales? > > 1. Current Market Value falls one space per "block" of shares sold. > > Is hardcoded in StockRound_1835. Which other games have this feature? > > 2. Current Market Value falls only when the President sells shares (no > effect if other shareholders sell). > Not yet. > > While considering this, consider other related issues: > * whether you can sell in the first SR > <NoSaleInFirstSR/> (e.g. 1835) > * may sell companies that haven't operated, as normal (1830) > Default. > * may sell companies that haven't operated, but receive the > destination share price rather than the starting one (as in 1844) > Not yet. > * may not sell companies that haven't operated (most DH games) > <NoSaleIfNotOperated/> (e.g. 1835) > -- > John A. Tamplin > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel -- Rick Westerman wes...@pu... Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building |
From: Rick W. <wes...@pu...> - 2011-03-14 01:32:03
|
What should be done in regards to unofficial game modifications. In particular I am wondering about modifications to allow 2-player play. My buddy John and myself have been having lots of fun lately doing 2-player 1889, 2-player 18AL, 2-player 1851, etc. But for the latter two I've had to add a 2-player option in the XML files via extrapolating starting cash and ending certificates. These modifications are "unofficial" since the designer/publisher of the game did not create them nor have they been published anyway (as the 1830 Coalfields variant was). On the other hand I think that it would be nice to keep the variants within the Rails eco-system. But the rest of you might not agree. Any opinions on this? -- Rick |
From: Rick W. <wes...@pu...> - 2011-03-14 01:02:32
|
> (much deleted, including my original idea) > Of course I agree that true client/server would be a lot more > efficient. But > if I were you, I wouldn't hold my breath waiting to see that > completed. > If fairly simple features like Reload and Autosave/load (my proposed > name of > the new feature) enable Rails users to achieve near-real time play, > I'm all > for it to implement these first. Thanks! I was sort of hoping that the features would be "easy" to implement. -- Rick |
From: John A. T. <ja...@ja...> - 2011-03-14 00:03:00
|
On Sat, Mar 12, 2011 at 4:02 PM, Aliza Panitz <ali...@gm...>wrote: > Rails 1.4.1, 1856, CGR running 3 Diesels. (This is not completely > absurd -- my plausible choices for the CGR in this game are 5,6; D,5; > and D,D,D. The money doesn't work out right for D,D. This is a very > odd game where the CGR formed with 4,5,6, and ten excellent tokens) > > At first, run calculations were taking 15-20 minutes on a T60 laptop > running Windows XP. Now, though, I've got a calculation that's been > running for well over an hour, taking 45-55% of my CPU the whole time. > The map isn't that much more developed! [added - it finally completed. > $1440 per 10% share.] > > Earlier, I was all ready to file a Rails bug because I could clearly > see a better route than what was displayed, but I stepped away from my > computer and when I came back, a better run was shown instead. So, > one simple request: when Rails is still calculating a run, there > should be a note on the screen saying something like "route > calculation in progress." (Screen shot attached. Even I can quickly > see that the light blue train should run towards the WGB tokens for an > extra $60 on the run, and in fact Rails eventually did $10 or $20 > better than that.) > > The next thing is that I'd like to know what was autocalculated versus > hand-entered. A note in the logfile saying what the calculated run > was would be very useful. (Yes, I could go back in the history and > look for myself, but that's not always feasible.) > > Finally, any interrupt between calculating a run and entering it > restarts the calculation -- even things like saving the file or > entering the destination of another company. Highly annoying, though > not quite a bug. > This is a known issue with the current brute-force algorithm -- it was brought up when it was being implemented. Basically, when the number of trains and stops goes up, the number of possible routes goes up exponentially. A long, long time ago, I implemented route calculation by transforming the problem to a flow graph and running the max-flow/min-cut algorithm on it (sorry, I no longer have this code), which avoids exponential time. However, I don't know how to adapt this to all the exotic rules that have been added since then -- there may not be any better approach than brute force to make sure no solutions are missed. Perhaps the best approach is to take advantage of multiple cores by sharding testing alternate routes into threads and count on hardware getting faster :). -- John A. Tamplin |
From: Erik V. <eri...@xs...> - 2011-03-13 22:57:06
|
Any rule variation to be implemented in Rails poses the same question: is it worth while to make it configurable in XML, or is it so heavily tied to just one game (or maybe two) that it can as well be hardcoded in a game-specific class? See below for the status of the cases raised. Erik Van: John A. Tamplin [mailto:ja...@ja...] Verzonden: zondag 13 maart 2011 19:28 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Variations on share price modification after sales On Sun, Mar 13, 2011 at 4:17 AM, Scott Petersen <sc...@re...> wrote: Is there a way to implement these fairly common rules that about how to modify share price after sales? 1. Current Market Value falls one space per "block" of shares sold. Is hardcoded in StockRound_1835. Which other games have this feature? 2. Current Market Value falls only when the President sells shares (no effect if other shareholders sell). Not yet. While considering this, consider other related issues: * whether you can sell in the first SR <NoSaleInFirstSR/> (e.g. 1835) * may sell companies that haven't operated, as normal (1830) Default. * may sell companies that haven't operated, but receive the destination share price rather than the starting one (as in 1844) Not yet. * may not sell companies that haven't operated (most DH games) <NoSaleIfNotOperated/> (e.g. 1835) -- John A. Tamplin |