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: Bill R. <ro...@gm...> - 2011-03-17 12:02:19
|
On 2011-03-17, at 19:20 , Erik Vos wrote: > 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'?). As the person working on 1848 (I'm more or less done the XML), I would very much appreciate the ability to define two-sided trains in XML, since 1848 has trains of the form N / N+ where one side is a standard N train, but the other (slightly more expensive) side allows calling at one extra gauge change marker. I agree with the notion that various special features (i.e. the fact that a + train in 1848 may make one extra stop at a gauge change marker) may as well be hardcoded into game-specific code. Bill |
From: Chris S. <chr...@gm...> - 2011-03-17 13:57:58
|
For built in trains, which also exist in the 18MEX minors, how about <BuyFromCompany="no"/>. -- Chris Please consider the environment before printing this e-mail. On Thu, Mar 17, 2011 at 4:20 AM, Erik Vos <eri...@xs...> wrote: > 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). > > > > > > ------------------------------------------------------------------------------ > 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-17 14:57:50
|
That's not valid XML, but I understand what you mean. You probably refer to the 18EU minor free 2-trains. An extra 'sellable="no"' attribute would fix such a train. An important difference is, however, that that the 1825 built-in trains are expensive and must be paid for before these trains can run. I suppose it will become a mix of XML and some special code in PublicCompany_1825. Erik. Van: Chris Shaffer [mailto:chr...@gm...] Verzonden: donderdag 17 maart 2011 14:58 Aan: Development list for Rails: an 18xx game Onderwerp: Re: [Rails-devel] Buying trains For built in trains, which also exist in the 18MEX minors, how about <BuyFromCompany="no"/>. -- Chris Please consider the environment before printing this e-mail. On Thu, Mar 17, 2011 at 4:20 AM, Erik Vos <eri...@xs...> wrote: 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). ---------------------------------------------------------------------------- -- 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 |