Validate round numbers

[jonahgreenthal]

A few times this year I've seen people use round numbers in nonstandard ways:

• 1.1 for the first game in round 1, 1.2 for the second game in round 1, etc.
• 5.1 for tiebreakers that occurred after round 5 (I imagine they might have used 5.2 if they had a second stage of that breaker)
• -1 for…actually I have no clue why

Round numbers should be positive integers. Tiebreakers can be their own round (i.e., in the second case above, those should have been round 6, and the next stage start with round 7). If we want to provide a sort of "sub-round" functionality for multi-stage tiebreakers, go for it.

[ANadig]

I haven't gotten to the game entry part of rewriting things, but my plan was to enforce positive integers for normal rounds, and then not even have editable round numbers for tiebreakers (the system will be aware of what tiebreakers you potentially need, and where those games should go in the tournament structure). In the background, the round would be some sort of text description, which is consistent with the schema specification for the Round name property.

[jonahgreenthal]

and then not even have editable round numbers for tiebreakers (the system will be aware of what tiebreakers you potentially need, and where those games should go in the tournament structure)

I'm not sure what this means. Surely people need to be able to enter whatever tiebreakers they want rather than be forced into what software thinks they need?

[ANadig]

What I mean is, there's no reason to allow users to enter an arbitrary game for an arbitrary round number and then mark it as a tiebreaker. If your tournament has a prelim phase and a playoff phase, there are exactly two kinds of tiebreakers that make sense to enter: prelim->playoff tiebreakers, and playoff->finals tiebreakers. These two buckets would each logically be one round in the data structure, and the idea of a numeric round number doesn't apply.

[jonahgreenthal]

I think that's generally true, but I'd be pretty wary of making the program so inflexible.

Also, what happens if you import a file that has tiebreakers already marked in a way that's not compatible with that model?

[ANadig]

Yeah, there are many yet-to-be-resolved questions about what happens when we open a file from older versions, or a vanilla qbj file (I'm changing the file format to essentially match the qbj schema but with extra information in some objects). Ultimately, things will probably look like:

• The application runs in some sort of "basic mode" when you open a file that doesn't have enough detailed information about the tournament structure
• Various "I know what I'm doing, trust me" options to allow you to override things that you shouldn't normally need to change (as an example that I've already implemented for the next version, there's a way to change the bonus divisor setting, but normally it isn't editable).

My main priority is to make it really easy to do the normal things correctly, because I've seen enough evidence that they aren't easy enough.

[jonahgreenthal]

Yeah, there's major tension between your last paragraph and my last comment. I think a lot of "trust me" options is a good way to handle that if it doesn't make development and support too complex.

[jonahgreenthal]

Also, if you want to make suggestions for changes to the QBJ schema, they would be welcome.