Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  hovercraft physics, help please....  (Read 2099 times)
0 Members and 1 Guest are viewing this topic.
Offline unwashedvillager

Junior Newbie





« Posted 2005-01-20 11:50:43 »

Right, first post here, so i don't know what kind of detail you people like.....so apologies if i'm vague or that.

I'm currently working on my 4th year college project, which is a tank game, but the tank is a hovercraft so i have to implement the physics for movement-more accurately the hovercraft has to move as it should, regardless of how the movement is achieved. I have a physics enigine started, movement is force based but so far i only have linear forces implemented.

I could "fake" the hovercraft movements, i.e. apply a force to push it to its right and rotate at the same time, which i think would be very niggly and involve loads of trial and error. Right, so what i want to know is what you people think of this approach? Should i go for proper rotational forces? And can anyone give me some tips or code for calculating the inertia tensor if you think the proper approach is better......

From what i understand of it I have to break up the body into loads of point masses, get the distance from the center to each point, square it and do some additional math(can't remember exactly what). The bodies are pretty simple shapes so far, and i don't intend to make them any more complicated than they are so calculating inertia should be pretty straight forward.......but i'm stull a bit confused by it, i don't like to try code something that i don't fully understand, and i don't feel like hammering it into my head like i did with quaternion rotations......

Any help or opinions greatly appreciated......
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #1 - Posted 2005-01-20 12:20:00 »

If I was just doing a game, I would assume that the tank designers knew about the rotational forces of moving the turret, and compensated for them. As such, the hovercraft would tend to follow standard vector thrust patterns with air resistance being the only counter-vector.

What I might do, however, is I might slow the tank a bit when the turret is turning. This would be because the (fans, rockets, antigrav?) engines have to redirect thrust to counter the rotational movement. If you wanted to get tricky about it, you could make each engine an independent force vector, but that would complicate the model significantly.

The advantage to the above approach is that you can treat the tank as a single entity, rather than defining the various tensor points in the model. Since a tank is generally something that doesn't warp under most forces, this is actually a fairly reasonable way to represent it.

Now if you were looking for a simulation as opposed to a game, then I'm afraid you're on your own. It's not so much of a problem of being difficult math, as it is that you have a LOT of math. Every component, its weight, independent thrust vectors, air resistance that changes according to temperature (lots of changes on a battlefield :-)), and resistance to rotation (i.e. friction) are all issues that would need to be accounted for.

Back to your original question, things aren't as difficult as you might think for rotational forces. Since your hovercraft is, well, hovering, it doesn't experience any counter-resistance when the rotation occurs. What this means is that the body of the tank will experience the exact same amount of rotational force as the turret. i.e. If no other forces acted upon the tank, the tank body would rotate the opposite direction of the turret. The only thing to take into account is the inertia of the body vs. the turret. Since (I assume) the body will be heavier, it will rotate slower than the turret. From there you can build your counter-thrust parameters on eliminating the forces places on the tank.

Hmm... does my rambling make any sense or did I just cause a bunch of heads to explode?

Java Game Console Project
Last Journal Entry: 12/17/04
Offline dsellars

Junior Devvie




Need to write more games


« Reply #2 - Posted 2005-01-20 13:16:13 »

Is this going to be a 2d or 3d game?

I was going to look into doing a game like this a while ago, top down 2d style.   I had a play using odejava to power the physics for a simple hovercraft.  It felt really cluncky to control though.

this link should show you what I mean (it might still work, I'm not sure what state I left it in Wink ).  I didn't get far with it as somthing else grabbed my interest Wink

http://bob.newdawnsoftware.com/~dan/ sorry the site is a little on the basic side it's not really a site for the public.

I think if I get round to looking at this again I'll just implement some fake 'game' physics.

Dan.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline unwashedvillager

Junior Newbie





« Reply #3 - Posted 2005-01-20 17:32:28 »

It's in 3d, and I think i've figured a way to split up the tanks nicely for the individual point masses. I'm using 2 semi ellipsoids(if thats the right name) for the collision detection, and i can split them up by volume for each point mass to evenly distribute it.

2 questions for anyone whose implemented inertia before or has better knowledge tahn myself, should i try spread the mass perfectly about the tank? and should i assume the inertia products for the point masses be 0?

jbanes: it's a "simulation"-but my lecturer for project is a gamer, and would rather see a playable game than an accuratephysics based simulation.The people who are marking it will more likely be dazzled by lighting effects than at all impressed by realistic physics, but I'm gonna try implement rhobust physics any way, maybe not so accurate that it would reduce performance. I never though of what you were saying about the turret affecting the movement of the tank, but I'll just leave it alone....What I was getting at in the first post was the way in which hovercraft turn, they kind of slide sideways and turn into the slide....doesn't make much sense unless you've seen it....

Thanks for the quick replies
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #4 - Posted 2005-01-20 18:02:08 »

Quote
What I was getting at in the first post was the way in which hovercraft turn, they kind of slide sideways and turn into the slide....doesn't make much sense unless you've seen it....


Ah, ok. I know what you're talking about. See, I was assuming multiple thrust vectors instead of a single rear thrust vector. i.e. All the thrusters on the bottom would "tilt" to provide forward, lateral, and reverse momentum. Combinations of tilt could produce vehicle rotation. What you're referring to is simply redirecting the rear thrust in a way that produces rotation.

This is complicated, because the hovercraft spins only because the power transfer from one end to another is incomplete. As you said, a tensor field. It also wouldn't work as well in a vacuum, because the air provides a certain amount of resistance that helps "push" against the opposite end of the vehicle.

I think you may be able to get a reasonable approximation by "guessing" the rotation imparted on the vehicle when the thrust is redirected. You can continue to treat the rear thrust as a vector, and simply redirect the vector with the thrust. Then impart an amount of rotation based on the angle of the thrust. The result would be that when you turn, you will start to spin and slide to the side. As soon as you complete your spin, you can redirect the thrust back the other way to stabilize your trajectory right before you re-center the thrust to provide maximum forward power.

That being said, I can't imagine that any engineer in his right mind would design a hovertank like a traditional hovercraft. It simply isn't stable enough as a weapons platform, and would be hellaciously hard to control. (That's a lot of mass you're pushing around!) Instead, I think an engineer would take the approach of using various directed thrusters to maneuver the tank in much the same way as the OHMS system maneuvers the space shuttle.

Our mythical engineer would probably install four lateral thrusters which would allow the tank to slide sideways (fire both on the same side) or rotate on its axis (fire one on each side, at opposing ends of the tank). The hovering would then be achieved with a set of shielded thrusters at the bottom which provide enough thrust to hover the vehicle, but keep enough in reserve to adjust their thrust to cancel out any roll motion produced during strafing maneuvers. Forward thrust would be provided by either tilting the bottom thrusters, or by having thrusters in the rear. Reverse thrust (also braking) would be provided by tilting or forward mounted thrusters.

The proper way to then control such a vehicle is two joysticks. (Anyone remember Atari Battlezone?) Centered sticks would produce thrust only for hovering. Both sticks forward would produce thrust from the rear for forward motion. Both stick to the side would provide lateral motion (i.e. strafing). One stick forward and one stick back would activate the side thrusters whereby the forward stick would activate that side's forward thruster, and the back stick would activate that side's rear thruster. Both sticks back would activate the thrusters on the front of the vehicle.

Such a design becomes very easy to calculate for. You have a vector for weight (down), a vector for hovering thrust (up), and a vector for each thruster mounted on the sides, front, and back of the tank. Take the tank's current vector and add all of those to it. Then take air resistance as a percentage of the vector to subtract. The only special case is then rotation which can then be set to any value that "feels" correct.

Does that help at all?

Java Game Console Project
Last Journal Entry: 12/17/04
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #5 - Posted 2005-01-20 18:02:22 »

why dont you just apply a force in the direction of the rudder? As in get the direction of the rudder and apply a force on the "body" of the hovercraft... And dont apply a great deal of friction...

Or have u already tired that?  Roll Eyes

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #6 - Posted 2005-01-20 18:24:03 »

Quote
why dont you just apply a force in the direction of the rudder? As in get the direction of the rudder and apply a force on the "body" of the hovercraft... And dont apply a great deal of friction...


That would send the hovercraft sideways without actually producing rotation. In order to calculate for the rotation on the craft (i.e. turn and slide), you'd need a tensor field to calculate how much power is being transfered from one end of the vehicle to the other. The vehicles own inertia would be the primary factor that would cause the rotation, as the side pushed on would have more power applied than the side which has no force and is thus resisting the movement.

Java Game Console Project
Last Journal Entry: 12/17/04
Offline unwashedvillager

Junior Newbie





« Reply #7 - Posted 2005-01-21 06:43:37 »

Quote

Such a design becomes very easy to calculate for. You have a vector for weight (down), a vector for hovering thrust (up), and a vector for each thruster mounted on the sides, front, and back of the tank. Take the tank's current vector and add all of those to it. Then take air resistance as a percentage of the vector to subtract. The only special case is then rotation which can then be set to any value that "feels" correct.

Does that help at all?
While your idea would probably save me time, work and make it a better game, the spec for the project says it has to control like a traditional hovercraft. I'm not factoring in recoil and weight displacement due to the turret becuase of this-there's nothing more than a game that feels like punishment.....
Offline Deadcow

Senior Newbie




Back from beyond ... Moo!


« Reply #8 - Posted 2005-02-21 09:20:28 »

There is a full chapter on hovercraft physics in this book:

http://www.oreilly.com/catalog/physicsgame/

If you can get a hand on it...
Pages: [1]
  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.

rwatson462 (37 views)
2014-12-15 09:26:44

Mr.CodeIt (30 views)
2014-12-14 19:50:38

BurntPizza (61 views)
2014-12-09 22:41:13

BurntPizza (98 views)
2014-12-08 04:46:31

JscottyBieshaar (59 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!