Bill Taylor invented a version of hex which can be played on the projective plane, in around 2001. Essentially this is a version of hex on a board which "wraps around", where the goal is to basically to connect a piece to it's wrapped-around version, like so (orange has won here):
I've written a demo implementation of projective hex (pictured above), where the board can be scrolled around. The original game used a fixed hexagonal board, which is not equivalent to this board (this board is a bit more symetrical). I think the ability to scroll around might make it a easier to understand local positions, since the representation of the game in two dimensions necessarily distorts some parts of the board. This implementation is really just a UI demo, but I'd be interested to know people's thoughts on the game.
(In topological terms, the object of the game is to form a non-trivial loop in the projective plane. Like in hex, it's mathematically guaranteed that by filling in the board, exactly one player will win.)
First observation: the board contains several pentagons instead of hexagons. This changes the game more deeply than the wrapping around a globe. Compare this with the difference between the game of Y and the variation Bent-Y: http://www.trmph.com/hexwiki/Y.html I like to play Bent-Y, because the board behaves elusively different. It was designed bij Titus and Shensted to reduce the impact of the center move.
Second observation: as every single cell of the board becomes a center cell, there is no possibility to imply the swap-rule anymore. Any move would be swapped and the swapping player would always have an important advantage.
I see Bill Taylor suggests a three move swap-rule: Black-white-black and then choose.
Third observation: I kind of get lost on the board. Moving the board makes the direction of play even more obfuscating. But for sure it is spectacular!! In Toroïdal Go, which is based on the same wrapping idea, the edges have a different color. So you know which moves will become doubled on the visual board.
Regarding the pentagons: I definitely agree it will change the gameplay, although I haven't quite worked out how (it changes ladders going through the pentagon, for one). It's actually impossible to tile the projective plane with only hexagons, since it has Euler characteristic 1. Bill Taylor suggested variants with 6 pentagons or 3 squares; this one has 6 pentagons as well, though differently arranged.
For idea (1), this representation is actually a stereographic projection of the sphere representation you suggest. It probably wouldn't be too difficult to adapt the code to optionally render a 3d sphere instead - I might try it this weekend.
For idea (2) (shading the cell being moused over, and it's duplicate), I really like this suggestion. I'll implement it later today.
Some other comments:
# Unlike a torus, when you go around the projective plane, left and right become flipped. This is maybe a bit unintuitive. However there's no obvious "right" winning condition for other closed manifolds like the torus or sphere.
# Currently links created using "Share board" as in Tony's comment are not permanent. The server has no database (it's like 100 lines of python I threw together), so when it shuts down, all the data is lost. I'll try to implement TRMPH style links to board positions, where the board position is encoded in the URL, maybe today or whenever I have time.
Another idea is to allow the board size to be selected. (The smallest board would be the dodecahedron modulo an involution, a.k.a. the Peterson graph.) It would be interesting to solve the game completely on small boards. I suspect that for the first several (smallest) board sizes, any first move is a win. Are all first moves a win on very large boards? In order for the three move swap rule to work, it must be the case that there exist first moves such that for all subsequent second moves there exist both winning and losing third moves. If that is true, the presumably for large boards choosing a third move near the dividing line between the winning and losing third moves results in an approximately even game.
Yep, allowing to select board size is on my todo list. It would be interesting to implement a solver but I'm not sure when/if I'll get around to that.
I'm not sure what you mean about the 3-move swap rule. The way I interpreted it, the first player plays all 3 moves, then the second player splits. In this case, it seems like there only needs to exist a first move such that there *exists* a second move such that there are winning and losing third moves?
Perhaps I misunderstood the 3-move swap rule proposal. I assumed the 2nd player would choose the 2nd move. But your interpretation seems like a better rule.
It's a fascinating idea, and an amazing demo, but I'm not sure if 3 move EQ will be enough on this small grid which I call order 6, the number of distinct pentagons. It might be a more fair game on a larger grid. One could always increase the opening protocol complexity still further with 5 move equalization, but that sounds like a major kludge to me.
I believe, by either an euler argument, or by the fact that this is, in some sense, a hex-tiling of a dodecahedron, that there will always be 6 distinct pentagons.
The order should be the distance between "adjacent" pentagons. In this case, order 4.
There are actually two separate families of boards with dodecahedral/icosahedral symmetry. As William Fraser points out, they all have 6 pentagons. The number of hexagons in the first family starts out as 0, 15, 40, 75,... and in general is 5*n^2 - 5. The number of hexagons in the second family starts out as 10, 55, 130, ... and in general is 15*n^2 - 5. The board in the current implementation uses the first family with n = 6.
The smallest member of the first family is the projectivized dodecahedron. The smallest member of the second family is the projectivized truncated icosahedron.
Update: I added the option to change the board size. Numbering is as William suggests - the previously used size is 4, minimum is 0 (rendering for size 0 is a little buggy right now). Incidentally, 4 has a similar number of cells to 11x11 hex, 5 to 13x13, and 7 to 18x18.
So one player is playing around the cylinder (making a circle) and the other is playing top to bottom. Even if there is just 3 spaces around the cylinder, the player playing top to bottom can win for arbitrary heights.
Castro_bot: interesting, it looks like Renkula! is a reinvention of Projex (it's exactly the same game, just a different representation). I like the semi-transparent sphere idea.
The UI is just javascript, rendering using an HTML canvas. Well actually I used flow for typechecking, but it's basically javascript.
Have you posted the non-compiled/obfuscated source code anywhere (eg github)? I'd be interested to check it out. Or hey, if you'd like to collaborate, it'd be cool to have a front end that connects nicely to hex, havannah, etc. I'd be interested in changing my program to play Renkula/Projex as well.
Castro_bot: I haven't posted the source code currently. I've been intending to clean it up and put it on github. I'll post it in the next week or so whatever state it's in.
What do you mean by "front end"? Like a desktop program? I am potentially interested in making better tools for these type of games, e.g. recently I've been working on a web-based game record editor for hex (http://gwylim.net/hexeditor).
Hi Gwylim, I tried your hexeditor: http://gwylim.net/hexeditor Nice work! Maybe, if you want to get more feedback on improvements, you could start a new topic about this editor? As this topic was about Projex. In Trmph's hex editor I miss a load from and save to sgf option. Your editor has this option, although I could not get it to work yet. I could not load any sgf-file. Further I did not expect blue (in LG) to become white in the editor. A numbered grid and the option to toggle move numbers on and off would be great options too, which Trmph does not offer yet. Hold on!
Hi Tony, thanks for the feedback. This tool is currently incomplete, and the SGF generated doesn't conform to the standard (but it *should* be able to load SGF generated by this tool, could be a browser compatibility issue if not). I'll post a new topic after I've done some more work on it. I'll also add the grid letters/numbers, thanks for the suggestion!
Little Golem