Anyone know the math behind moving in space?

ID:151667
 
Sep 20 2009, 12:00 pm
Okay, so you have a ship. Your ship can fly a maximum of say, 10 pixels per tick. Your ship does not having to be moving in the direction you're facing.

You push thrust, your ship gains thrust in the direction that it faces. As I said, it can have no more than 10 PPT top speed.

So what happens if you're flying at 0 degrees (north), at 10 PPT, you face your ship 270 degrees (east) and give it 5 thrust? You should end up with 5 thrust north and 5 thrust east, so you'd end up going northeast, but at what speed?

Does anyone know the math behind determining how thrusts effects speed when attempting to change direction, and which direction your thrust should be moving your ship? A lot of non-BYOND space games use this math, but it still eludes me.
Sep 20 2009, 12:12 pm (Edited on Sep 20 2009, 12:46 pm)
You can calculate the magnitude of the velocity vector by taking the square root of the sum of the squares of the horizontal and vertical velocities:

var/velocity = sqrt(v_hor*v_hor+v_vert*v_vert)


You can then refactor the vertical and horizontal velocities so they are moving at only 10 pixels by taking a ratio:

var/ratio = 10/velocity
v_hor*=ratio
v_vert*=ratio


Determining how thrusters affect the horizontal and vertical velocities is done with trigonometry (if you can only thrust in 4/8 directions, you can just pre-work this out and save the CPU. This is more for 360° movement)

var/angle = 90
var/acceleration = 2
var/a_hor = acceleration*cos(angle)
var/a_vert = acceleration*sin(angle)


When moving the ship by setting pixel offsets, be sure to use two extra variables to store the pixel offsets. This is necessary because pixel_x and pixel_y automatically round off their values, so if the ship is moving at 0.4 pixels in one direction, it will never actually move because the pixel_x/y will keep discarding the .4

<edit>I forgot to mention, the above code uses the standard 0° = EAST unit circle.</edit>
Sep 20 2009, 12:13 pm
Foomer wrote:
Does anyone know the math behind determining how thrusts effects speed when attempting to change direction, and which direction your thrust should be moving your ship? A lot of non-BYOND space games use this math, but it still eludes me.

I'm not sure of the math behind it but I am pretty sure that you would end up moving at 10 ppt north and 5 ppt east because you gave no opposing thrust to your northbound movement. With that in mind, I would guess that you would be moving northeast at around 7.5 ppt.

EDIT: Crap. DC got to it before I did and with a much better answer.
Sep 20 2009, 12:15 pm
Basicly how you said it is correct. As long as your moving 10 PPT(In however many directions total, while moving NE would be 5 N, 5 E). Anyways that's how I think it could work. Then just use either some nasty trigonometry(Nasty, cause I don't know anything about it) or some type of linear angle changing type of thing, which would be a lot simpler, though not exactly what your looking for I think.

If the above is wrong for what you need, there are some flash demo sources of Moon Landing type games if that's what your looking for. I'm sure it couldn't be that hard to translate the math between languages too.
Sep 20 2009, 12:35 pm (Edited on Sep 20 2009, 12:50 pm)
Unless I remember incorrectly, a force perpendicular to a prior force will not negate the prior one. So if you were moving 10 PPT to the north and accelerated to 5 PPT east, you'd be going 5 PPT east and 10 PPT north. In order to go from 10 PPT north to 5 PPT north and 5 PPT east, the force vector you apply should be in a southeast direction.

When applying forces, differentiate between your north/south and east/west directions. Given a force F at angle A, F*sin(A) would equal the vertical force and F*cos(A) would equal the horizontal force. On one final note, you should change your directionals: For programming/mathematical purposes it is usually best to assume that 0° is EAST and 90° is NORTH. If you're set on using 0° for NORTH, you can simply swap the calls to sin() and cos(), so F*cos(A) would get the vertical force.

Also keep in mind that thrust affects the acceleration of the object, which in turn affects the rate of change of velocity, but it does not directly equal the velocity. Remember those old equations such as: Force = mass * acceleration --- this works especially well for space because it is a frictionless environment and there is less to account for.

So the force of your thrust divided by the mass of the object it is applied on should equal the acceleration applied to the object. This won't directly equal the resulting velocity, but will affect it.

I'll end with an example. Let's say we're accelerating a small 80kg mass with a force of 200N applied at 33° for 3 seconds. We'll start by dividing this force into its horizontal and vertical components:
Horizontal: 200N * cos(33°) = 167.7N
Vertical: 200N * sin(33°) = 108.9N

Now to get the acceleration for each:
F = ma
Horizontal:
- 167.7N = 80kg * a
- 167.7N / 80kg = a
- a = 2.1 m/s2
Vertical:
- 108.9N = 80kg * a
- 108.9N / 80kg = a
- a = 1.4 m/s2

So for each of those 3 seconds, the horizontal velocity will increase by 2.1 m/s and the vertical velocity will increase by 1.4 m/s. Assuming the object was at rest when this force was initially applied, after 3 seconds the object would be moving 4.2 m/s north and 6.3 m/s east. The last task, then, is to come up with some number of pixels to correspond to meters and make appropriate conversions.

Edit: whoops, spent so long typing everyone else already got to this before I did!

Edit2: I also wanted to mention that a spaceship in flight will not likely be applying thrusters all the time. One thrust and it will stay in motion until an opposite force is applied. So if you accelerated to 10PPT north, and stopped applying thrusters, you'd continue moving at that rate until something accelerated you to the south.
Sep 20 2009, 12:36 pm
Well, considering there's pretty much very little air etc. in space, there shouldn't be very much friction, so you can probably get away with some simple speed, etc. calculations.
Sep 20 2009, 12:41 pm
jt_vectors. Just saying. It handles all of your trigonometric evilness without need of knowing how it works.
Sep 20 2009, 12:52 pm
In response to Kaiochao
Kaiochao wrote:
jt_vectors. Just saying. It handles all of your trigonometric evilness without need of knowing how it works.

Care to demonstrate what I'd need to do? I still haven't looked into jt vectors.
Sep 20 2009, 12:59 pm
In response to Foomer
Foomer wrote:
Kaiochao wrote:
jt_vectors. Just saying. It handles all of your trigonometric evilness without need of knowing how it works.

Care to demonstrate what I'd need to do? I still haven't looked into jt vectors.

http://www.byond.com/members/ DreamMakers?command=view_post&post=77879
Sep 20 2009, 1:44 pm
In response to Foomer
One pretty useful proc is jt_vectors.VectorFromBearing().

//Previously defined a "position" /coordinate (or /vector, change moveto accordingly) for the moving object.

//It creates a new vector pointing towards Bearing(in degrees) with a magnitude of Distance. 
var/vector/move = jt_vectors.VectorFromBearing(Bearing, Distance)

//This would be the new coordinate for collision testing, as to not change your position beforehand. 
var/coordinate/moveto = position.AddVector(move) //This creates a new /coordinate.
//check for collisions with moveto.
//if there are no collisions, set the position to the new position.
position = moveto

pxUpdate() //update the visual position.



Hobnob's article shows a way to convert vector/coordinate positions to BYOND's coordinate system, where 1 unit = 1 pixel.
The jt_vectors demo has a different one, where 1 unit = 1 tile (and 1 pixel = 1/32 units, I suppose).
Sep 22 2009, 1:18 pm
Oops! I went to reply to this thread, went AFK in the process - came back and wrote all this. I think I completely distorted your question in my head, and wrote something that doesn't answer your question but is related. Instead of letting it go to waste I'll hit post.


I'll recommend you read Hobnob's vector article, I haven't read it myself but I bet there's a lot to learn from it.


//inertia varies, but we'll just make it constant
#define inertia 0.8


mob
  var
    px = 0 //the mobs positions
    py = 0
    vx = 0 //the mobs velocities
    vy = 0

  proc
    tick(var/dt)
      move(dt)

    move(var/dt)
      //who needs collision detection

      x += vx * dt
      y += vy * dt

      vx *= inertia * dt
      vy *= inertia * dt

      position()

    position()
      x = px / 32
      y = py / 32
      pixel_x = px % 32
      pixel_y = px % 32

      if(client)
        client.pixel_x = px % 32
        client.pixel_y = py % 32

  New()
    . = ..()

    px = x * 32 + 16
    py = y * 32 + 16
    position()


Now you've got the ground work for what we seem to call pixel movement, you'll need to do some event handling.

client
  var
    north = FALSE
    south = FALSE
    east = FALSE
    west = FALSE

  proc
    KeyUp(var/key)
      switch(key)
        if("north") north = FALSE
        if("south") south = FALSE
        if("east") east = FALSE
        if("west") west = FALSE

    KeyDown(var/key)
      switch(key)
        if("north") north = TRUE
        if("south") south = TRUE
        if("east") east = TRUE
        if("west") west = TRUE


Now we can move the mob:

mob/player
  var
    angle = 0

  tick(var/dt)
    if(client)
      if(client.north)
        //cheap acceleration
        vx += sin(angle)
        vy += cos(angle)

      if(client.south)
        vx -= sin(angle)
        vy -= cos(angle)

      if(client.east)
        angle += 2

      if(client.west)
        angle -= 2

     move(dt)


Movement, key events, and tying them together is down.
All you need is a game loop and you're set.

world
  New()
    . = ..()

    loop()

proc
  loop()
    while(TRUE)
      for(var/mob/m)
        m.tick(1) //you could wastefully "pause" the game by passing 0, you could increase the time delta to "fast forward" or decrease for "slow-motion"

        sleep(1)
Sep 23 2009, 2:35 am (Edited on Sep 23 2009, 3:22 am)
In response to Crashed
wait... your code doesn't really seem to make much sense?

      vx *= inertia * dt
      vy *= inertia * dt


It looks to me like you're accelerating the mob... with inertia * delta time? That doesn't make sense. :|

[EDIT]: Ah I see. Your inertia constant isn't quite inertia but something more along the lines of sliding friction or air resistance.
Though there's a problem with that. What if the delta time is several ticks long? Then you'd be accelerating the mob rather than decelerating.
An easy fix would be to make it
      vx *= inertia / dt
      vy *= inertia / dt

That would be guaranteed to decelerate assuming that the delta time is at least one tick long. (It'd be better to do this in a for() though, since 80% of the velocity is constantly changing)

It would be more realistic to instead have a global sliding-friction coefficient and have that generate a force on the mob in the negative velocity direction. That'd be subtracting from the magnitude of velocity rather than multiplying to the magnitude of velocity.
Air resistance, on the other hand, is kind of annoying with F = -bv


Also, I think you made a typo here:
      x += vx * dt
      y += vy * dt

Shouldn't it be px and py instead of x and y?

IIRC, x and y are floored automatically by BYOND (Like you would expect from a variable typecasted as int from any other language) so they're not good for storing decimal or sub-coordinates.

Sep 25 2009, 11:17 am
I. Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it.Issacc newton 1st law

I. II. The relationship between an object's mass m, its acceleration a, and the applied force F is F = ma. Acceleration and force are vectors (as indicated by their symbols being displayed in slant bold font); in this law the direction of the force vector is the same as the direction of the acceleration vector.

III. For every action there is an equal and opposite reaction.

hope that helps
Sep 25 2009, 1:49 pm
In response to Gigimoi
Not really, since all that would obviously arise from the vectors already discussed.