Header

Montag, 23. März 2009

Ship physics

I implemented most of the ship's basic movement physics the other day. We have so-called definition files which specify the physical quantities of a given ship type, such as its mass, its size, its shape, the force of its engines and the torque the maneuvering jets apply for rotating a ship. Furthermore, we also specify the ship's maximum velocity and angular velocity. There is no physical law in classical mechanics which would limit the ships' velocity, but it we don't want them to travel too fast as a game element.

The goal now was to find a way to compute the ship's acceleration based on the forces without getting significantly faster than the specified maximum velocity. In other words, we need to modify Newton's law to take into account the maximum velocity of the ship. I spent some thought on how to modify this so that it has the properties we'd like, and this is what I came up with: In this formula, the minus sign is used if the dot product of F and v is positive, and the plus sign otherwise. In the case that the force goes into the same direction as the current velocity, the additional term will lower the total acceleration by a factor of v/vmax. Therefore, when v reached vmax, a will be zero and no additional acceleration is possible anymore. Also, when, for whatever reason, the ship gained a higher velocity than vmax, then the additional term slows it down again.

On the other side, if F points into the opposite direction of v, then we are actually deccelerating. The dot product is less than zero, so the plus sign is used. In this case, the original acceleration is increased by a factor of v/vmax. This makes decceleration from high velocities take shorter than accelerating to such a velocity. This might not be realistic, but it makes it easier to avoid collisions, so I think it's a good thing. If we didn't want this, then we could simply drop the additional term when deccelerating, and we would still have the velocity limit in place.

Another thing to note is that if the ship is travelling at maximum velocity, then changes its direction arout 90 degrees and accelerates into a direction which is perpendicular to the current one, then the dot product is zero and the second term vanishes. In that case, we allow the total velocity to become greater than vmax. This is not a problem though, because of three reasons:

1) As explained before, the ship will automatically slow down again when travelling faster than vmax.
2) To permanently travel faster than vmax, one would need to change the flight direction very often, taking a zigzag-like route. In that case however, one would be faster when travelling at vmax using the direct route anyway.
3) The effect is very small: If vmax is 20, and one turns at v=19.99, then the highest v will be v=20.05 before it gets smaller again.

For rotation, the same formula is used, with the force replaced by the torque (also specified in the definition file), the acceleration replaced by the angular acceleration, the mass replaced by the moment of inertia and the (maximum) velocity by the (maximum) angular velocity. As there is only one direction for rotation (namely around the Z axis) we don't even have the possibility of gaining more angular velocity than the maximum here.

2 Kommentare:

  1. Hm, I actually have no idea what kind of game you are trying to make here. But I wonder why the "real" space physics are so seldom implemented.

    The point is - yes, it will get more complicated. You have to keep track of velocity vectors of targets that are at large distance - because you might have to brake for minutes just for not flying right past (or into) them. But I don't think it will be too hard to find a suitable graphical representation.

    Well, just as I said, I have no idea what you're aiming for. Just a quick rant :)

    AntwortenLöschen
  2. It's supposed to be a real-time strategy game. Actually it's just a feeling of ours that the game might be better playable if there is a maximum velocity for the ships.

    I'll probably experiment with this as soon as it's halfway playable. Maybe we are wrong. But it's easier to take the limit vmax to infinity in our current approach than to introduce vmax later, I guess.

    AntwortenLöschen