Users of this forum came up with some interesting Go variants which currently can’t be played on any server. Would anyone be interested in helping to change that?
We could enhance a server that already exists or build something new. I’d be open to both approaches.
Existing servers:
Variants lacking a server:
Yeah I’d be interested 
Seems like VGS is the obvious choice if looking to extend an existing project. But @seequ recently mentioned part of it is not in a buildable state so that poses an issue
I’ve made a wiki out of my first post to gather some information about variants and servers. Feel free to extend or change it.
One thing to note with VGS is that the server is actually very easy to interface with. There’s even some prior work with integrating katago (ask @sanderl). This means that even if no one wants to salvage the existing client, a determined developer could write a completely new one and make it support whatever subset of variants you want to see.
Almost a year ago a friend of mine and I started a webassembly project for playing fractional multicolour go online. It lacks important features such as user management and a database and is far from finished. But it is open-source and the code can maybe be re-used, too.
We had also plans to integrate generalised pyramid scoring
Anyway I am interested in contributing to a community project for go variants
I would like to point out that the DipGo server uses sequential moves (for now). The variant that we proposed and played here on these forums had simultaneous moves.
Great that there’s some interest. 
One thing to think of is what possibilities to add variants should be provided.
I think some stuff could be changed via config files or something similar. For example an easy method to define the move sequence would help with a lot of variants.
Standard: 1,2,1,2,…
Pair go: 1,2,3,4,1,2,3,4,…
Thue-Morse: 1,2,2,1,2,1,1,2,…
Sequential multiplayer: 1,…,n,1,…,n,…
Parallel multiplayer: (1,…,n),(1,…,n),…
But that could also be: (1,3,5),(2,4,6),(1,3,5),(2,4,6),…
Now defining those sequences by generating them and providing them as input would be one way to go and would be sufficient in a lot of cases. Providing functions (to create the sequences) as input would be more flexible, but also more complicated to implement.
Now I think I’ve seen the concept of a move sequence in Variant Go Server and Fractional Go Server, but I didn’t check how those are implemented.
AFAICT, they both support cycling through a list of players, like in your “Standard” and “Sequential Multiplayer”, but not the parallel or T-M ones.
I’ve just thought of something else to consider: Sometimes during the game the move sequence may change, like when a player gets eliminated in battle royale.
Do we want to support non-rectangular board patterns?
In that case I would suggest a data structure along the lines of
“a board has a list of intersections”
“an intersection has a list of intersections (neighbours)”
… then we could for example use a bunch of code from the Fractional Go Server to generate boards of (what we called) “polygonal” pattern (don’t ask why) of different sizes.
An advantage is that you can create various kinds of patterns. A disadvantage is that from this structure alone, it is not clear how to display the board (we solved this by storing a bunch of data inside each intersection, like a coordinate vector etc.)
Yes please! Those polygonal boards sound awesome!
Also 3-D/4-D variants would be cool (although maybe UI is too hard)
I’d want that, yes.
And the question what we want is an important one in general. I think it would be good to at least consider stuff that someone wants, even if others are not interested, to build something that is flexible.
There are pretty mature graph drawing libraries out there…
Here’s a 9x9 board as drawn by GraphViz, not exactly a go board, but playable 
I’m not saying we should visualize stuff this way, just that we have something to fall back on if the board state is represented as a graph.
Yeah I suspect that non-planar graphs will be tricky to visualise.
For planar graphs it’s not a big problem, I think. For example we can compute coordinates for intersections (different from the usual goban coordinates) for the purpose of positioning them nicely.
How about supporting multiple classes of stones (i.e., different types of stones with varying capabilities)? Or radically different winning objectives, like the capture of a special type of stone?
I legit think implementing chess would be a good test of the extensibility of the project haha
Okay I think the big question for me is how do we start?
Like are we doing “green field” or extending an existing project?
If green field, what tech stack? One theme I saw in the existing projects was that there needs to be a way to share code between client and server bc of all the rulesets and whatnot. That could be a good reason to do a node.js server, but compiling to webasm works too.
If existing, would it be a fork? I think it’d be nice for everyone who’s contributing to have push-to-main priviledges (at least at first)
