I currently have some code that checks if squash and tennis scores are valid, both in javascript and PHP.
This results in 4 blocks of code existing, 2 languages * 2 sports, which does not scale well should any extra sports come around, or extra languages…
How can one describe the valid scores of games via a settings/text file, so that each language can parse them and apply these rules.
I’m stumped with the strange tie break situations in tennis should it reach 6-6 in a set, and also infinite play off in the final set should it reach 2 sets all.
ie:
tennis = {
"format": [
{
"name": "sets",
"min": 3,
"max": 5,
"winby": 1
},
{
"name": "games",
"min": 6,
"max": 7,
"winby": 2
}
]
}
squash = {
"format": [
{
"name": "games",
"min": 3,
"max": 5,
"winby": 1
},
{
"name": "points",
"min": 15,
"max": 0,
"winby": 2
}
]
}
This is certainly not an easy task; what you need to is fold behavior into data structures, that is, you need a generic score check algorithm that covers all the games you need, and has configurable rules (which it takes as parameters, in a format digestible by either of the target programming languages).
The first step, obviously, is to come up with a generic data structure that can accurately represent the scores. For example, for soccer, hockey, basketball, etc., a simple pair of integers will do; but other sports, such as tennis, require more complex data structures – e.g., a list of pairs of integers. So for example a soccer result could be, in pseudocode, [(1, 3)] (a list with one pair, representing the result “1:3”); a tennis result could be [(6,1), (6,2), (7,6)] (I’m not exactly sure about tennis rules though). And obviously, if you want to model scores within sets, you have to extend your data structures accordingly. (A note on tennis scores within games: while the counting is nonlinear, there is a very small number of valid scores, and they can easily be mapped to a linear integer space – [ "love", "15", "30", "40", "game" ] can be handled internally as [ 0, 1, 2, 3, 4 ], and then mapped back to the idiomatic value for display.)
Then you need to implement generic constraints on these scores; some will work on individual pairs, others will consider the result as a whole. For example, one such constraint might be “minimum number of result pairs”, and its parameter would be 1 for soccer, 3 for tennis. Another might be “scores within one pair must not be equal”, and it would be applied to tennis and knock-out style soccer matches, but not pooled or league-style soccer matches (where a draw is possible). Make enough rules to cover all the constraints.
A configuration file might then look something like this:
[
{
"sportName" : "soccer",
"rules" : [
{ "ruleType": "numberOfSets", "number" : 1 },
{ "ruleType": "minScoreValue", "value" : 0 }
]
},
{
"sportName" : "soccer-knockout",
"rules" : [
{ "ruleType": "numberOfSets", "number" : 1 },
{ "ruleType": "minScoreValue", "value" : 0 },
{ "ruleType": "noDrawsWithinSet" }
]
},
{
"sportName" : "tennis",
"rules" : [
{ "ruleType": "minNumberOfSets", "number" : 3 },
{ "ruleType": "maxNumberOfSets", "number" : 5 },
{ "ruleType": "minWinningSetScore", "value" : 6 },
{ "ruleType": "maxWinningSetScore", "value" : 7 },
{ "ruleType": "noDrawsWithinSet" }
]
}
]
The last part you need is glue to put it together: a rules engine that loads rules from a file, instantiates the appropriate checkers, and applies them to the specified scores. This last part is simply a matter of iterating over the applicable rules (recursively if you have nested scores such as for tennis) until you find one that doesn’t match.
As you add more games to your system, you’ll have to add more constraint types, but if you keep them generic and parametrizable, the chances of existing rules already covering a new game grow as you go.
In fact, you are implementing a DSL (domain-specific language) to describe game scores and rules.
1