Node manipulation by level

[vegaro]

As mentioned in #3 and gambitproject/gte#32

Quoting @stengel on 26th July 2015:

I enclose a new picture to illustrate this. This is not urgent but if in place would allow to grow game trees quickly, and I think it is not too difficult to implement in SVG, in particular since it is similar to something you have already done with the information set:

• All nodes on the same level of the game tree are in a "level set" which I call the "multiaction line". It is the following SVG object:
  • An invisible line of THICKNESS the same as the diameter of the node disks,
  • Which HIGHLIGHTS (in gray) when hovering over it, i.e. between any two nodes,
  • But when hovering over a node this has priority, i.e. the "multiaction" line does not appear. This is exactly the behaviour that applies currently (26 July 2015) to the information sets.
• the idea is that when clicking on the multiaction line, the operation (such as adding children) applies to all nodes on the multiaction line (i.e. on that level)
• because an information set has a similar behaviour, the "multiaction" line will not appear on levels that have information sets are not singletons because I think this would be too confusing. On such a level either the information set has to be dissolved first or only clicking on nodes and information sets is possible. In short, the multiaction line only contains all nodes on one level if these are not yet in non-singleton information sets.
• what happens when you click on the multiaction line depends on the MODE you are in:
  • add children
  • delete nodes
  • set player
  • merge all nodes into one information set (most complicated, save for later)

We consider these now separately. The important thing is that the EFFECT of clicking on the multiaction line should be UNIFORM, not the ACTION, which makes it more predictable (see also the discussion in
gambitproject/gte#32). To illustrate this point, suppose we ADD children to the
multiaction line highlighted in the enclosed picture multiaction.png

Here all nodes have two children except for the second node. Here, in mode "ADD CHILDREN" (+) clicking on the line should give two children to the leaf. After this all nodes have the same number of children, namely two, and clicking again on the line will then add a third child to each node.

General behaviour for "add children":

• find the smallest number S and largest number L of children for the nodes in the multiaction line.
  • If S < L, add children to those nodes so that ALL nodes have L children now.
  • If L = 0, add two children to each node on the multiaction line, else
  • If S = L, add one child to each node on the multiaction line.

General behaviour for "delete nodes":
Again, the aim is to have predictable behavior.

• if ANY of the nodes in the multiaction line have children, delete all their children but keep the node itself as part of the tree (i.e. even if some nodes are leaves already, do not delete them).
• otherwise (that is, ALL nodes in the multiaction line are leaves), delete all these leaves.

General behaviour for "set player":

• set all nodes on the multiaction line to belong to the current player (which may be chance)

General behavior for "create information set":

• suggestion: postpone here any multiaction for the moment.
• note that this mode button only works if every node belongs to a player already.
  • now if all nodes on that level belong to the same player AND have the same number of children, they could be united into one information set
  • if that is not the case, i.e. the nodes on the level belong to different players, then one could merge CONSECUTIVE nodes on this level that have the same player and same number of children into information sets.
    I am not sure this is a very time-saving activity, hence postpone this.

However, for ADDING NODES and SETTING PLAYER the multiaction functionality would be useful to create a game tree quickly.

The UNDO operation (which we don't have at all yet) would naturally have to apply to the entire multiaction operation, so this is important when recording the state of the game before applying the multiaction operation.

[shiv2994]

Hey.
I used the application for a while and tried out the various options available. I was wondering. Wouldn't it be better if the transitions that take place in general or on using the level function are slower so that that the user can observe the changes that take place? This would be very helpful in situations where the tree is rather complex. Or if the person isn't well versed with the application and the way different options behave in different situations. The user could try using the undo and redo option to understand the change but a slower transition from one state to another would result in a much better understanding of what each option is doing.