The game is 2d and overhead. The player can walk around and scroll the map arbitrarily. (practically the cardinal and ordinal directions, via arrows or WASD)

It's easy to do this if the world, logically is a torus. But if it's a sphere it seems more complex.

I've found resources aimed at representing a spherical world in a 3D game, but since this is 2d and directly overhead.

Is there any way to do this without having to represent the world as a real sphere and then sliding around on it with some sort of square subset of it? And it seems like even this would run into some issues along the edges and really throughout the whole square slice that gets more stretched the further you are from the center of the screen.

Not really... say that you're at the equator and walk left and right.. easy..

Then imagine walking straight up until you reach the pole, and then turning right. Do you want the player to walk "right" as in along the longitude, basically having the same tile repeat itself over the entire visible area, or do you want the player to walk "right" as in walking south along the latitude back towards the equator?

The problem with turning towards the equator is that "up" won't always be "north". If you walk up from the equator to the north pole, then turn right and walk back down to the equator, and then turn right again and continue right until you reach the original position where you started to walk "up", that direction (north) will now be to the right, not up.

I think the easiest solution would be representing the world as a real sphere, though I guess every time you scroll up/down or left/right you could dynamically map the new row or column of tiles that should scroll into view to a part of the sphere and then create the actual tiles as a 2D row/column instead of 3D. But again, they would not always have the same left/right orientation.

It is a classic topology problem, and no, there is no easy solution for it. Mathematically you cannot map a spherical system onto a planar system without tearing it or causing distortions of some type.

That said, there are approximations and projections that people have come to accept as normal for that sort of thing.

Look at paper maps for a prime example of it. To be flat the mapmaker will severely distort things on the edges and middle and clip off everything beyond a certain extent, or they break it up into segments with somewhat less distortion, or they project areas into circular views of a region such as a polar cap, and so on.

But I don't think you need to do any of that. I'd ask a question:

Do you REALLY need an entire globe? Does it REALLY need to be globe shaped?

I love how Civilization handled it, faking the world as a large rectangular area. That is close enough to how people imagine a map that it works for the game.

If they tried to handle it as a spherical object traveling around the polar regions could be done in a small number of moves but traveling around the equator would require many times more moves. In the real world circumference varies by latitude. It would make travel in the game that much more confusing as the shorted path becomes an arc across the surface that isn't obviously the player's 2D projection.

Games are usually not set in the real physical world. Games us approximations, they use fake scales, they use fake physics, they use fake rules, they try to make "fun" rather than making "physically accurate".

While I completely agree with Frob, you might be able to do this by having a sphere that is actually made up of polygons, and all your 2d maps are polygons. This would probably work better in a more discrete screen style game, where each screen is a rectangle, with set exits to adjoining rectangles. Except in your case, they would all be irregularly shaped, depending on the polygons used. (squares and triangles, hexagons and pentagrams, or irregularly shaped pentagrams, etc)

It would mostly all be pointless though, as the player wouldn't have a very good sense of the overall shape being spherical in a 2d game.

It would mostly all be pointless though, as the player wouldn't have a very good sense of the overall shape being spherical in a 2d game.

3/4 of the way through this sentence it clicked that this is not a viable idea. They really won't have a good sense of the world at all. And anything that doesn't end up with some absurd case where they're at poles and the map is cycling around horizontally rapidly will end up having their orientation with respect to the axis of the sphere constantly changing and there will be nothing recognizable to them.

Not really... say that you're at the equator and walk left and right.. easy..

Then imagine walking straight up until you reach the pole, and then turning right. Do you want the player to walk "right" as in along the longitude, basically having the same tile repeat itself over the entire visible area, or do you want the player to walk "right" as in walking south along the latitude back towards the equator?

The problem with turning towards the equator is that "up" won't always be "north". If you walk up from the equator to the north pole, then turn right and walk back down to the equator, and then turn right again and continue right until you reach the original position where you started to walk "up", that direction (north) will now be to the right, not up.

I think the easiest solution would be representing the world as a real sphere, though I guess every time you scroll up/down or left/right you could dynamically map the new row or column of tiles that should scroll into view to a part of the sphere and then create the actual tiles as a 2D row/column instead of 3D. But again, they would not always have the same left/right orientation.

The issue you described is the problem I was trying to describe in the OP. Your solution is probably one of the better ones but as it's essentially ugly, it helps to highlight why I'm just going to have to end up going with a torus since a sphere won't work well at all.

Thinking back a bit further in the history of my experience, I wonder if you could take inspiration from how old raycasters like Wolfenstien3D and Doom corrected the 'fish-eye' effect that results from computing ray distance from a central point, which they would then use to scale the vertical wall segment. That would produce some wierd visuals if left uncorrected, such as you would seem to be squared up to a nearby wall in the center of the screen (its floor and ceiling were flat and parallel), but as the rays marched towards the left and right extremes of the screen, the ray distance would accelerate towards infinity and cause the wall segment to shrink rapidly, pinching the floor and ceiling together.

I wrote an ASCII ray caster and had to deal with that exact case. Funny thing is the effects were so hard to interpret in ASCII that I had to convert the engine to a standard per pixel graphical raycaster to see what was going on. Wasn't aware what the phenomenon was called until years later when I started reading all of Carmack's notes on the BSPs in Doom.