How to create a non-square 2D grid with spherical topology. When programming Conway's Game of life on my computer. A problem arises; how to deal with the borders on the board? Do the cells at the border have to take into consideration less neighbours than the cells on the inside of the board? That creates unwanted effects at the edge of the board (as if the rules of the game changed there). Another possibility is to make an infinite board, but programming this seems complicated in many ways.
The solution? Sticking toghether the opposite sides of the board so that things seem to teleport to the other side when faced with the problem of interacting with one edge (a typicall approach for many similar games). This is topologically equivalent to a Torus as far as I understand. Whose fundamental polygon is

Then I played a little with different topologies. I've been able to create Conway's Game of Life with Klein Bottle topology and then with the Real Proyective plane topology. But there's one final topology I want to examine and is the Sphere. Surprisingly the Sphere is becoming more and more difficult to wrap my head around so I ask you for help.
According to the Fundamental polygon of a Sphere I should glue together the top side of the board with the left side, and the bottom side with the right side.

But I want my board on Game of Life to be non-square (the grid of cells not having the same number of rows and columns). This wasn't a problem in the other topologies because I was gluing together sides with the same lenght, but now things are more complicated. One solution would be to stretch/contract one of the sides to accomodate the other before gluing them. But how could I do that with a discrete subdivision of space (like in a board of cells)? If I make on cell bigger/smaller then how I define its neighbours now? I could create/destroy some cells so that the number of cells in one side matched the other I have to glue together, but then there would be cells without any role in the game or cells that interact to much with the neighbours, and what rules do I implement for that decission exactly? So I'm stuck here, I want to see a glider move across the board regularly without been destroyed or transformed just at the edges because I didn't implemented a sphere topology correctly, without imposing a square grid in particular. What should I do?
 A: If you're trying to map a cellular automaton defined on a regular flat lattice onto a sphere, you're always going to have some "defective" points where the lattice looks locally different somehow, e.g. by a cell having an abnormal number of neighbors or by the neighborhoods overlapping in an unusual way.
Mathematically, this is because the total angular defect of a sphere (or any convex polyhedron) is 2 full circles (i.e. $4\pi$ radians or 720°), while that of a torus or an infinite plain is zero.
For a rectangular 8-neighbor lattice, as in Conway's game of life, probably about the best you can do is take six square grids and build a cube out of them (which you can then stretch into a geometric sphere if you like).  This'll give you eight defects at the eight corners of the cube.  Depending on how you connect the grids together at their edges, those defects can be of (at least) two types:

*

*If the corner is in the middle of a cell, then that cell will only have six neighbors instead of the usual eight.

*If the corner is between cells, then at each corner you'll have three cells that each have only seven neighbors instead of the usual eight.*

Either way, the unusual neighborhood size in itself won't have a major effect on Conway's game of life: any cell with more than three live neighbors will die anyway.  What will affect the behavior of the CA, however, is the unusual local connectivity of the grid near the corners.  This can allow the corners to support non-standard stable or oscillating patterns that would not be stable elsewhere on the lattice, and can also destroy any gliders or other moving patterns that hit one of the corners.
For example, a basic glider in Conway's GoL will travel in a straight line along a diagonal of the lattice.  But at a corner of a cube, three diagonals join together, and there's no way for a glider arriving straight at the corner along one of those diagonals to continue straight ahead — it'd have to continue along an edge of the cube, but that's impossible, since that's an orthogonal direction on the lattice!
Also, even if no glider directly hits the corner, strange things can happen in their vicinity.  For example, it's possible for two gliders initially moving on parallel paths to pass a corner on opposite sides, turn in opposite directions and collide — something that could never happen on a flat torus or on an infinite plane.
*) If you like, you can also consistently count each of the three corner cells as its own missing diagonal neighbor, but at least for Conway's GoL that's likely to be even more disruptive than just leaving that neighbor uncounted.
A: Edit: This answer is wrong, as pointed out in the comments. I'm leaving it here so that others don't make the same mistake.
Very interesting question! One idea that springs to mind would be to have two different grids of the same dimensions, representing hemispheres, and identify the edges of the grids in the obvious way. Thus we realise the sphere as a quotient space of two disjoint squares, instead of a single polygon. 
Obviously this isn't ideal, since it would no longer look like one grid, but it would at least give a spherical topology. 
A: What I think that you are looking for is the Hexagonal sphere:

There is an explanation on Red Blob Games about this tiling.
There's a note on glider-rules by Carter Bays: A Note on the Game of Life in Hexagonal and
Pentagonal Tessellations on the Wolfram site.
What I suggest you should do first, is to make a $2$D-version on a hexagonal-grid and make the wraparound work. You don't need to worry about $3$D, since this grid will be like a projected "texture-map" on a treesphere in the $3$D-space. E.g. every point in the hexagon can be projected on to the sphere. 
