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