• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

GameMaker Image angle, steering behaviors, and velocity

samspade

Member
I have a decent vector based steering behavior library and I'm trying to tie the image angle (top down 2d) to the directional input provided by the steering behaviors but not the objects overall velocity.

For example, lets say the object wants to seek the mouse. The image angle should be equal to the direction of its velocity. However, if I add wind blowing perpendicular to the object the objects final velocity will no longer be directly towards the mouse (or the true seek velocity) as the wind will be pushing it. However, I still want the image angle to be following the true seek velocity - e.g. the directly the object would be heading in sans wind.

This is even more complicated because steering behaviors are capped - e.g. there's only so much thrust an object can apply towards 'its' desired direction (where that could be player or ai controlled) but outside forces have no such cap (e.g. wind, gravity, etc.).

I feel like this is a simple problem and I am missing an obvious solution, but I haven't been able to figure out a method that works.

Combining all forces gives the correct movement direction, but incorrect image angle and its capped, separating steering and other forces gives a correct imagine angle but incorrect movement as the forces don't cancel each other out.

How do I:
  • limit the steering force
  • cap the steering velocity
  • tie image angle to steering velocity angle
  • but have no limit on outside forces
  • and no cap on final velocity
 

NightFrost

Member
I don't know what feel you're wanting to give the controls, but I think it might be best to detach facing completely from current velocity and make it always be towards mouse, giving the ship an Asteroids-y control. This way, when player applies thrust, they are in complete control of its velocity vector. As you've noticed, the problem with facing in steering behaviors is how it always equals current velocity vector, which also means an agent at rest has no facing.

If you don't want to go that way, I think the best option is to apply acceleration to velocity, cap it, take that as ship's facing, and then apply wind without capping velocity or recalculating facing. However you'd discard this change to velocity after applying to position, and next step assume the velocity + acceleration alone are the actual vector. I'm not sure how the handling feels with that, you'll have to test it out.

It might drift, as I just now realized there's a conflict of sort between ship's 'true' direction and the direction of mouse. I mean, the only way to make the ship reach the mouse is to make it face the mouse, but if acceleration is applied to any other direction than the mouse (as in, along the ship's actual velocity vector) then it will never be able to reach the mouse if there is wind or gravity or other additional forces.
 
Top