Menu
▾
▴
rails-devel
|
From: Stefan F. <ste...@we...> - 2012-08-22 12:29:36
|
Another milestone is reached for Rails2.0: It is possible to start 1830 without an error. However no reasonable game play and some GUI glitches remain. However a playable version is on the horizon and I wonder if there are any volunteers you would be interested to play around with alpha versions and report their issues? If that is the case I would start releasing alpha versions on the Rails website in a few weeks time. How does the current Rails 2.0 roadmap looks like: A) Get 1830 working again B) Merge (or implement) all patches from the Rails1.x trunk since Rails2.0 left that branch C) (Help to) finish some of the nearly done 18xx versions (1825, 1826, 1880) D) Change the GameSave file format from Java Serialization to (zipped) XML E) Create a prototype for (real-time) online play F) Make sure that all other 18xx versions work again Adding C) and E) soon ensures that serious testing/usage of Rail2.0 will start soon. Stefan |
|
From: Oliver H. <oli...@gm...> - 2012-08-27 19:58:24
|
Hi there, I am interested in implementing a small variant of 1835. There are only small changes in the map, tiles and minor companies. If I understood the rails concept right, this should mainly be done by editing XML-files. As I have only very little experience in programming, this might be a good start for a contribution but I still need some help to start. You can find the description of 1835 Schlesien at bgg: http://boardgamegeek.com/boardgameexpansion/94856/1835-schlesien Cheers Oliver |
|
From: Erik V. <eri...@xs...> - 2012-08-28 08:21:32
|
Hi Oliver, You could inspect the 1830 XML files to see how to implement variants. If that doesn't help you out, I can assist or do (part of) the job. Does a document exist that fully describes the rule changes for this variant with respect to the standard version? For instance, how does the extra minor 4a convert to a Prussian share? The BGG page mentions two versions of this variant, is there any relevant difference between these two versions? Erik. > -----Original Message----- > From: Oliver Heck [mailto:oli...@gm...] > Sent: Monday, August 27, 2012 9:58 PM > To: rai...@li... > Subject: [Rails-devel] 1835 Schlesien > > Hi there, > > I am interested in implementing a small variant of 1835. There are only small > changes in the map, tiles and minor companies. If I understood the rails > concept right, this should mainly be done by editing XML-files. As I have only > very little experience in programming, this might be a good start for a > contribution but I still need some help to start. > > You can find the description of 1835 Schlesien at bgg: > http://boardgamegeek.com/boardgameexpansion/94856/1835-schlesien > > Cheers > Oliver > > ---------------------------------------------------------------------------- -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Oliver H. <oli...@gm...> - 2012-08-28 11:55:07
|
Erik, I am willing to work myself through the XMLs but where do I find them? Is there any documentation available? Cheers Oliver Am 28.08.2012 10:21, schrieb Erik Vos: > Hi Oliver, > > You could inspect the 1830 XML files to see how to implement variants. If > that doesn't help you out, I can assist or do (part of) the job. > > Does a document exist that fully describes the rule changes for this variant > with respect to the standard version? For instance, how does the extra minor > 4a convert to a Prussian share? > > The BGG page mentions two versions of this variant, is there any relevant > difference between these two versions? > > Erik. > |
|
From: Erik V. <eri...@xs...> - 2012-08-28 12:07:29
|
You can find all sources in the Sourceforge Rails project. You may need a Sourceforge account. The project has a wiki, but the info in there is very limited, and probably does not cover what you need to know. But learning by inspecting examples should work well. You'll need to know the basic XML formatting rules. Erik. > -----Original Message----- > From: Oliver Heck [mailto:oli...@gm...] > Sent: Tuesday, August 28, 2012 1:55 PM > To: rai...@li... > Subject: Re: [Rails-devel] 1835 Schlesien > > Erik, > > I am willing to work myself through the XMLs but where do I find them? > Is there any documentation available? > > Cheers > Oliver > > Am 28.08.2012 10:21, schrieb Erik Vos: > > Hi Oliver, > > > > You could inspect the 1830 XML files to see how to implement variants. > > If that doesn't help you out, I can assist or do (part of) the job. > > > > Does a document exist that fully describes the rule changes for this > > variant with respect to the standard version? For instance, how does > > the extra minor 4a convert to a Prussian share? > > > > The BGG page mentions two versions of this variant, is there any > > relevant difference between these two versions? > > > > Erik. > > > > > ---------------------------------------------------------------------------- -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Oliver H. <oli...@gm...> - 2012-08-28 12:15:38
|
Ok, I found some XML-files in the 1835 folder. Looks pretty straightforward. I have no idea how git works, though. I will edit these XMLs and come back as soon as I am finished or stuck. Oliver Am 28.08.2012 14:07, schrieb Erik Vos: > You can find all sources in the Sourceforge Rails project. You may need a > Sourceforge account. > The project has a wiki, but the info in there is very limited, and probably > does not cover what you need to know. > But learning by inspecting examples should work well. You'll need to know > the basic XML formatting rules. > > Erik. > > |
|
From: Erik V. <eri...@xs...> - 2012-08-28 12:21:12
|
In this stage using git is not essential. You can send me your updated files if you want. Erik. > -----Original Message----- > From: Oliver Heck [mailto:oli...@gm...] > Sent: Tuesday, August 28, 2012 2:15 PM > To: rai...@li... > Subject: Re: [Rails-devel] 1835 Schlesien > > Ok, I found some XML-files in the 1835 folder. Looks pretty straightforward. > > I have no idea how git works, though. I will edit these XMLs and come back as > soon as I am finished or stuck. > > Oliver > > Am 28.08.2012 14:07, schrieb Erik Vos: > > You can find all sources in the Sourceforge Rails project. You may > > need a Sourceforge account. > > The project has a wiki, but the info in there is very limited, and > > probably does not cover what you need to know. > > But learning by inspecting examples should work well. You'll need to > > know the basic XML formatting rules. > > > > Erik. > > > > > > > ---------------------------------------------------------------------------- -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Oliver H. <oli...@gm...> - 2012-08-28 12:24:17
|
Fine, I will do so. Am 28.08.2012 14:20, schrieb Erik Vos: > In this stage using git is not essential. You can send me your updated > files if you want. > Erik. > |
|
From: Oliver H. <oli...@gm...> - 2012-08-29 08:45:35
Attachments:
1835_Schlesien.zip
|
Erik, please find the updated XML files attached. I made changes to Game.xml, CompanyManager.xml, Map.xml and Tiles.xml. From the XMLs I was not sure if there are changes necessary to Berlin and Dortmund or to the TileSet. I added two 2-trains. Unfortunately I have no chance to test any of these changes but if you send me a compiled version I will be happy to do this. Cheers Oliver Am 28.08.2012 14:20, schrieb Erik Vos > In this stage using git is not essential. You can send me your updated > files if you want. > Erik. |
|
From: Erik V. <eri...@xs...> - 2012-08-29 10:04:13
|
Thanks, I'll look at it later today. > -----Original Message----- > From: Oliver Heck [mailto:oli...@gm...] > Sent: Wednesday, August 29, 2012 10:45 AM > To: rai...@li... > Subject: Re: [Rails-devel] 1835 Schlesien > > Erik, > > please find the updated XML files attached. > > I made changes to Game.xml, CompanyManager.xml, Map.xml and Tiles.xml. > From the XMLs I was not sure if there are changes necessary to Berlin and > Dortmund or to the TileSet. > > I added two 2-trains. > > Unfortunately I have no chance to test any of these changes but if you send > me a compiled version I will be happy to do this. > > Cheers > Oliver > > > Am 28.08.2012 14:20, schrieb Erik Vos > > In this stage using git is not essential. You can send me your > > updated files if you want. > > Erik. |
|
From: Erik V. <eri...@xs...> - 2012-08-29 20:00:17
Attachments:
1835_Schlesien_ev.zip
|
Oliver, It's not that simple. You'll have to keep all existing variants working as well. Not for nothing did I refer you to the 1830 examples. I have updated Game.xml and CompanyManager.xml as examples (see attached updated zip). I have added two named variants: Coalfields (the original version) and Schlesien (the updated one). Of course we could decide that only the latter is needed. If you compare my versions of these files with yours, you'll see how to make variant-specific exceptions to the standard setup. I'm leaving the rest to you. You'll also have to add tile -902 to TileSet.xml. Erik > -----Original Message----- > From: Oliver Heck [mailto:oli...@gm...] > Sent: Wednesday, August 29, 2012 10:45 AM > To: rai...@li... > Subject: Re: [Rails-devel] 1835 Schlesien > > Erik, > > please find the updated XML files attached. > > I made changes to Game.xml, CompanyManager.xml, Map.xml and Tiles.xml. > From the XMLs I was not sure if there are changes necessary to Berlin and > Dortmund or to the TileSet. > > I added two 2-trains. > > Unfortunately I have no chance to test any of these changes but if you send > me a compiled version I will be happy to do this. > > Cheers > Oliver > > > Am 28.08.2012 14:20, schrieb Erik Vos > > In this stage using git is not essential. You can send me your > > updated files if you want. > > Erik. |
|
From: Oliver H. <oli...@gm...> - 2012-08-29 20:04:53
|
Erik, Ok, I missed the point that this will not be new game but a variant of an existing one. I will have a look at it tomorrow. Cheers, Oliver Am 29.08.2012 22:00, schrieb Erik Vos: > Oliver, > > It's not that simple. You'll have to keep all existing variants working as > well. Not for nothing did I refer you to the 1830 examples. > > I have updated Game.xml and CompanyManager.xml as examples (see attached > updated zip). I have added two named variants: Coalfields (the original > version) and Schlesien (the updated one). Of course we could decide that > only the latter is needed. > > If you compare my versions of these files with yours, you'll see how to make > variant-specific exceptions to the standard setup. I'm leaving the rest to > you. You'll also have to add tile -902 to TileSet.xml. > > Erik > > |
|
From: Oliver H. <oli...@gm...> - 2012-08-29 20:24:14
|
> Ok, I missed the point that this will not be new game but a variant of > an existing one. By the way, wouldn't it be more useful to create a separate gametype? Otherwise you will not be able to combine the existing variants with the two map types. Oliver |
|
From: Erik V. <eri...@xs...> - 2012-08-29 21:39:06
|
> By the way, wouldn't it be more useful to create a separate gametype? > Otherwise you will not be able to combine the existing variants with the two > map types. I understood, that Coalfields/Schlesien was a variant of standard 1835. But if you want to be able to mix elements of different variants at will, we'll have to rethink what a "variant" is. In this specific case, one approach could be to configure the map type as a new game option, for instance: <GameOption name="MapVariant" values="Standard,Schlesien" default="Standard" /> A different approach could be to configure the start packet distribution scheme as a game option, for instance <GameOption name="InitialRoundType" values="Standard,Snake,Clemens" default="Standard" /> but in this case the behaviour is hardcoded, so we'll have to change some code (no big deal). Or we could do both. Perhaps that's the most flexible approach? Then we would no longer have the "Variant" option, at least for now. Thinking again, perhaps we still need "Variant" for Clemens, because there is a lot more to the Clemens variant than just the start packet distribution. IIRC, at least some of the Clemens specialties have not even been implemented yet. And there are a lot more 1835 variants that we haven't yet considered, and I fear that at least some of these would not mix well with the Coalfields/Schlesien map extension. This is no simple matter. In any case, I don't want to promote variants to separate games. That would create a maintenance nightmare. Comments from the group on this matter would be welcome. Erik. |
|
From: Stefan F. <ste...@we...> - 2012-08-30 05:53:07
|
A general comment from my side: My favorite solution for the issue is to have a two-layered structure: A) Fine-grained GameOptions (with defaults set to what the general consensus defines as the standard game) B) GameVariants defining changes in sets of the GameOptions There is no need for a GameVariant to define all GameOptions, only those for which it deviates from the standard. This would allow to combine GameVariants as long as they differ in the GameOptions they adjust. A generalization would allow to define a hierachy for GameVariants which would allow to resolve conflicting GameOptions or even ask for Player input how to resolve conflicts there. We could also allow to use GameVariant names as GameOptions names to indicate little changes which are not worth GameOptions of their own. So for 1835 one GameVariant would be "Clemens" which changes the GameOption "InitialAuction" (and potentially others) and another "Schlesien" which adjusts the GameOption "Map" and others required for 1835. The testing hell is already out of the box as soon as Rails allowed GameOptions. However most players will know that they get the most stable version if they keep GameOptions to the standard setting. However my proposal requires some serious recoding of the GameSetup engine and UI code, so it is better scheduled for Rails2.0. Stefan On 08/29/2012 11:38 PM, Erik Vos wrote: >> By the way, wouldn't it be more useful to create a separate gametype? >> Otherwise you will not be able to combine the existing variants with the > two >> map types. > > I understood, that Coalfields/Schlesien was a variant of standard 1835. But > if you want to be able to mix elements of different variants at will, we'll > have to rethink what a "variant" is. > > In this specific case, one approach could be to configure the map type as a > new game option, for instance: > <GameOption name="MapVariant" values="Standard,Schlesien" > default="Standard" /> > > A different approach could be to configure the start packet distribution > scheme as a game option, for instance > <GameOption name="InitialRoundType" values="Standard,Snake,Clemens" > default="Standard" /> > but in this case the behaviour is hardcoded, so we'll have to change some > code (no big deal). > > Or we could do both. Perhaps that's the most flexible approach? Then we > would no longer have the "Variant" option, at least for now. > > Thinking again, perhaps we still need "Variant" for Clemens, because there > is a lot more to the Clemens variant than just the start packet > distribution. IIRC, at least some of the Clemens specialties have not even > been implemented yet. And there are a lot more 1835 variants that we haven't > yet considered, and I fear that at least some of these would not mix well > with the Coalfields/Schlesien map extension. This is no simple matter. > > In any case, I don't want to promote variants to separate games. That would > create a maintenance nightmare. > > Comments from the group on this matter would be welcome. > > Erik. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Oliver H. <oli...@gm...> - 2012-08-30 06:51:28
|
Erik,
> because there
> is a lot more to the Clemens variant than just the start packet
> distribution. IIRC, at least some of the Clemens specialties have not even
> been implemented yet.
Clemens makes three changes to the original rules, which are all
implemented in rails:
* When buying a certificate from the Start Packet, there are no
restrictions on the order in which certificates may be purchased; a
player is free to choose any certificate remaining in the Start
Packet. Each player in turn may choose any of the remaining
certificates (some of which include an additional certificate, i.e.,
the Saxon director's share with the LD private) for purchase. (These
combined certificates may not be separated when purchasing from the
Start Packet.)
* The very first run of the first stock round is done backwards, all
others take place normally. E.g., in a game with four players the
first run is 4-3-2-1. Thereafter every run is 1-2-3-4. (Exactly once
player 1 has two turns in succession.)
* The Pre-Prussian minor companies will not operate until the Bavarian
(BY) floats. However, the private companies will pay out if the BY
does not float.
I do not see anybody playing the original rules any more, so I think
this variant is mandatory for Schlesien/Coalfield.
Oliver
|
|
From: Erik V. <eri...@xs...> - 2012-08-30 11:44:22
|
OK, you're right. The third option you mention is a separate game option that can be set or unset with any variant. It would be nice if we could set the default value to "on" automatically if Clemens is chosen, but the option selection code isn't yet that smart, I believe. The other two options only refer to the initial round, so we still have the option to make the initial round another separate game option. However, that may change in the future. IIRC several variants exist out there that would most likely be incompatible with the Schlesien extension, so I don't think it's a good idea to make that a completely independent game option (see also Mike Bourke's comments). On the other hand, I would find it overly restrictive to tie Schlesien to Clemens alone. I'm pretty sure that it wasn't intended that way by Harry Wu. As map changes seem more fundamental to me than the initial round sequence, I would propose to split off the latter to a new game option, see the "InitialRoundType" suggestion in my previous post. Two "variants" would then remain for now: Standard and Coalfields/Schlesien (probably the latter one only). For a good overview of (almost?) all proposed 1835 variations, see http://home.earthlink.net/~gamecorner/1835spac.html. Although it's unlikely that all of these will ever be implemented in Rails, we should be prepared to implement the more popular ones (and I don't know which ones are actually played these days). Further analysis would be required how that can be achieved in the best way. Some variants have a built-in different distribution mechanism that cannot mix with the currently implemented ones, and in that case we might have to hardcode restrictions on the latter. But that is for later study. Erik. From: Oliver Heck [mailto:oli...@gm...] Sent: Thursday, August 30, 2012 8:51 AM To: rai...@li... Subject: Re: [Rails-devel] 1835 Schlesien Erik, because there is a lot more to the Clemens variant than just the start packet distribution. IIRC, at least some of the Clemens specialties have not even been implemented yet. Clemens makes three changes to the original rules, which are all implemented in rails: * When buying a certificate from the Start Packet, there are no restrictions on the order in which certificates may be purchased; a player is free to choose any certificate remaining in the Start Packet. Each player in turn may choose any of the remaining certificates (some of which include an additional certificate, i.e., the Saxon director's share with the LD private) for purchase. (These combined certificates may not be separated when purchasing from the Start Packet.) * The very first run of the first stock round is done backwards, all others take place normally. E.g., in a game with four players the first run is 4-3-2-1. Thereafter every run is 1-2-3-4. (Exactly once player 1 has two turns in succession.) * The Pre-Prussian minor companies will not operate until the Bavarian (BY) floats. However, the private companies will pay out if the BY does not float. I do not see anybody playing the original rules any more, so I think this variant is mandatory for Schlesien/Coalfield. Oliver |
|
From: Oliver H. <oli...@gm...> - 2012-08-30 13:01:38
|
I am fine to go forward in whatever direction you decide to. :-) Thank you for that link, it's highly appreciated! In the meantime I installed Eclipse but did not manage to compile the project yet - because of some general JDK error. But I think I can fix that. Am 30.08.2012 13:44, schrieb Erik Vos: > > OK, you're right. > > The third option you mention is a separate game option that can be set > or unset with any variant. It would be nice if we could set the > default value to "on" automatically if Clemens is chosen, but the > option selection code isn't yet that smart, I believe. > > The other two options only refer to the initial round, so we still > have the option to make the initial round another separate game > option. However, that may change in the future. > > IIRC several variants exist out there that would most likely be > incompatible with the Schlesien extension, so I don't think it's a > good idea to make that a completely independent game option (see also > Mike Bourke's comments). On the other hand, I would find it overly > restrictive to tie Schlesien to Clemens alone. I'm pretty sure that > it wasn't intended that way by Harry Wu. > > As map changes seem more fundamental to me than the initial round > sequence, I would propose to split off the latter to a new game > option, see the "InitialRoundType" suggestion in my previous post. > Two "variants" would then remain for now: Standard and > Coalfields/Schlesien (probably the latter one only). > > For a good overview of (almost?) all proposed 1835 variations, see > http://home.earthlink.net/~gamecorner/1835spac.html > <http://home.earthlink.net/%7Egamecorner/1835spac.html>. > > Although it's unlikely that all of these will ever be implemented in > Rails, we should be prepared to implement the more popular ones (and I > don't know which ones are actually played these days). Further > analysis would be required how that can be achieved in the best way. > Some variants have a built-in different distribution mechanism that > cannot mix with the currently implemented ones, and in that case we > might have to hardcode restrictions on the latter. But that is for > later study. > > Erik. > > |
|
From: John D. G. <jd...@di...> - 2012-08-31 03:32:43
|
On 2012-08-29 14:38, Erik Vos wrote: > Thinking again, perhaps we still need "Variant" for Clemens, because there > is a lot more to the Clemens variant than just the start packet > distribution. IIRC, at least some of the Clemens specialties have not even > been implemented yet. And there are a lot more 1835 variants that we haven't > yet considered, and I fear that at least some of these would not mix well > with the Coalfields/Schlesien map extension. This is no simple matter. > > In any case, I don't want to promote variants to separate games. That would > create a maintenance nightmare. > > Comments from the group on this matter would be welcome. I'm in favor of support for variants. On my to-do list is to add my 1835 Equal Footing Variant (which has slightly different start-packet rules, plus a modified map, more tiles and different upgrade paths, and more trains). However, it seems to me that a "variant" such as Clemens which changes only the start packet should not be listed as a variant but merely an option in the Options tab -- so that it can be played with another variant. Similarly for other small changes. |
|
From: Mike B. <com...@ip...> - 2012-08-31 04:56:33
|
Agreed, in principle, but here we again run into the problems of compatibility testing and the introduction of new source of bugs as a consequence. Mike Bourke Campaign Mastery http://www.campaignmastery.com Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com -----Original Message----- From: John David Galt [mailto:jd...@di...] Sent: Friday, 31 August 2012 1:32 PM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] 1835 Schlesien On 2012-08-29 14:38, Erik Vos wrote: > Thinking again, perhaps we still need "Variant" for Clemens, because there > is a lot more to the Clemens variant than just the start packet > distribution. IIRC, at least some of the Clemens specialties have not even > been implemented yet. And there are a lot more 1835 variants that we haven't > yet considered, and I fear that at least some of these would not mix well > with the Coalfields/Schlesien map extension. This is no simple matter. > > In any case, I don't want to promote variants to separate games. That would > create a maintenance nightmare. > > Comments from the group on this matter would be welcome. I'm in favor of support for variants. On my to-do list is to add my 1835 Equal Footing Variant (which has slightly different start-packet rules, plus a modified map, more tiles and different upgrade paths, and more trains). However, it seems to me that a "variant" such as Clemens which changes only the start packet should not be listed as a variant but merely an option in the Options tab -- so that it can be played with another variant. Similarly for other small changes. ---------------------------------------------------------------------------- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 120829-1, 30/08/2012 Tested on: 31/08/2012 2:56:51 PM avast! - copyright (c) 1988-2012 AVAST Software. http://www.avast.com |
|
From: Oliver H. <oli...@gm...> - 2012-08-31 11:56:13
|
Erik,
I understand your discussion about variants and options. But I am not
sure, what are the implications to how the XML-files have to be changed.
Is this the 18xx-example still valid?
<IfOption name="Variant" value="Basegame,Pere Marquette,Reading,Simple">
<Hex name="F2" tile="-903" orientation="5" value="40,70"
city="Chicago"/>
</IfOption>
<IfOption name="Variant" value="Coalfields,Coalfields&Reading">
<Hex name="F2" tile="-903" pic="-939" orientation="5"
value="40,70" city="Chicago">
<Access runThrough="yes"/>
</Hex>
</IfOption>
<IfOption name="Variant" value="Wabash">
<Hex name="F2" tile="0"/>
</IfOption>
I am waiting for your input how to move on.
Oliver
|
|
From: Erik V. <eri...@xs...> - 2012-08-31 21:32:39
|
Yes, that is valid. There are two ways to do it: 1. Create a separate <IfOption> tag for each and every variant. That is how I did it originally in all situations, and how your example below does it. 2. First define a default case (without <IfOption> tags), and add <IfOption> tags per (group of) variant(s), only defining the differences, which override the default values only if specified That is how I have later started to configure game options. This way, a lot of code can be saved. Erik. > -----Original Message----- > From: Oliver Heck [mailto:oli...@gm...] > Sent: Friday, August 31, 2012 1:56 PM > To: rai...@li... > Subject: Re: [Rails-devel] 1835 Schlesien > > Erik, > > I understand your discussion about variants and options. But I am not sure, > what are the implications to how the XML-files have to be changed. > > Is this the 18xx-example still valid? > > <IfOption name="Variant" value="Basegame,Pere > Marquette,Reading,Simple"> > <Hex name="F2" tile="-903" orientation="5" value="40,70" > city="Chicago"/> > </IfOption> > <IfOption name="Variant" value="Coalfields,Coalfields&Reading"> > <Hex name="F2" tile="-903" pic="-939" orientation="5" > value="40,70" city="Chicago"> > <Access runThrough="yes"/> > </Hex> > </IfOption> > <IfOption name="Variant" value="Wabash"> > <Hex name="F2" tile="0"/> > </IfOption> > > I am waiting for your input how to move on. > > Oliver > > ---------------------------------------------------------------------------- -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2012-08-28 08:35:43
|
BTW, this Schlesien variant appears to be very closely related, but not identical, to the 1835 Coalfields variant by Harry Wu (which I own). While we're at it, I think we should implement both. Coalfields has the same map changes as Schlesien, but no extra trains or tiles. In Coalfields, minor 4 is moved to Breslau, whereas in Schlesien 4a seems to be an extra (16th) minor. Let's sort out these details before we start! Erik. > -----Original Message----- > From: Erik Vos [mailto:eri...@xs...] > Sent: Tuesday, August 28, 2012 10:21 AM > To: 'Development list for Rails: an 18xx game' > Subject: RE: [Rails-devel] 1835 Schlesien > > Hi Oliver, > > You could inspect the 1830 XML files to see how to implement variants. If > that doesn't help you out, I can assist or do (part of) the job. > > Does a document exist that fully describes the rule changes for this variant > with respect to the standard version? For instance, how does the extra minor > 4a convert to a Prussian share? > > The BGG page mentions two versions of this variant, is there any relevant > difference between these two versions? > > Erik. > > > -----Original Message----- > > From: Oliver Heck [mailto:oli...@gm...] > > Sent: Monday, August 27, 2012 9:58 PM > > To: rai...@li... > > Subject: [Rails-devel] 1835 Schlesien > > > > Hi there, > > > > I am interested in implementing a small variant of 1835. There are > > only small changes in the map, tiles and minor companies. If I > > understood the rails concept right, this should mainly be done by > > editing XML-files. As I have only very little experience in > > programming, this might be a good start for a contribution but I still need > some help to start. > > > > You can find the description of 1835 Schlesien at bgg: > > http://boardgamegeek.com/boardgameexpansion/94856/1835-schlesien > > > > Cheers > > Oliver > > > > ---------------------------------------------------------------------- > > -------- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > > Discussions will include endpoint security, mobile security and the latest in > malware threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Mike B. <com...@ip...> - 2012-08-30 02:54:48
|
Logically, games divide into two elements: maps and rules sets. Maps include home bases and therefore starting positions on the board, and determine which corporations exist within the game. Rules divide into special abilities related to the maps, such as port tokens and what-have-you, generic "core" rules, and specific rule implementations for a particular game variant (1830 vs 1856 vs.... and so on). Consider the complications of the Prussian Railway and all the minor companies that form it and placement on, say, the 1830 board. It can't be done. So tokens and corporations are map-and-variant specific. While the facility could possibly be coded in for using separate drop-down boxes to select the map (and related parameters like corporations, tokens, etc) and the rules set to be used, ensuring that all the combinations are mutually compatible would be a nightmare, vastly blowing out the level of testing requirements. There would be times when we would be forced to play god, deciding into which category a particular rule falls (map or system), always with the potential of angering someone who doesn't agree. So this would require a line-by-line reading of, analysis of, possible discussion of, and potential disagreement over, each and every rule in each and every version of the game. I don't think it's worth it. A possible compromise might be to create a map editor that takes the existing elements of the map for a particular game and variant and rearranges their location on the map board, then saves the resulting map in a format that permits it to be used within that system-and-variant. Since the map elements don't change, only their relative placement. But even this would potentially run into problems. Mike Bourke Campaign Mastery http://www.campaignmastery.com Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 120828-3, 29/08/2012 Tested on: 30/08/2012 12:55:05 PM avast! - copyright (c) 1988-2012 AVAST Software. http://www.avast.com |
|
From: Chris S. <chr...@gm...> - 2012-08-30 15:51:02
|
A number of games don't assign home stations to corporations until formation - 1817 is an example. Similarly, in 1861 after a certain phase (the 5 train?) you can start a new major corporation in any unconnected hex. Thus, I think it's a bit too broad to say the map determines the corporations. -- Chris Please consider the environment before printing this e-mail. On Wed, Aug 29, 2012 at 7:55 PM, Mike Bourke <com...@ip...>wrote: > Logically, games divide into two elements: maps and rules sets. Maps > include > home bases and therefore starting positions on the board, and determine > which corporations exist within the game. Rules divide into special > abilities related to the maps, such as port tokens and what-have-you, > generic "core" rules, and specific rule implementations for a particular > game variant (1830 vs 1856 vs.... and so on). > > Consider the complications of the Prussian Railway and all the minor > companies that form it and placement on, say, the 1830 board. It can't be > done. So tokens and corporations are map-and-variant specific. > > While the facility could possibly be coded in for using separate drop-down > boxes to select the map (and related parameters like corporations, tokens, > etc) and the rules set to be used, ensuring that all the combinations are > mutually compatible would be a nightmare, vastly blowing out the level of > testing requirements. There would be times when we would be forced to play > god, deciding into which category a particular rule falls (map or system), > always with the potential of angering someone who doesn't agree. So this > would require a line-by-line reading of, analysis of, possible discussion > of, and potential disagreement over, each and every rule in each and every > version of the game. > > I don't think it's worth it. > > A possible compromise might be to create a map editor that takes the > existing elements of the map for a particular game and variant and > rearranges their location on the map board, then saves the resulting map in > a format that permits it to be used within that system-and-variant. Since > the map elements don't change, only their relative placement. But even this > would potentially run into problems. > > > Mike Bourke > Campaign Mastery http://www.campaignmastery.com > Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com > > > > --- > avast! Antivirus: Outbound message clean. > Virus Database (VPS): 120828-3, 29/08/2012 > Tested on: 30/08/2012 12:55:05 PM > avast! - copyright (c) 1988-2012 AVAST Software. > http://www.avast.com > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > 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