The Ur-Quan Masters Discussion Forum

For a space game I am working on, I have four stats for each ship: mass, thrust, turn, and thrust_wait. These stats determine the actual performance of the ships. Currently I have in place the following formulas:


But I'm not sure about them. Can someone just sort of critique my formulas? Thanks! :)

so, let's see - the more turn_wait you have, the faster you accelerate?

You're looking at thrust_wait. There isn't a turn_wait in my game. I wanted to keep huge ships from having a large acceleration, but I couldn't think of a way that made sense, so I added that little bit in.

I really think all my formulas suck, which is why I'm asking for advice.

I meant thrust_wait. I'd think that more thrust_wait would give you less acceleration, not more.

also, the "dirnum" formula (whatever that is) is equivalent to the simpler: round(64 * mass / turn);

dirnum is the number of directions that the ship can face. Higher numbers mean slower turning.

thrust_wait is how many frames the game waits before allowing the player to thrust. Acceleration is how much speed is gained each thrust. I think I will probably take that bit out and stop the player from creating super-thrusters another way.

...like making large ships not get as much thrust? :-\

Think of it this way: let's assume the propulsion happens by a series of explosions. If you increase the intensity of the explosion, it therefore costs more energy to produce each explosion, reducing the amount of explosions.

However, I think I will revert to my original plan, and make the thrust_wait also determined by a formula.

The point is not to make large ships not have as much thrust; On the contrary, the idea is that larger ships will have more thrust, because without the extra thrust, the ship would be much too slow and unwieldly to fight in deadly combat. For example, if you take my formula for the top speed with a mass of 500 and a thrust power of 2, you get a maximum speed of 1/500, which is extremely low.

I'm going to update the formulas right now, and I will soon have an update.

UPDATE: Here are the new formulas. I actually have more confidence in these:

To behave more realistically, the relation of propultion parameters to mass should be squared .
Probably energy level will be constant per engine type , E(k)=(1/2)*m*V^2 .
Twice more mass , four times less speed .
Thrust is not related to mass , it's again engine property . But , as you can fit bigger engine into bigger ship , you could maybe positive tie them - more mass=more thrust .

When you say thrust, do you mean acceleration, thrust_wait, or max speed?
Also, when you say "propulsion", do you mean acceleration, thrust_wait, or maximum speed?

Assuming that formula would be for acceleration, I tried translating it into my game:


Is that what you meant? I assumed that V stood for Velocity.

On the other hand, momentum is the quantity that's actually conserved in this system, and it gives
dP/dt = 0 = Engine thrust + (M dV/dt)ship
Rearranging, we get
A = engine thrust / ship mass

You can use the energy formulation if instead of a time step you use a distance step. This is because momentum is force integrated in time, and energy is force integrated in position.
Using a distance step would be really inconvenient for a game, as each particle would update asynchronously. Plus, you'd need to add in an extra step to apportion the energy properly between the exhaust and the ship. All around, just use the momentum approach.

In short,
you were right the first time.

OK, thx. Changed the formula back.

EDIT: These are the current formulas:

I took out the max_speed formula; it will be defined by the user.

*bows out of thread*

Yep, in space inertia would be a better parameter than just the mass. And engine parameters scientifical applications are, probably, less relevant to an arcade style game, unless you were going for a phisics game engine.
By "letting the user to define top speed" you mean the actual parameter, or if the acceleration button is pressed, the ship will go faster indefinately? The latter is more correct, again from real-world point of view... Unless I'm missing out something again :)