Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (517)
Games in Android Showcase (123)
games submitted by our members
Games in WIP (578)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Physics of shooting  (Read 6039 times)
0 Members and 1 Guest are viewing this topic.
Offline Gudradain
« Reply #30 - Posted 2010-03-10 17:10:24 »

Anyway, the math of shooting bullets is extremely simple:
1  
2  
3  
4  
bullet.position.x = gun.position.x
bullet.position.y = gun.position.y
bullet.velocity.x = gun.velocity.x + cos(gun.rotation) * bullet.initalSpeed
bullet.velocity.y = gun.velocity.y + sin(gun.rotation) * bullet.initalSpeed

this will always be correct, until you approach the speed of light. persecutioncomplex



Yup Riven is right. With this your bullet will go as you want him to go if you don't change the speed of your ship (gun) while the bullet is on the screen.

If you want the bullet the move on the same visible trajectory no matter if the ship change speed or not, you need to reread my post. If you don't understand what I mean just ask.

Good luck.
Offline dishmoth
« Reply #31 - Posted 2010-03-11 08:37:44 »

this will always be correct, until you approach the speed of light. persecutioncomplex

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!  Roll Eyes
Simon

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #32 - Posted 2010-03-11 15:11:51 »

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? Smiley
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.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Riven
« League of Dukes »

JGO Overlord


Medals: 823
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #33 - Posted 2010-03-11 15:38:46 »

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.

If the plane is moving forward and the gun is shot pointing forward:
   1. plane speed = 1000
   2. bullet speed = 1000 + 1000 = 2000
      (plane hits the breaks)
   3. plane speed = 0
   4. bullet speed = 2000 (same, because plane does not affect bullet after the shot was fired)

If the plane is moving backward (original example) and the gun is shot pointing forward:
   1. plane speed = -1000
   2. bullet speed = -1000 + 1000 = 0
      (plane hits the breaks)
   3. plane speed = 0
   4. bullet speed = 0 (same, because plane does not affect bullet after the shot was fired)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #34 - Posted 2010-03-11 16:23:45 »

If the plane is moving forward and the gun is shot pointing forward:
   1. plane speed = 1000
   2. bullet speed = 1000 + 1000 = 2000
      (plane hits the breaks)
   3. plane speed = 0
   4. bullet speed = 2000 (same, because plane does not affect bullet after the shot was fired)

If the plane is moving backward (original example) and the gun is shot pointing forward:
   1. plane speed = -1000
   2. bullet speed = -1000 + 1000 = 0
      (plane hits the breaks)
   3. plane speed = 0
   4. bullet speed = 0 (same, because plane does not affect bullet after the shot was fired)
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:

1. ship is facing right (positive)
2. ship speed = -10 px/ts (px = pixels, ts = timesteps)
3. bullet speed = -10 + 10 = 0 px/ts

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).

1. ship is facing right (positive)
2. ship speed = -30 px/ts
3. bullet speed = -30 + 10 = -20 px/ts
4. ship stops

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.

A much more common and potentially more important example:

1. ship is facing right (positive)
2. ship speed = 30 px/ts
3. first bullet speed = 10 + 30 = 40 px/ts
4. ship is reducing speed as it fires

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=9MIvhLSrYVk
In 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

See my work:
OTC Software
Offline Jono
« Reply #35 - Posted 2010-03-11 20:45:42 »

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!  Roll Eyes
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.
Offline dishmoth
« Reply #36 - Posted 2010-03-13 11:34:04 »

I've had a think about this before ...

That's the spirit!  I knew someone here must have.  Grin

Quote
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.

Yes, that does highlight the problem that "realistic" and "fun to play" don't necessarily go hand-in-hand.

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

Quite.  The only tricky bit would be thinking up a name.  Assuming a game in which you shoot chunks of rock, the best I could come up with was Relativisteroids.  Tongue  There's room for improvement.

Simon

Offline Jono
« Reply #37 - Posted 2010-03-13 19:44:10 »

Actually, I found a Java implementation of relativistic asteroids:
http://www.referencegames.com/index.html

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.

Assuming a game in which you shoot chunks of rock, the best I could come up with was Relativisteroids.  Tongue  There's room for improvement.

Yours is a vast improvement over the only one that pops into my head: Hemorrhoids.
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

DarkCart (7 views)
2014-10-31 21:44:48

DarkCart (7 views)
2014-10-31 21:43:57

TehJavaDev (38 views)
2014-10-27 03:28:38

TehJavaDev (29 views)
2014-10-27 03:27:51

DarkCart (43 views)
2014-10-26 19:37:11

Luminem (24 views)
2014-10-26 10:17:50

Luminem (29 views)
2014-10-26 10:14:04

theagentd (35 views)
2014-10-25 15:46:29

Longarmx (63 views)
2014-10-17 03:59:02

Norakomi (61 views)
2014-10-16 15:22:06
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!