Ludii Forum
New Game - Netted but inefficient and buggy... - Printable Version

+- Ludii Forum (https://ludii.games/forums)
+-- Forum: Problems (https://ludii.games/forums/forumdisplay.php?fid=5)
+--- Forum: Game Problems (https://ludii.games/forums/forumdisplay.php?fid=17)
+--- Thread: New Game - Netted but inefficient and buggy... (/showthread.php?tid=606)

Pages: 1 2


New Game - Netted but inefficient and buggy... - dale walton - 06-15-2021

I scripted a new game "Netted" which has regions based on extended connections.  Apart for a few problems, it could be submitted, however:

To avoid defining and handling spurious pieces and sites, I used counting Steps with a step to with multiple conditions.
For the most part it works, but the AI can barely handle very small boards.

However, I get unexpected results from time to time which I suspect is due to my not understanding "Intervene" fully, or a bug in the way I used it within Step To.

I am using it to define disallowed steps to empty cells between adjacent, diametrically opposite opponent's pieces. Those spaces are part of the "Net" and don't count as liberties on the edge either -- but steps should be allowed across self-occupied cells between opposed Enemies.  Perhaps there is a better way.

The trial example shows a false game ending where the script thinks that access to the adjacent edge cell is blocked (below it, to the right), but in fact it is not blocked, and the game shouldn't end here.

Most of the time it works, so I don't know why it misses just a few cases.  Does "Intervene" have special edge behavior?

Is there a less intensive approach to the whole problem?


RE: New Game - Netted but inefficient and buggy... - dale walton - 06-15-2021

Here is an updated version without  "Intervene" which works correctly, but is even slower for AI....


RE: New Game - Netted but inefficient and buggy... - dale walton - 06-16-2021

Here is a version that  avoids the intervene by marking the cells (which improves clarity for the players, but is not much faster)

However I also added the diagonal connections centered on the edges, and that has a bug of using the wrong index ---  but you may have fixed this bug already for  N-Mesh....


RE: New Game - Netted but inefficient and buggy... - dale walton - 06-16-2021

In this version, I commented out the Diagonal connections for testing overall, and ran into strange behavior of being able to select sites that are occupied by balls.  I changed the remove to specifically remove only as many connection pieces at a site as needed to enable placement, but the problem of allowing selection of the ball-occupied sites still exists.  See trial.

------------------------------------------------------
For this case changing:

(= 2 (count Pieces #1 "Ball" in:(intersection (sites Around Cell (from)) (sites Around Cell (to)))))

to

Work-around:
(= 2
(count Sites Cell
  in:(intersection
  {
    (sites occupied by:#1 component:"Ball" on:Cell)
    (sites Around Cell (from))
    (sites Around Cell (to))
  }
)))

Worked,
--> so the bug appears to be that "Ball" in (count Pieces #1 "Ball"  is not being processed.

-------------------------------------------------------------------

Also please confirm that the bug concerning the use of the wrong index in the following (currently commented out code) is the bug that was already fixed for N-Meshed, as the fix is not yet released:
i.e in:

(add
    (piece (id "I" Mover))
    (to Edge ("HalfWayEdge" (last To) (value)))
  )

or  in

(define "SharedCells" (intersection (sites Around Cell #1 Orthogonal) (sites Around Cell #2 Orthogonal)))

(define "HalfWayEdge"
 (min (intersection
  (array (sites Incident Edge of:Cell at:(regionSite ("SharedCells" #1 #2) index:0)))
  (array (sites Incident Edge of:Cell at:(regionSite ("SharedCells" #1 #2) index:1)))
))

(I also had compile problems when trying with out the array conversions, when passing a (value) parameter, and other problems when passing a (site) parameter, which is why the strange construction) - but the construct is working except for the location on the screen.

(i.e.  the pieces end up on the wrong edges, or if the Cell locations are to big, the Edge locations between them are bigger than the range of CELL (instead of EDGE) locations causing out-of-range errors.)


RE: New Game - Netted but inefficient and buggy... - Eric Piette - 06-17-2021

Hi,

Can you sum up what I am supposed to look at? The last lud file and the trial? Another?
Just the questions in the last message?

Making a lot of messages with a lot of questions with modifications in the middle of each message does not make the task easy for us. And I do not see how I would be able to help you with that. Please tell me which questions with which .lud (one single lud) for us to be able to understand what you asked here.

Regards,
Eric


RE: New Game - Netted but inefficient and buggy... - dale walton - 06-17-2021

I understand it can be confusing, but there can be more than one problem in a script.

1) Main outstanding point:
What I cannot work around is the the problem with the "I" pieces placed on the edges showing in the wrong positions and/or causing index out of range and preventing the move. This could be the same bug as N-Meshed that you said you have fixed - but is not yet released. Please fix or confirm it already is fixed... (you can see the problem in the " ... 1.2.1b.lud" file (or not see it, if it is already fixed) Just try placing two pieces of the same color diagonally adjacent and see where/if the connection line is placed.

Minor additional requests
2) The rest I have worked around, however scripting like this is like walking through a minefield, so I have posted so you can clear them. I think you would want to remove bugs that are clearly identified and appreciate me taking time to identify the problem. So FWIW:

Definitely, in "(= 2 (count Pieces #1 "Ball" in:(intersection (sites Around Cell (from)) (sites Around Cell (to)))))" the Ludii is ignoring the "Ball" constraint.

3) There must be a cleaner way to handle the Halfway edge scripting instead of converting to array, but I had compiler errors with many tries and that is what finally worked. I doubt it is worth your time to dig into it or explain it to me unless it is something obvious. But if there is a kind of "why didn't he simply do it this way" solution, which doesn't take you time to think about, I would be thankful for the guidance.


RE: New Game - Netted but inefficient and buggy... - Eric Piette - 06-21-2021

Hi,

For 1) Yes I had fixed the previous problem, so the one you were referring to was already fixed. However, I saw a bunch of other small problems about out of bounds when moves or check were done on the edges (the edges are the latest feature added for the graph and we do not have a lot of games on them, so that's always cool to find bugs about them and fix them, thanks for that). So, now I do not know for your game, but running playouts on it do not create any problem. That will be in the next release (maybe end of this week).

2) Yes, I am going to fix that.

3) I prefer to let you looking about it with less bugs about edge in the next version. However, maybe if you use other ludemes, you will find some other bugs about using edge. So please post here the future .lud creating with the next version with any exceptions triggered because of the edges.

Regards,
Eric


RE: New Game - Netted but inefficient and buggy... - dale walton - 06-21-2021

Thanks.
OK, so even if it works, I'll give another try at simplifying it a bit, and tell you what happens.


RE: New Game - Netted but inefficient and buggy... - dale walton - 07-02-2021

As requested, here is the latest version and three trials showing the wrong incident edges were chosen for the 3 possible directions.

I think this is an error on your side, rather than the script, as for each direction the diagonal are added with the same offset for each placement where they occur.


RE: New Game - Netted but inefficient and buggy... - dale walton - 07-04-2021

Re the above post.  I found the problem(s): it is a problem with (intersection ... )

I updated the file using the following define for placing the edge diagonals:



(define "HalfWayEdge"

(min

  (difference

  (array (sites Incident Edge of:Cell at:(regionSite ("SharedCells") index:0)))

  (difference

    (array (sites Incident Edge of:Cell at:(regionSite ("SharedCells") index:0)))

    (array (sites Incident Edge of:Cell at:(regionSite ("SharedCells") index:1)))

))))



Insetead of this old one which doesn't work (intersection for arrays might be giving a union result instead?) meaning that (min finds the lowest of all, instead of the lowest of one value)


(define "HalfWayEdge"

(min

  (intersection

  (array (sites Incident Edge of:Cell at:(regionSite ("SharedCells") index:0)))

  (array (sites Incident Edge of:Cell at:(regionSite ("SharedCells") index:1)))

)))



(define "SharedCells"

(intersection

  (sites Around Cell (last To) Orthogonal)

  (sites Around Cell (value) Orthogonal)

))



I used (min ...) to convert the result to an integer for the compiler because without it the script would not compile even though there is only one result (try removing it from the one that works to prove this)



I used (array ...) because I got

Unexpected syntax '(sites Incident Edge ...' in 'at:(intersection (sites Incid...'.

or

Unexpected syntax '(sites Incident Edge ...' in 'at:(difference (sites Inciden...'.



without it, but I don't know why that makes a difference. if (array ...) can understand the syntax, why can't (difference for regions or (intersection for regions understand it?



I use (value) in "SharedCells" to pass the integer into the middle of the processing of region functions.



------------------------------------
There is a separate bug:


This part of the script has a separate bug annotated in the comments in the script:

I have included netted not OK4.trl to illustrate the un desired effects - The Northerly diagonal connection is doubled instead of single, and the Southerly diagonal connection is doubled with its 2 levels in different states as well. Most of the time the script works correctly, but it fails when an orthogonal connector ("I" piece) is removed on the same placement.



(define "AddDiagonalMarkers"

// possible bug here:

// in "netted not OK4.trl" seems values from results were not unique

// or the remainder was performed twice for some other reason...

// happens specifically when an orthogonal has been removed at the placement site (last To) as well

// unaffected by absence of presence of count:2 in the removal.

// additionally some times the state is updated for the entire edge

// and sometimes the state is updated for level 0 of the edge.

// I need the state to update specifically the one edge added the given edge sites.



(forEach Value

  (results

  from:(last To)

  to:(sites Around Cell (from) Diagonal

    if:(and

    (= (id "Ball" Mover) (what at:(to)))

    (not

      (is Within

      (id "Ball" Mover)

      in:(intersection

        (sites Around Cell (from) Orthogonal)

        (sites Around Cell (to) Orthogonal)

  )))))

  (to)

  )

  (and

  (add

    (piece (id "I" Mover))

    (to Edge ("HalfWayEdge"))

  )

  (set State Edge

    at:("HalfWayEdge")

    level:(topLevel at:("HalfWayEdge"))

    ("D" (last To) (value))

))))