-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow More Board Types for Some Variants #158
Comments
Note: I wrote group_utils in a way that it doesn't depend directly on Re: what to do with old code: I'll try not to be too attached to Grid, but in addition to |
Noted. It's not just about the code though, it's also about old games and configs. Although it wouldn't be too bad to drop all games at this point. |
In fact, I've got a |
IMO it's good to keep the grid configs around.. It's a lot easier to grep { width: 9, height: 9 } than a list of 81 nodes and 144 edges |
I think a Board Interface / Abstract class sounds nice. |
What
Looking at our currently supported Go variants, there are only a few which don't work with a graph-like board right away:
But other ones could be easily played with graph-like boards in theory, yet they can't, because they extend the
Baduk
variant, which only allows grid boards:It would be nice, if we allowed those variants to be played on other boards too.
How
But there are different ways to achieve this:
Board
interface or abstract class, that ensures the necessary functionalities (detecting chains, etc.) are implemented, but allow different implementationsDepending on how it's done, we might have to think about what we do with the current implementations. Do we keep them?
The text was updated successfully, but these errors were encountered: