This refers to conventions in the file format and program. In principle, these are unambiguous encodings and we could keep them. Question is if we should allow for blank move names.
Because the user may go back to earlier stages when creating
a game, the game may have unassigned players, moves, or
payoffs even if some of these are defined. However, with
unassigned players to nodes the stage cannot go beyond the
PLAYERS stage.
Currently, an UNASSIGNED player is a node without a player
attribute (which is also interpreted as a chance node), but
where the move probabilities are "NaN".
An unassigned MOVE is a blank character. If you manually
replace a single move with a blank and come back to the MOVE
stage, the blank move name will be automatically replaced.
In short, it is hard to use blanks as move names, but then
there is also no good reason to allow them. Logically, the
move name is irrelevant for solving the game.
This refers to conventions in the file format and program. In principle, these are unambiguous encodings and we could keep them. Question is if we should allow for blank move names.
Because the user may go back to earlier stages when creating a game, the game may have unassigned players, moves, or payoffs even if some of these are defined. However, with unassigned players to nodes the stage cannot go beyond the PLAYERS stage.
Currently, an UNASSIGNED player is a node without a player attribute (which is also interpreted as a chance node), but where the move probabilities are "NaN".
An unassigned MOVE is a blank character. If you manually replace a single move with a blank and come back to the MOVE stage, the blank move name will be automatically replaced. In short, it is hard to use blanks as move names, but then there is also no good reason to allow them. Logically, the move name is irrelevant for solving the game.
An unassigned PAYOFF is stored as which is empty.