Starship auto steering

Started by
13 comments, last by Norman Barrows 9 years, 5 months ago

Hello,

I have been programming games for some time now, but one thing I never really fiddled with too much was AI and clever steering behaviors.

I am currently implementing a game where you control 3D space ships along a 2D plane, using a point and click based system.

Movement of the units is really simple, they have a current transform and every tick they move towards their "goal" position in a straight line (if there is a goal position; otherwise the ship is just idle). As the ship translates into the final position on this 2D plane, it rotates at a given speed to face the target, so it doesn't feel too abrupt, for example as when the user tells the ship to go to somewhere in its behind area.

Now, I want to give my ships a bit more interesting movement. I am not touching the basics of the movement, it remains a simple point and click to make the ship go from a transform A to transform B, but I want the ship to traverse a more interesting path to get to the destination, respecting some local mobility rules of the ship itself.

Can you give me some guidance on how to tackle this issue? I am not sure what to look for, perhaps there are some well known algorithms to handle this?

Otherwise, what would be my next step, assuming I don't get any hints, would be to try and model some basic elements of a big starship, and try to play with those in how the ship moves.

1) Tilting: the bigger the ship, the less tilting it can do as it moves, and because of this, it also turns slower if it can't tilt. Tilting of the ship would vary depending on the dot product between the desired direction and current direction , in relation to current speed?

2) How much lateral/backwards thrusting power the unit has, which would influence how quick it can turn to face the target direction? (assuming there is any; some ships could simply have a unique propulsor at the back)

3) General mass of the ship would come into play with its thrust power to decide how quick it moves?

Thanks in advance :)

Advertisement

Several thoughts for you to consider, and this may be more simulation than you're interested in:

You're simulating a starship so you've already made some assumptions (either explicitly or implicityly) about the technology available.


there are some well known algorithms to handle this?

For the foreseeable future, at speeds reasonably below the speed of light, Newton's laws will be applicable. Learn them well!

A criteria for you to consider: passenger comfort and safety - you can't accelerate at g-forces for which the occupants have not been trained. If personnel are standing or walking when turns take place, lateral acceleration must be limited to very low values (a fraction of a g). Untrained seated/restrained passengers should be subjected only to low "vertical" accelerations, maybe 1.1 to 1.25 g's. If a person weighs 160 pounds (mass*acceleration), an acceleration of 1.25 g results in the body experiencing a weight of 200 pounds! Lateral accelerations should be limited to fractions of a g.

And remember: turning is acceleration!

If you want to assume your starship has a "local" gravity generator which can cancel the effects of acceleration on passengers, you can forget about all that.

However, as you mention, you still have to consider the mass of the ship versus the thrust available to determine the maximum acceleration. That's a matter of you choosing reasonable masses and whatever thrust force you want to simulate.

- Consider economics: a commercial starship which is used primarily for getting from point A to point B, generally in a straight line, would likely have a large thrust capability (expensive) for one direction, with minor course correction lateral thrusters (cheaper, less fuel consumption, less mass). Those lateral thrusters would probably be sized for rotating (change angular not linear velocity) the craft only, not to provide lateral acceleration. That is, course corrections would be made by initialing rotating the ship past the desired direction and use the primary engine to accelerate from the "old" velocity to the "new" velocity. As velocity increases in the desired direction, the ship would be slowly rotated back toward that direction.

Think of a rear-wheel car on ice - capable of "thrust" only in the direction of the rear drive wheels. To change velocity, you have to turn the front wheels (no forward thrust, just a little lateral force which turns the chassis). You would swing the chassis direction past the desired direction, slowing the car in the "old" direction and gradually increasing speed in the "new" direction. As the velocity approaches the desired direction, you turn the front wheels in the other direction (past the desired direction) to start swinging the chassis back into line.

- You have to stop at your destination. In a frictionless environment (such as the vacuum of space), you have to start deceleration at mid-point (or a little beyond maybe as you've used fuel, mass is reduced and you'll need less force to decelerate at the end than you did at the beginning).

- Can you use massive objects in local space to change direction using a "gravity" swing around a planet or star? If so, that acceleration is "free" with regard to fuel consumption.

Interesting thought problem, Grimshaw.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Do you use vectors for movement? My personal take is to keep a constant reference to the ship's movement in space, so that, as the helm rotate, the ship accelerates in that new direction, but not all magnitude already applied follow.

For example, if you are going straight "left" and rotate to go straight "up", but your ship movement is independant, it will know that you have accelerated to the left in the past and will take a while to adjust to your new heading.

All you need to do then is to use your acceleration and apply vectors, and as the ship rotate, you set new vectors to modify the previous one. Also apply a constant "decay" to the ship's movement and previous vectors will slowly become irrelevant, still giving you a cool ellipse which looks much better despite being quite unrealistic (in space, you'd be adrift to the left/up forever).

@Buckeye, thanks for the insight, indeed you went a bit too simulation there, since my ships are only fixed shape bodies with predetermined thruster powers and directions (for the behavior and emitting particles etc), I only need to know how to evolve from A to B, using these constraints in a way that looks and feels good. Plus, most movement should happen within the amount of game space that fits the screen, so each move shouldn't be big in magnitude. However, you got some nice tips there, which I will certainly consider!

@Orymus3, yes I use vectors for moving towards the target, and will indeed follow the tip to keep adapting my "forward" vector over time, until it faces the right direction to the target. I guess now I just want to find the algorithm that makes it look/feel more interesting.

For example, ships with thrusters on the front and sides can easily do a straight path to the target location, with velocity varying through the course, as the ship rotates (assuming different thrusters have different strengths). Other example is a ship with just a thruster in the back which will need to start accelerating to whatever direction it is facing, and then use the inertia and its tilting feature to start curving into the right direction.

I know there are gaps in the logic because physics, but I primarily want the game to feel good, rather than give orgasms to physicists ^^

You might want to look into flow fields? It's what Planetary Annihilation uses for its stuff, and I think the Spring RTS also uses it. Also, I'd probably just abstract away the tilt and what not away, so that it's only a graphical representation of it's overall turn rate and acceleration.

You don't have to simulate anything if you don't want to. If the goal is the make the ships travel a curving path that looks good, then calculate a curving path that looks good and move them along it. Who cares if the physics is correct?

In this case a Bezier curve would probably be a good choice. You have a starting point and initial facing, and you have an ending point with a target facing. So your first and fourth control points will be the start and end positions. The second control point can be calculated by projecting the initial facing a fixed distance forward from the starting position. You might or might not scale that distance by the ship's current speed depending on whether you want to factor in braking distance. Similarly, the third control point can be found by projecting the target facing backwards from the end position. You can vary the distance you use when projecting the facing vector -- a small distance would simulate nimble ships that can fly more-or-less a straight line, and a longer distance would simulate ships that need more time to turn.

I can foresee an issue that might come up if the start and end positions are too close and the control points end up crossing each other. You could probably check for that case specifically, or just ensure that the distance you project the facing vectors is always less than half the distance from start to end.

Steering behaviors are the easiest and best documented way to achieve the smoothness of movement while staying relatively physically accurate. They need no precalculation like flow fields (which are advantageous for large numbers of units doing the same thing) and they're more physically accurate and reactive than bezier curves would be.

With a steering behavior you can easily control the acceleration and deceleration, which includes smooth turning and the free-body equivalent of "turn radiuses."

So far as tilts and the like, that's an animation issue. The animation blend tree should be fed the velocity/acceleration data and select the appropriate animations to play based on that. e.g. if the ship is applying 70% of its thrust capacity to turn right, select the animation with most of the thrusters on the front-left of the ship firing. (Your animation is not going to be super-simulationy or accurate because little things like "forward" are irrelevant in space but players would be unsatisfied if the ship didn't look like it was moving in a terrestrial/Hollywood-like fashion; they'll probably want sounds and other effects that don't make sense in space but make for a more game-like experience).

The nice thing about steering is that it can be applied to simple collision avoidance and the like as well, making fleets of ships, small obstacles, or criss-corssing paths look better.

Sean Middleditch – Game Systems Engineer – Join my team!

Thanks a lot for the suggestions, I will definitely read more into steering behaviors, flow fields and bezier curves. This is really helpful.

Is flocking of many ships part of the steering behavior topic?


For example, ships with thrusters on the front and sides can easily do a straight path to the target location, with velocity varying through the course, as the ship rotates (assuming different thrusters have different strengths). Other example is a ship with just a thruster in the back which will need to start accelerating to whatever direction it is facing, and then use the inertia and its tilting feature to start curving into the right direction.

Ok it seems I have misunderstood what 'stage' you were at. Sorry.


Is flocking of many ships part of the steering behavior topic?

If I assume what you mean by "flocking" (station-keeping?), then .. not really. Flocking behavior determines what direction and destination a ship should have. How a ship changes direction, avoids close encounters, etc., is handled by proper steering.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

This topic is closed to new replies.

Advertisement