What is a variant?, and more

[Martin Bruse]

I started thinking about what a variant is, after Chris mentioned mixing in units e.g. wings in any variant.

I figure orders should be mixed in the same way, like set a flag to play Classical but with "build anywhere".

You still want the normal variants, though - you want to play Hundred and know what the defaults are.

So, maybe we should express order sets as configurations in the variants (in some sense they already are, I guess, but more as something defined by a string or number so that the game server can say "variant so and so but with this other order set").

Then we could define unit sets the same way, and start with small changes, like new unit types, when we want to create e.g. Modern.

This way we would be able to mix in order and unit types any way we want in any game. Neat.

Not trivial to implement, but should be possible and not exactly rocket science.

What new unit types do you want then?

I'm considering a few that might be fun, apart from the ones I've already read about, like the wings in modern:

- Submarines: Other players only see where they were the previous movement phase, nobody but their owner knows where they are NOW.

- Bombers: Can only move between owned SCs, but does so in one phase no matter how far between. Can support anywhere on the map no matter the distance.

Comments? Other ideas?

[Chris Babcock]

Two good sources for material there would be the North American Variant Bank <navb.org> and the DPJudge <floc.net/dpjudge>, assuming that both sources are still available and at the URLs I remember.

The DPJudge has the documentation on the variants implemented for play there. I have source code, which has been previously released with a Berkeley license whether or not it is currently published. Since that is written with Python, the devs delighted in making all the code as reusable as preternaturally possible.

The variant bank used a taxonomy called ARDA classification to describe variants. While most ARDA classifications had to do with map variants, two noticable exceptions were press variants and mix in variants. 

Chris

--
You received this message because you are subscribed to the Google Groups "diplicity-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diplicity-de...@googlegroups.com.
To post to this group, send email to diplic...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Babcock]

I mentioned that the variant taxonomy used thoughout the 90s and 00s was largely centered on the maps. If I was to do my own taxonomy, I think I'd use a tag system rather than a hierarchy. The ARDA system had overlapping categories, which meant that the maintainer had to guess the author's intent in creating the variant in order to make classification. Some of the decision trees were more rigidly defined than others, but the maintainers didn't always understand the background for variant necessary to classify it as fans expected. A large format map based on a literary work might have been misclassified as large format if the maintainer was not familiar with the work it was based on. With a tag system, you only vet tags for relevance, not priority, so it's not necessary to make those kind of arbitrary decisions in order to place the variant in a way that will be discoverable.

Since most mix in variants are off by default, the map variant contains your base rules, which mix in variants can modify, and a list of variant rules that are exceptions to off by default for that map. 

There will still be situations where map variants need to be modified to support a mix in. These are rare. It's not unreasonable to expect the implementer of a mix in to modify existing map variants as needed and to document what needs to be done in future map variants to support the mix in. For example if Blind was to be implemented, any variant with a variable starting position would need to define how that is described to players. A tag system would aid in identifying existing variants that need intervention to work with new rules and alerting map publishers of potential issues with existing mix in variants.

Additionally, variant code should be maintained as if it was a library with versioning distinct from the server source. Variants can potentially infringe on intellectual property. If possible, you want to sandbox execution of code for variants and load them from externally maintained sources. The server operator then would only need to implement a DMCA compliant complaint procedure in order to be protected under the Safe Harbor provision. If someone wants to play a variant not previously supported in the server, they give the server information on the repository and go for it. If the variant map infringes some IP, like Pern or one of the LotR maps, the operator's liability is limited to ceasing publication of games based on that repository. A PITA, but better than getting a cease and desist letter.

This was going to be about taxonomy of mix in variants. I'll do that later.

Chris

On May 9, 2018 11:51 AM, "Martin Bruse" <zond...@gmail.com> wrote:

--