Spherical Worlds

#1 R&C had spherical worlds? Hmm... I must not have noticed.

I'm not sure exactly, though. I haven't tried anything quite like it. While I'm sure that with scores of programmers, you could do it, but if you "rounded" it within the mission specifications, wouldn't that give the desired effect (unless you want to be able to run around the entire world).

#2 Theo, I've never tried to implement anything like this, but I have given it a great deal of thought.

I'd say that, for starters, transforming the vectors and coordinates for every object in the game - based upon it's location within the world and the orientation of the ground plane at that location would be a nightmare.

Not just to code, but on performance as well.

~ It's just a theory though. (C;

#3 You would have to modify every physics calculation that involves gravity, to redirect it to the center of your "planet". You'd also need to modify the physics of various controllable objects so that they reorient themselves based on the direction of gravity. Then you'd just remove the terrain from a mission, add in a set of difs that circles your attraction point.

I seem to remember some marble blast levels that used triggers ( powerups ) to modify the direction of gravity. It'd take some 3d math work, but nothing really too complex, to roll your own from the existing physics.

#4 @David
Come to think of it, they might have been introduced in R&C2. *Most* of the levels weren't spherical, but some of them (mostly the 'Giant Clank' levels) were. R&C3 did more with it, and they were more involved (real levels, rather than just a quick challenge you had to beat to continue).

@Kirby
Yeah, most likely a performance hit (an extra transform for every object in the world (except the 'terrain' objects), but I figure if it can be handled with the computing resources available to PS2 developers, it can be handled with what'll be a normal computer by the time I'm done. :)

@Paul
Sounds like what I had expected. Of course, my need for round planets is a few development milestones away. What I *really* want to do in the end is to dynamically generate those round worlds (you can do some pretty neat stuff with pseudo-random number generation), but I know that's quite a bit of custom code away, and wouldn't even be an issue until I got the gravity code changes figured out.


I'm currently planning a space-sim game where you can run just about any combat station in a space fleet, (including boarding party, fighter-pilot, gunner, starship pilot, and ground-forces). I've broken the development down into a chain of 'playable' milestones starting with fighters, working up to starships, then including planets (and star systems), and eventually ground combat. It's pretty important to be able to have round worlds when you can see the whole thing, and you might want/need to interact with it.

(Before I get the standard 'Do you have any idea how much work that would all be?' responses, the answer is, "Yes, and I'm planning to spend the next few years working at it, that's why I'm spending so much time up front figuring out what I need to do to get it done.")

#5 Just a quick note Theo,
if you do go and change all the physics code to use a more flexible gravity vector,
you might want to not assume all you want is a spherical world.
instead just have some function which returns the gravity vector for any point in space.

that way you can deal with spheres, traditional infinite plains, and possibly more exotic things like wormholes or what have you.


ie

getGravity(pos)
  {
  
  if (plain old infinite plane where "up" is positive Y:)
    grav = vec(0, -1, 0);

  else if (sphere centered at 0,0,0)
    {
    dist  = pos.length();
    grav  = pos.normalized() * -1;
    grav /= (dist * dist);
    }

  else if (wormhole)
    {
    // who knows ?
    }

  else if (giant cube?)
    {
    // who knows ?
    }


  // optional:
  grav *= gravityConstant; // approximately 9.8 (meters per second per second)
   
  return grav;
  }

#6 @Orion
Oh yeah. Definitely. I'll probably break out the gravity vector from the accelleration, though. And for sanity's sake, I'll limit gravity to a single source as well. (That 'multiple body' problem is hairy in 2D, I can only imagine how much worse it is in 3D.)

#7 Well it's only hairy if your significant gravity sources are affected by gravity.

like, you don't really need to figure in the pull the spaceship has on the planet, unless you really want to.

#8 I did exactly this less then 3 months ago. It took more then a month. It was incredibly tedious, and required everything from transforming gravity, to storing a y axis directional vector. I also had to alter the way the OrthoBoxConvex returned distance dot products (faceDot) ... The entire Player class was coded on the assumption that straight up the z axis is always up for the player.

If you are serious about doing this, just remember that it is probably going to take you about a month (if you are a good coder) . The player class is a beast.

#9 @Chris
Good to know its been done (successfully) before. Did you actually mean the z axis, though? I thought that the Y-axis was typically up/down, and Z was typically towards/away from the screen. If you *did* mean z-axis, that's a good thing to know going in!

#10 Yes, generally Z axis is in and out of the screen, but not in torque. It is up and down.

You will see it when you start messing in the engine. There are code comments all over hte place about z being static and what not.

#11 Some links about TSE's Atlas terrain engine:

Ben Garney's .plan
Snapshot

Multiple Atlas terrain blocks, as well as TSE water blocks, can be positioned and rotated arbitrarily - so you could make a huge spherical terrain.

#12 Dang that's a nice feature. Just that is worth the $150 for the early-adopter license. (Hope I can scrape it together before EA expires.)

Anybody know if it handles triangular terrain blocks? (You can't actually make a closed shape other than rectangular solids with rectangular side pieces.) Maybe drop the height-map to minimum level on the diagonal?

#13 B.G.'s Atlas can also technically do a spherical terrain alone.

#14 @Mike
Obviously I'm missing something from what I've seen of the Atlas stuff. How can it do sperical terrain alone?

#15 You can make multiple terrains, and rotate them and what not.... but the player will still act like normal.... You can't walk on the spherical world... You can just make a terrain sphere.

#16 @Chris
But the only way to get a closed shape with rectangles is to have 6 sides, which limits the terrain effects you can get. Each side being a height map would mean that the terrain near the edges would be extending away from each other at a 90 degree angle, so only low terrain would maintain the spherical world look, and any peaks near the edges would end up as overhangs.

Technically, any closed solid would have the same issues, but with triangle-based shapes, you can get much 'flatter' transitions between the sections, so it wouldn't be nearly as noticable.

#17 I helped Chris with some of his problems during that month.

He is correct in stating the problems lie in the many many changes required to the player class to make walking on walls / upside down work.

#18 Wouldn't it be better if we changed the code to correctly implement gravitational fields as described by Einstein et al. + Mach's views ? What I mean is to make gravity based on mass... i.e. the spherical world (the largest mass in the game's world) would directly affect the player via it's gravitational field inside spacetime.

The engine could ignore objects that would result in trivial gravitational fields (force) on the player and other objects. (These objects would either be too small or too far away to have any affect on the objects in question.)

This way, you could have multiple "planets" (spherical terrains) in a universe, without having to change the code for each individual terrain block.

For anyone who doesn't really know physics, the further away an object is, the less the gravitational field is affecting the player ( or any other object for that matter). Therefore a distant planet (planet B) would be applying gravity to your player on planet A, yet the gravity is so little it can be ignored until the player is closer to planet B (i.e. in it's orbit, and on the surface).

Thoughts?

#19 @Thomas
I'm planning on limiting gravity to being produced by stars, planets and moons, and only out to a distance defined by a minimum force threshold (some fraction of a G), but I do want it to be something that has to be taken into account while piloting a ship, or firing a mass-driver weapon. I really like the idea of a skillful player being able to 'orbit' a shot at somebody, and these are the 'big guns' on capital ships in my design. (Sort of like chucking a VW Bug towards your enemy at 1/10 the speed of light.)

The first playable iteration isn't going to have any of these features, though. The first thing I'll be playing with is zero-G maneuvering of small ships (fighters). It's going to be pretty 'hands-on', because I'm aiming for an accurate physics model rather than an 'airplanes in space' feel. (Think Battlestar Galactica, rather than Star Wars.)

#20 Sounds good, just remember that fun should take precedence over realism. Just because the physics are real, doesn't make it fun or interesting. There has to be a careful balance. Or maybe have different settings for realism, such as what you described. People are obviously more familiar with atmospheric flight, than space flight. But saying that is an opinion. I would much rather see space flight in space and vice versa. Also you might want to think about the type of technology that these spaceships would have. Regardless of how skilled a pilot may be, they are not going to be able to calculate the gravitational forces of a planet, and adjust accordingly, they will have a targeting computer that would calculate that at much higher and faster accuracy than they could do. I say let the player fly and shoot, and let the targeting computer say when you have a lock, based off of current flight direction and gravitational forces. This way people won't get frusterated when they lauch ther vw bug at the other capital ship.