tswift242
commented
10 years ago @JLoppert I was originally thinking of having separate CSV files for each player type, bu it's probably unnecessary if the data is formatted such that the player type is the first column. I think specifying the name of each stat is probably unnecessary too, as long as we keep to a consistent format/ordering. I think a pretty good file format would be:
player_type, player_name, stat_value0, stat_value1, etc.
From the player_type, you could find out the number of fields you'll need to read in and/or you could re-use/re-work some of the parsing logic I have throughout the codebase for parsing args from the command line (check Mode.java for example and trace through. The methods in there will parse args in the format of "player_type, stat_value0, stat_value1, etc." for any given player type. The entire workflow probably isn't reusable, but you could probably incorporate bits and pieces of it)
I think as far as accepting a subset of the required values, you can get the equivalent of this by just setting any value you don't care about to 0 in the CSV. Using the more verbose approach with specifying each stat name would also be harder to work into any existing parsing infrastructure that's already there, if we want to leverage that.
EDIT: the parsing infrastructure I have is for parsing rules, not stats (e.g. "parseScoringRules"). However, rules and stats have a 1-1 correspondence, so I would think they could be re-used, or at worst re-worked slightly to handle this situation.
@tswift242 I'm making progress on the UI for the file import, but I wanted some clarification on the CSV format. Will there be separate files for each player type? I don't think it's necessary, but it could make the parsing logic easier depending on the input format.
I had two file format options in mind:
There are pros and cons to both approaches. The former can accept a subset of the required values, but it is verbose. The second format is more restrictive, less verbose, but could be parsed faster (maybe?)