Hello. I'm using JMEPhysics for some aspects of my game, but I'd like to remove some of the fudging and delegate more to physics. My game is arcade-style, though, so I'm a bit confused as to how to pull this off.
I currently have a spaceship. The player flies by applying forward thrust with gradual acceleration up to a speed of 5. Without this acceleration, the ship slowly glides to a stop. The player also steers left and right, but always faces in the direction of motion.
I'm currently accomplishing this by setting linear velocities directly, and with a controller that applies a constant deceleration to the ship when it is in motion. I'd like to move more to a force-based system, however, as I've been reading up on AI and see how various motivations can apply forces of differing strengths to produce realistic-looking behaviors. I'm just not sure how to replicate this system more closely in line with the physics engine.
Acceleration/deceleration seems mostly straight-forward. I can apply a force along the entity's direction of motion, then do a bit of fudging to cap the speed at 5. I'm still debating whether I should retain my original fudgy deceleration, or place the objects on a surface with friction. I want some of them to continue moving, though, so it may be easier to retain this model.
I'm not certain about turning, however. I've been reading AI for Game Developers, and its models seem to use port/starboard thrusters that simulate drag, so objects turn more slowly at higher speeds. This would be a nice addition, but I'm not sure how to implement it. I've thought about torque, but I've always thought of that as more for engines and joints. Can it model nose thrusters as well? Or should I instead apply perpendicular forces? This would modify the velocity, and my DirectionVelocitySyncer controller would point the nose along the direction of the velocity vector, but this wouldn't work for a stationary vehicle, so I'm thinking this isn't the way to go.
Thoughts? This probably isn't what the physics engine is intended for, but I do like and use enough of its features such that it would be more troublesome to scrap it.
Sounds like you know what you are doing and what you want to do… so, that's very good 
The only thing that I really have to comment on is that friction idea: I would not recommend using surface friction for it, as it may cause many unwanted effects. Rolling friction or even aerodynamic friction would be better, but ODE does not have them. So applying a force in opposite direction of the velocity should be fine (probably relative to the speed).
irrisor said:
Sounds like you know what you are doing and what you want to do... so, that's very good :)
Well, with the exception of turning, which is throwing me for a loop, pun intended. :)
AI for Game Developers seems to advocate using bow thrusters, and I think I see how this could work, though the exact implementation confuses me. If I implement it as a standard force, then if the object is stationary then it will begin moving in the direction it is pointing simply on a turn I'd think, making it impossible to remain in one position and turn. So I'm guessing I'd need to use torque instead? Except, would torque turn the vehicle instantly, not necessarily simulating slower turns at higher speeds? Just wondering if I'm perhaps missing something about how to apply bow thrust forces and not cause the vehicle to start moving if a simple stationary turn is all that is desired.
I've been googling for this, but am getting lots of results from the ODE list on q12.org whose archives (as of last night) seem to be down. And it seems like most of the tutorials I've found deal with bouncing balls and the like, not on flying vehicles.
I don't know about the exact implementation, but just in terms of physics, if you want to turn without moving you do need torque and no resultant force. The torque turns you, and the resultant force moves you, so by definition what you want is just torque. You can get that using a pair of forces, but you need to make them push in opposite directions, on either side of the center of mass (I think), which is exactly the same as torque. So it seems like you might as well have the torque since it works out the same. Also a torque shouldn't instantly turn the vehicle, it will start it spinning at a rate depending on the moment of inertia and applied torque. If you want less turning at higher speed, you could just reduce the torque at higher speed, but I'm not sure why that helps - from the player's point of view it might just feel odd that the turning is "sluggish" sometimes. I can't think of any reason why any given vehicle would turn slower at higher speed. Unless the implementation you are talking about uses some kind of vectored thrust shared between turning and moving? In that case, it may not be capable of turning in place, or it may have pairs of thrusters. For example if a ship has a thruster on the nose, and one on the tail, it can turn by firing one left and one right with equal thrust - it will then turn in place either left or right (turns in direction the tail thruster is firing). It would accelerate forward by firing both thrusters backwards, etc. In this case, to accelerate and turn the thrusters need to be angled slightly, and the more forward acceleration you apply, the less turning you can get (and vice versa), which is maybe what you are after. In this case, you need to either let the player control the two thrusters, which will be really confusing, or implement a control scheme that translates the user's commands into thruster angles and forces, which will be complicated for you and still quite confusing for the player It would look cool though if you display the thrusters I hope some of that makes sense - I've not used jme-physics all that much, but I'm just describing how things work for a real physical system (I hope).
With the speed thing - if you want a maximum speed, that would tie in well with giving the player a fixed forward thrust to play with, but increasing the drag linearly or with the square of the velocity - you should then get a "terminal velocity" where the thrust balances the drag, without having to have an artificial limit where the thrust just turns off for no reason. You can do the same for torque and angular velocity to stop the ship spinning too quickly. You can tweak the response by altering the drag and force - you can achieve the same terminal velocity with a low drag and low force, or a high drag and high force, but the first will slowly approach the terminal velocity, whereas the second will get there quickly. I think classic asteroids works as if it had a very low force and drag for movement, and a very high drag and force for rotation, since I think the rotation was just a simple linear rotation rate thing.
Actually this discussion started me thinking about something - in jme-physics, when you apply a force, I get the impression it is cleared on the next update? Does this mean that you have to apply really large forces so that 1/100th of a second of that force is enough to do something? or are the forces really more like impulses?
Sorry for the huge essay, this is also stuff I've been through for my game so I've thought about it a lot I looked at using physics to control my planes, but ended up using a hybrid system with physics for collisions and "arcade" logic for movement when not colliding, since I really wanted to keep the sharp, easy-to-control feel of very simple arcade controls. When you hit something, physics makes sure you bounce off it until you regain control, but most of the time the physics object just follows the arcade plane around checking for collisions. Probably a horrible abuse of physics, really
Ick. I wish ode.org wasn't down, because I could really use some of the resources there.
Anyhow, I'm studying the AIFGD physics model further, and I think it may fall under the shared vector model. It looks as if there are separate vectors for forward and bow thrusters, so it may not be able to remain stationary and turn, or it may have some weird logic allowing for this.
I'm guessing the JMEphysics forces are more like impulses, if by "impulses" you mean the forces are applied over time (trying to brush the cobwebs off braincells I haven't used in over a decade. 
I've just switched acceleration to a force-based model and am simply setting the force vector's magnitude to units/second, re-applying it at each update. I'm not having to scale the vector based on the controller interval or anything similar.
Here is the model for which I'm aiming. (cut-n-pasted from AIFGD):
Before getting to the chase algorithm, we want to explain how the predator and prey vehicles will move.
The vehicles are identical in that both are pushed about by some applied thrust force and both can turn via activation of steering forces. To turn right, a steering force is applied that will push the nose of the
vehicle to the right. Likewise, to turn left, a steering force is applied that will push the nose of the vehicle to the left. For the purposes of this example, we assume that the steering forces are bow thrusters---for
example, they could be little jets located on the front end of the vehicle that push the front end to either side. These forces are illustrated in Figure 2
Interesting. From the quoted text, I can't work out whether it is meant to be accurate physics or just a quick approximate simulation. He might just be doing the "slower steering at speed" thing by reducing steering force with speed to fake it.
The Leonard Jones thing sounds interesting, I hadn't heard of that. I've been doing steering by just mixing together different steering behaviours, but a potential sounds interesting, I guess it works out similarly. I've tried to read up as much as I can about steering but I haven't found all that much on the web.
The steering stuff I've read also works based on just plain forces acting on a mass, but I adapted it to work with yaw/pitch/roll/throttle steering, basically just by converting the direction of the "force" into the local space of the plane, then using that as a steering vector (x becomes yaw, y pitch, z throttle, roll is generally unimportant but I use it to keep the planes approximately level). That steering model seems to work well for a plane, I guess it would work for most terrestrial vehicles but a spaceship would be more likely just to use forces, since there are no frictional or aerodynamic effects causing it to steer in the direction it is pointing.
Really amazing sort of info.
Not being rude, but you didn’t really have to bump this thread up, y’know?
It’s a spambot, I think.
Yup. It’s that “Hey pay me money and I’ll write your papers for you” thing.