Hmm... A 2D shooter based on relativistic physics? Set the speed of light to something like 50 pixels per second, centre the screen on the ship's frame-of-reference, and massage the laws of physics a bit so the end result isn't too unplayable. Sounds like a winner to me! Simon

If you hit the breaks quickly, it also won't be catching up, as both the speed of your bullet and you will be zero, but that would be nitpicking, right?

If I have a plane and a guy inside with a gun, and the plane is going 1000 km/s, and the guy shoots his gun, then the plane magically loses all velocity instantly. Because the bullet is no longer a part of the plane (but the guy has his seatbelt on), the bullet would fly back from whence it came. The whiplash would probably be a lot worse, but the bullet wouldn't go to zero speed.

As for the fictional environment - I saw that he was talking about Asteroids and a ship. So I assumed that things like instantly stopping ships could happen, therefore allowing for some weirdness of the bullets flying "backwards" through the ship if you add the velocity.

But yes I know what you're saying and I realize I was assuming a lot of constraints about the fictional environment that are not necessarily true.

If I have a plane and a guy inside with a gun, and the plane is going 1000 km/s, and the guy shoots his gun, then the plane magically loses all velocity instantly. Because the bullet is no longer a part of the plane (but the guy has his seatbelt on), the bullet would fly back from whence it came.

Well yes, I forgot to mention the speed of the bullet in my example. The plane must be traveling faster than the bullet for this particular problem to result (again, wouldn't happen in the real world, but could definitely happen in a videogame where you need to be able to see projectiles traveling onscreen).

To bring it back towards a game and the specific potential undesirable situations I'm thinking of:

You end up with a bullet going nowhere, which you probably don't want. The ship continues to drift away from the bullet, but the bullet will have the same position on the screen (given that it has no velocity at all).

You end up with the bullet flying out through the back of the ship, also something you probably don't want. Imagine if you fire 5 bullets when going that speed, then press the down arrow to hit the breaks, and watch all the bullets come out the back. If the bullets already appeared to leave the gun (the player has had the opportunity to see the bullets leave at the correct velocity) then this makes sense because the bullet velocity will continue as-is. However, if the user hasn't had a chance to see the bullets moving along their path and then stops (and say it's a very fast but not instant reduction in velocity) then you'll see all 5 bullets going out the wrong end at seemingly different speeds.

This will have the bullets appearing to travel at completely different speeds. Logically this makes sense because the ship's velocity was reducing as each bullet fired, but the user will see weirdness with 5 different bullets all fired at about the same time going completely different speeds. And in the reverse situation where the ship is accelerating as it shoots, the user will see the later bullets overtaking the first ones fired. That's especially weird for a player and could even cause gameplay problems (say you fire your freeze missile first and then your concussion missile which only works on frozen targets, and your concussion missile arrives first).

Am I making sense now? Obviously this is pretty moot because Wildern's situation is not one of the ones I'm posting, but it's a very real problem to worry about in any game with projectiles. I can think of far more games that do not add in the shooter's velocity when firing, because it is much more important to have constant bullet speed (as perceived by the user) then to have completely real physics. And with good reason, too, because as I mentioned before a bullet in the real world moves more or less instantly whereas one in a game must be visible, and therefore move very slowly. And if it's moving very slowly, then it's likely that a moving ship or player can make a large perceptible difference in the speed of the bullet, which would never happen in real life with a real bullet because I can only run 10 m/hr whereas a bullet flies 800 km/h.

Really the question is: which will look best in your game? Which aids the mechanics better?So... that is why I said in the beginning not to use the ship's velocity at all. Do I make sense yet?

PS - Have a look at these videos (only used these examples because they're ones I know of):In Super Metroid, even when running quickly the laser stays ahead of Samus. i.e. they decided to add Samus's velocity on.http://www.youtube.com/watch?v=9MIvhLSrYVkIn Megaman X, the bullets appear to go nowhere when you're going quickly, because you're overtaking them. i.e. they don't add Megaman's velocity.http://www.youtube.com/watch?v=Ckxv4ja5jkY

Hmm... A 2D shooter based on relativistic physics? Set the speed of light to something like 50 pixels per second, centre the screen on the ship's frame-of-reference, and massage the laws of physics a bit so the end result isn't too unplayable. Sounds like a winner to me! Simon

Time for a derail.

I've had a think about this before and it requires a bit of book-keeping, but should work ok. You need to keep track of the frame of reference of anything that has to make decisions: e.g. enemy ships that choose where to shoot (as opposed to random/fixed shooters), homing missiles, and the player's ship.

For each frame of reference, you need a brief history of every object in the world. Each entry in the history belongs to a timestep, and needs to identify when the information about that entry would reach the centre of the frame of reference (player/enemy/bullet/whatever). This is to make sure, for example, that a bullet shot at you at the speed of light won't be seen until it hits you.

I think the final thing needed was a mapping from the timesteps of the non-player frames of reference to the player's timesteps. This is to handle timing issues when frames of reference are accelerated relative to one-another. This could affect things like firing rates. Maybe this could be ignored? Gameplay > realism.

You can do some other neat stuff like blue shifting and red shifting colours based on their velocity to/from the player.

The implementation is trivial, and is left as an exercise for the reader.

It drops heaps of frames when you accelerate (at least for me), and I have a sneaking suspicion that the information reaches the ship instantly (so photons move faster than the speed of light). Asteroids still go invisible at the speed of light, but only because their length goes to zero.. or is that the same thing as delayed information? ...and now my brain is starting to hurt.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org