+- Ludii Forum (https://ludii.games/forums)
+-- Forum: Questions (https://ludii.games/forums/forumdisplay.php?fid=13)
+--- Forum: About the Ludii Grammar (https://ludii.games/forums/forumdisplay.php?fid=15)
+--- Thread: Writing more efficient game descriptions (/showthread.php?tid=366)
Writing more efficient game descriptions - Michael - 01-14-2021
I'm having trouble with a very slow game. On my computer it takes about 3 minutes to make a single move. I'm pretty sure this is because I have had to work around the lack of a native solution to working with large pieces on "strange" boards, but I'm hoping there might be some way of speeding this up. I don't know how to proceed. Any tips?
The problem definitely has to do with the boolean in the if-clause in (to) and (from), and especially with its use in ("UnClaimable"). But is there a more efficient way of doing this?
Edit: Perhaps I should explain how the game works.. It is played on a rhombus-tiling with hexagonal pieces that each cover three mutually adjacent rhombuses. Since Ludii cannot handle this kind of large piece, I had to come up with my own interface. This is how it works: To place a piece you select one of the rhombuses it will cover, then you select one of the other rhombuses it will cover. The third one is determined by those two choices.
This is the rule that creates trouble: You score 1 point every time your placement causes an odd number of empty sites to be (i) adjacent to the same number of friendly and enemy stones, and (ii) adjacent to no site wich can be occupied on a future turn.
RE: Writing more efficient game descriptions - MatthewStephenson - 01-15-2021
Hi Michael,
The primary cause of the slowdown was due to some unoptimised code we had when verifying legal moves.
This has now been fixed, and your game should run much faster in the next Ludii release.
Cheers,
Matthew
RE: Writing more efficient game descriptions - Michael - 01-15-2021
Exciting! I'm looking forward to it :) Hopefully, it will allow me to keep a running score in this game, which will be even more computationally demanding.