The sample code for Gomoku does something a little strange and non-obvious, which makes
it a bad example. Perhaps the code should be changed, or at least commented to explain itself.
The oddness is this. When you place a stone, a new subnode is added to the intersection containing
the visible stone, and then the position of this subnode is animated into position by the "slide" operation.
On the other hand, when you refresh or reload the board, the intersection is created with the stone
already in place, with no subnode. Consequently, node structure of the reloaded board is different
from that of the played-straight through board.
This can lead to subtle differences in the behavior of the UI when you play normally and when you
reload the game, as you do a lot during development.
This didn't cause any problems for Gomoku because stones are placed and never removed,
and because the artwork for the "click here" ring was a little smaller than the art for stones,
so the "click ring" for placed stones was never visible.
it a bad example. Perhaps the code should be changed, or at least commented to explain itself.
The oddness is this. When you place a stone, a new subnode is added to the intersection containing
the visible stone, and then the position of this subnode is animated into position by the "slide" operation.
On the other hand, when you refresh or reload the board, the intersection is created with the stone
already in place, with no subnode. Consequently, node structure of the reloaded board is different
from that of the played-straight through board.
This can lead to subtle differences in the behavior of the UI when you play normally and when you
reload the game, as you do a lot during development.
This didn't cause any problems for Gomoku because stones are placed and never removed,
and because the artwork for the "click here" ring was a little smaller than the art for stones,
so the "click ring" for placed stones was never visible.