Variants are pretty heavy weight, especially around configuring the key/value displayName and description. It uses a heavyweight callback to fetch names and display names for each one. Originally I think that was to make it easy to get it added without having to write a lot of extra methods ;you could layer in the name/displayName/description later. also, that way you didn' tneed yet another silly top-level struct.
But in practice you always need to add that information for a real game, and things like #687 might help generate those methods for you automatically when you need them.
It might be that the name/displayName/description triple is useful for other things in the library so it doesn't have to be that big of a deal to add.
type VariantConfig []VariantKey
type VariantKey struct {
Info VariantValue
//The name of the value that is default
Default string
Values []VariantValue
}
//TODO: name this something more general?
type VariantValue struct {
Name string
DisplayName string
Description string
}
func (g *gameDelegate) Variants() VariantConfig {
return VarianConfig{
Info: {
Name: "size",
DisplayName: "Size",
Description: "Number of cards to use",
},
Default: "normal",
Values: []VariantValue{
{
Name: "small",
DisplayName: "Small",
Description: "10 cards",
},
{
Name: "normal",
DisplayName: "Normal",
Description: "100 cards",
},
},
}
}
func (v VariantConfig) Valid() error {
//Ensures deafult denotes one of the items (if not specified defaults to first), also verifies each key is unique name. If a Value is missing a DisplayName, the DisplayName defaults to title case of the Name, with "-" and "_" replaced with " ". (That could be a getter on VariantValue)
}
The config passed to your LegalVariant will have had any keys that aren't set set to their default.
Noticed while fixing #678 .
Variants are pretty heavy weight, especially around configuring the key/value displayName and description. It uses a heavyweight callback to fetch names and display names for each one. Originally I think that was to make it easy to get it added without having to write a lot of extra methods ;you could layer in the name/displayName/description later. also, that way you didn' tneed yet another silly top-level struct.
But in practice you always need to add that information for a real game, and things like #687 might help generate those methods for you automatically when you need them.
It might be that the name/displayName/description triple is useful for other things in the library so it doesn't have to be that big of a deal to add.
The config passed to your LegalVariant will have had any keys that aren't set set to their default.