Add fan expansions to the database

[jthayne]

Would it be possible to have the ability to add fan expansions to the database?

Expansions I am aware of:

• http://boardgamegeek.com/boardgameexpansion/141918/duel-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/123095/scrolls-power-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/139778/warmonger-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/128915/paradox-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/88046/royal-court-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/80435/salvation-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/69035/books-magic-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/68281/fairy-tale-fan-expansion-dominion
• http://boardgamegeek.com/boardgameexpansion/203184/animals-expansion-mini-fan-expansion-dominion

[nickv2002]

Thanks for the suggestion @jthayne

I think we've been busy rewriting significant parts of the code of late to support the 2nd editions, foreign languages, and some other features, but I could see tackling this in the future.

That said, if it's something you're interested in making happen, and since this is a collaborative team project, it would help us greatly if you were able to contribute. You don't have to know how to code: what we'd need most help with here is just translating all the attributes of each card into an organized format that the computer can read. Take a look at the format of cards in the card DB and the English translations to see what it looks like.

If you're up for helping, consider modifying those files with one of the small expansions you linked above so we can test things out. (Look up how to do a GitHub clone & pull request or let us know if you need more help)

[sumpfork]

See #148 for a contribution from a BGG user. I think we should talk about whether these should be in a separate list/option - I feel they should be.

[wvoigt]

I agree. I think it would be best to separate them. Otherwise it could add a large number of cards, and translators could be even more intimidated if they feel they must translate fan expansions too. But I also think it would be a waste if someone feels the need to duplicated the effort that has already been done here, just because we don't support fan expansions.

On the backend of the generator, it does not care if it is original or fan based. Assuming we keep all the file structures the same, it really is just adding a little code to add in the fan expansions (and their translations.)

So I propose we:

• Keep the internal structures of the files the same.
• Add new versions of the files for the fan expansions (maybe prepend fan_ to each of the files.)
• Add option called --fan that works just like --expansion to pick up the fan expansions
• Then add the code to load those in too if selected.

My worry is if any of the fan expansions go wild and have their own base cards, or have new cost structures that are not compatible, etc.. Then it gets to be a much bigger coding challenge.

[nickv2002]

I think @wvoigt has it all mapped out pretty well.

We should not commit to supporting fan expansions, particularly in in the case of expansions with new base cards, card types, etc where lots of work would be required.

[sorawotobu]

Would a custom card option be a lot of work? It would be a reasonable way to address the fan expansion issue, not just for the ones posted but all fan expansions past and future.

[wvoigt]

@sorawotobu , I'm not sure what you mean by a "custom card" option. Can you elaborate.

@sumpfork and @nickv2002 So I took a look at this again this morning. I quickly looked at the Dominion fan expansions listed on board game geek. Most of them fit well in the existing structure. I found 2 that would need a new inline graphic substitution, but that is not really that big of a deal to add. If it is thought that the inline substitutions need to be generalized and separated out between official and fan expansions, then the work would be greater. Of course they all have new card types, but that can be easily be handled with the existing structure.

I also took a look at what it would take to make changes to main.py to load in separate files for the fan expansions. And as expected, there is nothing too difficult there. Just duplicating file loads and merging the fan information with the existing cards.

My only concern is we add 3 more files to the main db, and 4 new files to each language to be translated. And except for cards_db.json and the xx/cards_xx.json files, the files themselves are pretty small.

So the real question is the degree of separation we want for the fan expansions. Is it truly by files so everything is separated, or do we combine the files and just have a separate --fan option to select the fan sets? Separate Files:

• Pros
• Everything is separated. Official is not mixed with fan expansion. We would still need to make sure that any set and card tags are unique across all expansions, both Official and Fan.
• Cons
• More files to deal with. More files to load each time.
• Maintenance/Upkeep will be harder. If structural changes are made, more files to update.
• More files for translators to deal with. Translators may never even look at the fan expansions.

Just adding to existing database, but still have --fan for Fan expansion and --expansion for Official

• Pros
• Smaller code changes to main.py. Almost ready to go (just need to add --fan and keep --expansion/--expansions from picking up the Fan expansions)
• Don't need all the additional files. Everything, both Official and Fan are in one place. For most files, they don't change in size all that much.
• Keeps the same number of translation files. And translators might just translate Fan expansions anyway while they are translating everything else.
• Cons
• cards_db.json and the xx/cards_xx.json files will be bigger.
• ... and that might more easily overwhelm translators.
• Slightly harder to tease out Fan expansion names for '--fan'. Probably would need a new set attribute to designate as Fan expansion.

To be honest, I've gone both ways on this. I started thinking it would be best to separate out everything. Now I'm second guessing that. I wonder now if it is just easier, quicker, and actually better in the long run from a maintenance standpoint to combine them all and just work out the --fan vs --expansion selection.

Thoughts?

EDIT: Thinking about it more, I think no matter which way we go, we will need a new attribute for the sets in sets_db.json (or the fan equivalent) to differentiate between official and fan based. I propose simply "fan": true, for the the fan expansions. We can do a quick run through the sets and set the attribute to false for any set missing the attribute. Then it makes the work of teasing out Official expansions from Fan expansions much easier for the --expansion and --fan options. I added this small change to Pull #148.

[sorawotobu]

What I mean is allow people to enter a name and cost, possibly upload an appropriately sized image as an expansion symbol, if they choose to print card text or rules on the dividers have them enter those as well. "Custom Cards" would be an additional Expansion you could select, "enter custom card" could be among the generation options.

[nickv2002]

@wvoigt I'm mulling your ideas and will have feedback soon.

@sorawotobu What you're describing would take extensive changes just to allow users to upload content, not to mention integrating that content with the existing data. Not that it couldn't be done but it's probably unrealistic for a small project like this: I can't see us switching from the current model of using GitHub to manage all the data/metadata for the Dominion Cards & expansions.

[nickv2002]

@wvoigt I think option 2 is better in the long run too as long as all fan expansions get the "fan":True attribute it should be easy to sort in code.

Thanks for all your hard work on this and all the update. I feel like I'm just cheering and commenting from the sidelines.

[sumpfork]

I made some comments on #148 - I think we should provide a way to turn off official expansions, like --expansions=none, default the fan expansion selection to that value, and in the process merge the code for interpretation of both arguments.

[sumpfork]

We technically support fan expansions, but no more have been submitted since the original one. Closing this in favour of opening more specific issues if they arise.