Closed Blizihguh closed 1 year ago
Not sure if Luvit/Discordia has any built-in locking mechanism. Doing something homebrew would probably work, although it might be pretty janky. Maybe it would be better to do something like keeping a running round count, caching it at the start of checkForEnd, passing it into loadGame, and only loading a new game if the current round number is the same as the cached one. This is still a race condition, but I expect it to be a lot tighter than the current race condition.
Turns out Discordia does have built-in locking (libs/utils/Mutex.lua). So this should be pretty easy to solve: just yield the coroutine if the game state lock is currently held.
Fixed in commit f75c692ffa5d087629470be73f4113ec4676f786 :) Testing this was a little tricky; I ended up doing two passes:
When two people both click at the same time, and both clicks would end the game, it's possible to have two conflicting wins at the same time. This was fine before, when two players clicking at the same time was basically equivalent to two players pointing at the same time in real life -- the game is a wash and it's impossible to say who really won. But now that #28 has been implemented, this can result in two rounds being dealt at the same time, which is bad. Some kind lock is probably necessary specifically for dealing out a new round (but multiple wins is still fine).