I have a space ship floating in 2 dimensional space. It has an engine that provides a fixed amount of acceleration.

the ship may be moving in any direction. the ship's propulsion and image_angle are controlled by the arrow keys. The engine provides acceleration towards image_angle.

now, I want to use einstein's (special relativity?) theory to determine the maximum velocity the ship can achieve vs. lightspeed, given the thrust. Once I have the correct equation, I can tweak it so it will work with pixels and frames per second, and then put it in the step event. This will accomplish two important things: 1) a way to limit the player's speed without sacrificing realism by using noobish code like: "If speed>maxspeed speed=maxspeed" 2) a rating system for different engines

I am not well versed in advanced physics, but I DO know that as you approach the speed of light, it requires more and more energy to accelerate...

It's not the end of the world if this idea won't really work... I just thought it would be cool to try.

if(vector.length>maxspeed)
{
vector=vector.normalize*maxspeed
}

Look up the Lorentz factor. It is equal to 1/(sqrt(1-(sqr(speed)/sqr( c ))). This number determines many things to do with special relativity, such as length contraction, time dilation, and so on.
So if you have a thruster which outputs so much energy per second, this factor will allow you to determine how much the resultant increase in speed will be.

I also advise you to brush up on energy laws and so on. Most of it is fairly simple linear equations.

edit: ( c ), not ©

You want to have the correct method, only to crush it to get a game-play worthy effect ?

Why than not simply using a simple effect instead : Define a maximum speed, subtract the current speed and than divide the result by an acceleration-factor (or take, for example, the sqare root). Use this as the speed in a "motion_add(...)" command.

The end-result will be that the closer you get to the intended maximum speed the lower the applied thrust will become (down to Zero thrust at maximum speed).

Hope that helps.

The problem I run into with motion_add is this: motion_add(image_angle,(maxspeed-speed)/5) will not work because speed is actually a velocity with the object's "direction". If, for example, image angle is exactly opposite of the direction, the speed used in the equation does not become negative. this completely undermines the effect I was trying to produce. In order to fix it, I would have to do a whole bunch of trig stuff. I'm lazy, so after a simple motion_add(image_angle,1), I wrote: speed=speed*(sqrt(1-(sqr(speed)/sqr(maxspeed)))) and it works. however, I am not sure if this is the most processing-efficient way to use the lorentz factor.

EDIT: when the acceleration becomes large, the speed equation begins to loop so that each step, (x) speed is added... and the next step (y) speed is subtracted. so it vibrates. I fixed this by writing friction=sqrt(sqr(speed)/sqr(maxspeed)). this also eliminates any possibility for an error if the speed becomes higher than the maxspeed.

I am trying to understand things, but it is not that simple.

The energy of a spaceship is equal to
> E = 1 / sqrt(1 - sqr(speed/maxspeed)) * mass * maxspeed^2
which is approximately for speed << maxspeed
> (1 - 0.25*sqr(sqr(speed/maxspeed)) / sqrt(1 - sqr(speed/maxspeed) + 0.25*sqr(sqr(speed/maxspeed))) * mass * maxspeed^2
which is equal to secondary school's formula (first term E = mc^2, second E = 0.5mv^2)
> (1 + 0.5*sqr(speed/maxspeed)) * mass * maxspeed^2 = mass * maxspeed^2 + 0.5 * mass * speed^2

We get the thruster speed by solving E = mass*maxspeed^2 + 0.5*mass*thrustspeed^2, I guess. Dividing out mass*maxspeed^2, we get
> 1 / sqrt(1- sqr(speed/maxspeed)) = 1 + 0.5 * sqr(thrustspeed/maxspeed)
which, if I am not mistaken, is equivalent to speed = maxspeed * sqrt(blah/(blah+1)), where
> blah = sqr(thrustspeed/maxspeed) + 0.25*sqr(sqr(thrustspeed/maxspeed))
Indeed, if we estimate blah by sqr(thrustspeed/maxspeed) and blah+1 by 1, then we get the naive formale speed = thrustspeed.

I guess you can compute thustspeed as sqrt(sqr(xthrustspeed) + sqr(ythrustspeed)) and direction as point_direction(xthustspeed,ythrustspeed). Notice that in case ythustspeed is very large compared to xthustspeed, then xspeed is very close to zero. This seems logical. The astronauts will observe the xspeed as it is when it is only very small and thus does not suffer relativity effects, but since the time for the astronauts runs slower, the actual xspeed will be slower as well.

The thrustspeed may get infinitely large. If the thustspeed gets larger, the time the travel will take for the astronauts gets lower and lower. This is because the time on the spaceship goes slower and slower. Now you might wonder how the astronauts can perceive light years of space passing by in only a few days. The only possible conclusion is that the space for the astronauts transforms in such a way that light years become light days or even light hours.

EDIT: you can equip the spaceship with a flashlight to show the astronaut's time. Each real second (step), the time increase for the flashlight is sqrt(1 - sqr(speed/maxspeed)) seconds (steps).

EDIT EDIT: what I call thrustspeed is called proper velocity on the internet. I cannot find anywhere that you can add xthrustspeed and ythrustspeed by the formulas thustspeed =sqrt(sqr(xthrustspeed) + sqr(ythrustspeed)) and direction = point_direction(xthustspeed,ythrustspeed), though.

I do not think my formulas are right. Better ask your question on www.physicsforums.com or something. That is a more appropriate forum.

wow... yeah, not try putting it into the game 0.0

Are you talking the actual speed of movement of objects on the screen, or do you mean like you want to just report the velocity (like it's a gauge shown on a control panel)?

It doesn't make much sense for moving objects on the screen, because there are only a few speeds that will be playable -- like once the speed is a quarter of the view size per step I don't think any human could play the game. So the player object rarely moves more than 16 pixels per step in most games.

http://gmc.yoyogames.com/index.php?showtopic=410463&hl=