-
Notifications
You must be signed in to change notification settings - Fork 1
CGS as JSON
Aside from LCGS files, describing how the model should be build, CGAAL can also accept JSON files, where the JSON describes the fully build model. This wikientry will describe the format that the JSON input should be in.
In essence the CGS JSON file contains 4 objects, player_count, labeling, transitions and moves. Each of these objects, contains some information that is used to either parse the model, or explain the models form, which CGAAL uses to explore.
Is an object containing an integer, this integer explains how man players that is used in this CGS. As all players requires one move, for each state. We use this number, to ensure that there is a move for all players.
Example:
"player_count": 3
Is an object containing a list with the length of all states in the CGS model. Each index in said list, contains a list of all labels that has a value of True.
Example:
"labeling": [[1], [2,4,6], ..., [1,2,6]]
Is the most complicated of the objects in the JSON file, it contains a nested list, just like the labeling object. Yet this is as deep as there are players. The innermost list contains the final decision for p3, and the integer here represents which state that this combination of moves results in. So for a game with 3 players, the indexing transitions[0][0][0] would be valid, and if it were to return, say 5, then it would indicate that this combination of moves would result in moving to state 5.
This results in the list becoming rather hard to read, as you have to keep track of the [] which indicates all moves for all players, this also makes it hard to illustrate a simple example, as even for simple ones, it is quite space consuming, but one example could look like this, for 3 players, where p1 has 3 different moves they can make, p2 has 2 different moves they can make, and p3 has 4 different moves.
Example:
"transitions": [[[[1,2,3,7],[1,6,7,12]], [[1,5,7,10],[4,5,6,7]], [[1,10,52,105],[10,74,105,284]]]]
As you can see, it is quite space consuming, and has many possible branches. But based on this, we can say that f.eks. p1 and p3 can together guarantee that we in this transition hit state 7. But now imagine if p2 had 3 or more moves, and we can see that the statespace almost explodes.
Is an object that contains a list with the length of all states in the CGS. Each index of the list contains a list, which shows how many moves each players has, where the first index represents the first player, the second index the second player etc. As the players do no require to have the same amount of moves throughout the model, this can differ quite a bit. Yet one thing must always hold true, and that is that each player always has to have 1 move in each state.
Example:
"moves": [[3,2,4],...,[2,2,2]]
As the JSON file is an illustration of the whole model, it can be quite cumbersome to read or write, and hidden errors could be contained, due to the low readability. We thus recommend that if you were to write a model by hand, that you use the LCGS, and only uses this JSON possibility if you were to generate the models automatically.
A full example of a JSON file can be found in the codebase under json-examples. The handwritten JSON example: https://github.com/d702e20/OnTheFlyATL/tree/main/json-examples/mexican_standoff and the generated JSOn files: https://github.com/d702e20/OnTheFlyATL/tree/main/json-examples/random_generated