Shuttle design

[metalgearsloth]

There's a bunch of design stuff that needs solving for shuttles:

• How do we determine a grid's mass?
• How do we determine a grid's fixtures? I would assume it's based on chunks but are we doing 4 fixtures for a chunk (bearing in mind the vert limit for a convex poly in box2d is 8)
• How do we determine its top speed and "acceleration"? Is it based on number of engines? This also ties into the grid's mass
• What speed curve do we use? i.e. at a certain % of top speed drop it a bit
• What should the pilot's experience be like? Should they have a window with a radar on it? What should that look like?

[metalgearsloth]

We talked about it on discord a bit:

• Default mode (cruising?) should be tank controls where w goes "North", a and d rotate, and s goes South. This should be settable by a helmsman console or whatever eventually (currently it'll just be the grid's North).
• Potential for a strafing / docking mode at lower speeds.
• Speed based on number of thrusters in the relevant direction (probably need diminishing returns on this).

Other stuff still up in the air.

[clyfordv]

I can take a crack at half of these. I'd argue for having every grid be the same mass. Feels like you gain little by having it otherwise. Not super familiar with fixtures, but gather from looking at the code that they're the collision object. That's the extent of my input on that.

For your third and fourth bullet:

• Acceleration is proportional to thrust (from engines) divided by mass.
• You can either have no top speed (realistic, potentially unmanageable) or create a fictional drag force (more manageable).
• If it's the latter, I'd suggest modeling the fictional drag force as either directly or exponentially proportional to velocity.

... extrapolation on that last point:

• Directly proportional: computationally cheaper, might feel a little strange, but will likely make docking easier.
• Exponentially proportional: computationally more expensive (from the sqrt), will feel "floatier" at low speeds, might feel more realistic, will likely make docking more difficult.

System of equations for the above:

acceleration = # of engines * engine thrust/total mass

For directly proportional:
drag = total mass * velocity * drag coefficient
maximum velocity = # of engines * engine thrust/total mass (equal to acceleration)

For exponentially proportional:
drag = total mass * velocity^2 * drag coefficient
maximum velocity = sqrt(# of engines * engine thrust/total mass) (equal to sqrt(acceleration)

Speed curve arises naturally out of the above.

Units, for those who desire them:
acceleration - m/s^2
thrust - kg * m/s^2 (Newtons)
drag - kg * m/s^2
mass - kg

Drag coefficient and engine thrust are dimensionless quantities (read: no units) that can be tweaked to give the desired behavior in game.

[clyfordv]

sqrt(...) : square root, (...)^0.5

[PaulRitter]

First of, besides this little nitpick, i really like @clyfordv's proposal. Seeing how shuttles wont be scattered all over the server being driven non-stop, i'd opt for the drag force to be exponentially proportional to the velocity.

I'd argue for having every grid be the same mass.

I don't think this is a good idea, simply because stations will - in theory - be drivable too. I however too do not think mass needs to be that detailed. A sum of all tiles of a grid should probably suffice imo

[clyfordv]

I think I mistakenly thought grids = tiles (when it appears now grid = whole shuttle), so it seems we agree on that as well.