So me and a teammate were thinking about how to make a game where you are in a solar system and can fly around planet to planet but also walk on the surface FPS style, and do all of this without too many loading screens.

If there was a loading screen from being in space to being on a planet we could just do our world maps Final Fantasy style. You have a giant flat plane as the map and you warp around the edges as if you went around the world.



The mapping itself would be done like you would for any other game that is a large out door environment. Think Crysis or Battlefield. It will work a bit more like GTA or Elder Scrolls where chunks of the world load in depending on where you are.

The problem is this isn't how it actually works. If you can fly with a space ship from anywhere in space to the surface the coordinates need to be spherical like. If our world map was designed like above it would take just as long to walk around on the south pole as it does on the equator, but in reality if you are close to the pole you are walking in a MUCH smaller diameter.

A more accurate map design is something projected like this:


This is realistic but creates spatial discontinuity in the map.

I want mapping of worlds to work just like other video games where everything is flat and doesn't account for a spherical planet surface. I want the mappers to concentrate on making solid indoor areas and outdoor areas without silly things like spherical projections and the warping it would create on the things they place in the environment.

When you are far down on a planet surface everything seems flat anyway so it's a good approximation and doesn't require a more complicated physics engine or mapping process.

We thought of a bunch of crazy ways where we can combine spheres with 2D mapped parts of the world. The best would be to cube map the world. Just have each side of the planet be a face of the cube. Sphere to world coordinates would be a bit distorted but it's a video game so it's OK.


The only problem is the red parts. How does walking between the "flap" sides of the cube work? Sure you can warp the player around a bit but what happens when you are right at the corners? I can't think of a good way to handle that. It needs to both render correctly and the physics need to work out without crazy hax. If anyone has good ideas of how to handle this case, this is hands down the best method!!! We can map the entire planet this way.

The other thing we thought of is to have parts of the planet be mapped and the rest is just flat barren land or water that you fly over.



The sphere on the right shows how slices of it are taken out to leave flat planes. The smallest circle possible is created that contains a rectangular map. The white gird lines project on to the same white grid lines on to the sphere on the left. So where you are in the 2D slice represents your spherical position.

The black grid lines are basically the map data. Areas outside of the map are walkable on but it'll be flat plane as far as the eye can see. Everything will basically be projected on to an infinite 2D plane with barren flatland in between.

There are many projections one can use to make a map of a sphere.

Designing relatively small spaces (say, a city) as if they were flat and then dropping them on the planet shouldn't look too bad, no matter how you do it.

Internally, I think the easiest thing to do is to represent everything (including physics) in 3d. If you want your mapping tools to work in "2d" or "2.5d," you'd just need a postprocess that generates the 3d geometry (I'm picturing a workflow that involves a "map compilation" step).

Yeah everything is 3D. It just would be the same as all other 3D game engines, pretending the world is flat. Gravity is always down and not pointing at the center of a spherical planet.

Yeah everything is 3D. It just would be the same as all other 3D game engines, pretending the world is flat. Gravity is always down and not pointing at the center of a spherical planet.

I understand everything except the "Yeah": What you are saying is precisely the opposite of what Emergent was proposing.

[quote name='ill' timestamp='1321325062' post='4884030']
Yeah everything is 3D. It just would be the same as all other 3D game engines, pretending the world is flat. Gravity is always down and not pointing at the center of a spherical planet.

I understand everything except the "Yeah": What you are saying is precisely the opposite of what Emergent was proposing.
[/quote]

Heh OK. Well the thing I really don't want to do is actually model the round world because creating buildings and roads and cities would be a bit of a nightmare. The physics would be complicated too. I've tried to do this in 2D before and it was hard. PhysX doesn't even support this and my engine currently uses PhysX. And I definitely don't think writing my own physics engine is a good idea given how complicated the whole concept is already. Writing a physics engine as good as PhysX is basically like writing OpenGL from scratch.

Will your guy be able to run all around the whole planet in quite a short time?
Is he a giant?

If you land on a planet, you probably should have some kind of level of detail choice, where you change from the "planet model" (wich is round) to the "surface model" (which is flat).
Remember that planets are usually huge in relation to whoever is running around on them. (unless you're in mario galaxy)

Going from space to landing on a planet is a pretty huge scale change though, and isn't trivial to make it look good all the way down. (if you're going for realism)

You don't have to have loading screens just because you change some or all of the models, its just more tricky to implement seamlessly, and if it isn't strictly necessary for the game (which it usually isn't, more of a special effect) you can live with a loading screen.

Are you sure PhysX can't do this? I should start out by letting you know that I've never used PhysX before, but from a minute or two of Googling, it looks like, out-of-the-box, you can use RB_RadialForceActor to do a linear approximation to an inverse square field (which should be fine, given how small you are relative to the planet), and, if you're just a little more ambitious, you can implement a custom "force field kernel" (PhysX jargon, apparently). That seems to be what this forum post is about (It doesn't look like they've been successful yet, but it also doesn't look unrealistically hard.)

It also suspect pretty strongly that you could start out using RB_RadialForceActor, and later, if you decide to be perfectionistic, figure out how to do a real inverse square field, and that this replacement would just "drop in" to your code without requiring other changes.

Others with PhysX-specific experience can probably help you more from here on out.