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. > > |