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?

i don't quite understand what you mean by "tilting".

larger ships have more mass, and therefore more rotational inertia, resulting in slower turnrates (for a given size maneuvering thruster firing for a given amount of time).

a ship with a slower turn rate has a wider turning radius at any given 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)

this is your maneuvering thrusters, which turn the ship. usually translates to turnrate in a game.

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

F=M*A, or A=F/M. Accleration = force (thrust in pounds) / ship mass. bigger engines = faster. bigger ship = slower. thrust divided by mass give you the ship's acceleration rate.

when thrust is zero, acceleration is zero. when thrust is 100%, acceleration is maxed out at max_thrust/ship _mass.

to steer from A to B. ship has a heading, and a turnrate. each tick: calculate absolute heading to target. calculate relative heading to target (absolute heading - ship heading). limit relative heading to +/- turnrate. turn ship by relative heading.

for thrust: set thruster % based on range. don't forget that in the real word, spaceships have to turn around and thrust to slow down.

to move: ship has a speed, and a location. thrust % determines acceleration. each tick: speed += acceleration. then move ship in current direction by amount based on speed.

flocking in this case would be akin to "formation flying".

if you add in negative acceleration as you get close, the code will fly its self to the target in a realistic manner. by tweaking turnrate and how much acceleration = 100% thrust, you can tailor the behavior of the ship.

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.

sounds like "titling" is similar to "roll" in an aircraft. unfortunately, spaceships don't have air moving over control surfaces to allow changes in direction when the craft is flying straight ahead. only spaceships in Star Wars fly like planes (and that was done on purpose). this is a case where the ship would use maneuvering thrusters to turn around and then thrust to decelerate.

i would just give each ship a turn rate and max acceleration (and max deceleration too, perhaps).

you should be able to model pretty much any desired behavior that way.

and when speed drops near zero, set it to zero, to prevent minuscule "drift".

calculations should theoretically be doable using either angle or vectors. i use angles. doing the same thing with vectors seems like it would be harder/ more work.

results can be calculated either way then translated to whatever you need: Euler angles, direction vectors, quaternions, etc.

Have a look at Fernando's tutorials that are posted here:

http://tutsplus.com/authors/fernando-bevilacqua

He's done a number of them covering steering behaviour

Thanks a lot to everyone, I definitely have the answers I was looking for!

@NormanBarrows your answer was especially good, considering it gives a practical approach to manipulate ship steering within my constraints, thank you.

1) If you use a physics based system for movement, then scripted behaviours can become very tricky.

Consider the classic Elite docking procedure. The algorithm is very simple, go to a point, turn to face space station, accelerate into space station matching roll rate.

tricky indeed. in such cases its nice to have a "cheat" such as a "dock" or "assume standard orbit" button, which triggers what is basically a semi-canned animation of the ship docking, etc.

3) Allow micro adjustment.

Whatever solution you decide to use, make sure your code can do little tweaks that are outside the base system. Things like when a ship goes to a location, don't just say "ah it's close enough .. stop all engines and zero velocities and accelerations" . You may need to say "and make the ships location equal to the target location" as well.

I've seen several occasions where animations look sh1t because the ship is actually a couple of feet away from where it should be. Docking tubes that don't attach. Characters that pass through walls. That sort of thing.

definitely. this issue is common in space sims, unlike most other games, for some reason. guess they weren't playing close attention to exact locations. space sims that use real physics tend to have "drift" issues - near zero, but non-zero velocities that induce undesirable drift and roll (translation and rotation) to a ship. that's why you sometimes have to set near zero equal to zero, and make sure you're exactly where you ought to be (IE do a location fixup).