|
Post by teohhanhui on Apr 10, 2020 7:52:10 GMT -8
|
|
|
Post by teohhanhui on Apr 10, 2020 7:56:31 GMT -8
(Reply reproduced from the general-game-playing@lists.stanford.edu mailing list) It can be challenging to represent constructs like loops of points that may conditionally consist of very large amounts of data in GDL. Even when such a representation is technically correct and in compliance with the GDL specification, it may cause interpreters of the GDL to fail or slow to unusable conditions. (There's an old version of hex that caused many issues like this, which used a "linked list"-like construct to represent arbitrary chains of points; see the "list definition and operators" section here: ggpserver.general-game-playing.de/ggpserver/public/view_game.jsp?name=laikLee_hex) For the problem of "representing a move of high complexity", one approach that has worked in other games is to split up inputs over multiple moves. In this case, this would treat each segment (pair of dots) in the loop as a move; if I wanted to capture the rectangle formed by dots ABCD, I'd input a "capture A B" move, followed on consecutive turns by "capture B C", "capture C D", and "capture D A" moves. The problem here is, what do you do if a player starts such a move but can't finish it legally? (Other games where this approach has worked, like English Draughts and Dots and Boxes, don't have this problem; the prefixes of legal moves can be checked for legality as they go.) The other issue to look at here is how to determine whether dots are surrounding another group of dots. This can actually be dealt with somewhat more easily by rephrasing the question as: "Is this dot not surrounded by enemy dots?" That turns into a recursive property of the dots: If I'm understanding the game rules correctly, a point is not-surrounded-by-red if it's on the edge of the grid, or if it's not a red dot and adjacent to a not-surrounded-by-red point. I've used this type of recursion in GDL in a few cases, in versions of Hex and Go that it looks like I may never have published; some propnet-based interpreters can handle this type of recursion reasonably efficiently. (Published versions of Hex and Atari Go use a slightly different method of tracking such connectivity.) Such recursion could be used to track captured dots in a way that may not require additional moves (or where the move looks like, "capture the group of dots that includes the dot at (X, Y)"). For extended discussion, a thread on ggp.boards.net/ might be a better forum. Hope that helps, - Alex Landau
|
|
|
Post by teohhanhui on Apr 10, 2020 8:16:02 GMT -8
The other issue to look at here is how to determine whether dots are surrounding another group of dots. This can actually be dealt with somewhat more easily by rephrasing the question as: "Is this dot not surrounded by enemy dots?" That turns into a recursive property of the dots: If I'm understanding the game rules correctly, a point is not-surrounded-by-red if it's on the edge of the grid, or if it's not a red dot and adjacent to a not-surrounded-by-red point. I've used this type of recursion in GDL in a few cases, in versions of Hex and Go that it looks like I may never have published; some propnet-based interpreters can handle this type of recursion reasonably efficiently. (Published versions of Hex and Atari Go use a slightly different method of tracking such connectivity.) Such recursion could be used to track captured dots in a way that may not require additional moves (or where the move looks like, "capture the group of dots that includes the dot at (X, Y)"). The suggested algorithm didn't work for the game rules, so I have come up with an alternative: looking for a path made up of unfilled edges until we reach the border (a wall edge). From what I can tell, this only leaves the edge cases where some chain segments are shared between different chains (of the same player), because it means for a given coordinates, there might not be any adjacent edges which are unfilled. I suppose that can be handled by allowing traversing from one filled edge to another, and then proceed as usual onto unfilled edges as needed (if it's not a wall edge yet). Hopefully my implementation is correct, and that the recursion is okay for the GDL interpreters. Anyway, the situation around tracking of captured dots (for scoring) is trickier. There's the possibility of re-capturing an area previously captured by the opponent, by drawing a larger polygon around the perimeter which contains the opponent's chain (i.e. nested chains), so we should probably only consider the outermost chain when counting captured enemy dots (or we could just decide to double count, if this is too hard). I've updated the snippet at the same link: https://gist.github.com/teohhanhui/0156b9000cb997b497a191f0a7387bb9Thanks again for your help.
|
|