Fine Direction on mouse shooters

[diefox]

Hi Guys, I'm doing a small game that uses a simple click and shoot engine I made and I cant figure out a way to make the player shoot in the exact direction the cursor is on, the "look in the direction of" thing is kinda blocky.

thanks in advance

[King_Cool]

Your Bullets has to use Custom Movement ( 360 degree ) and not a Built in one ( built in Movements use 32 direction only, and this will comprimize the accuracy of the long range shots ).

Also, the key is to use 'Floating Point Coordinates' ( use Aterable Values for coordinates instead of the built in X andY ) for your 'Bullet Objects'.
The reason for this is when applying 'decimal movement' ( through the Custom movement ) to the built in X and Y coordinates ( which ony takes Integers ), the line the Bullet is traveling become noticably skewed and incorrect for longer shots.

I have included examples of both methods ( Floating Point Coordinates/ Built In 'Integer' Coordinates ) in the example below:

[ProdigyX]

Rather than using A Floating Point Engine, you can just use the 8 direction movement (or any other non player movement that goes in 8-32 directions).

For this

+Player Clicks
-Create Bullet Target
-Create Bullet
-Set Bullet AV A to Fixed Value of Bullet Target (or you could pair each other with spreaded values)


Then your next event would be something along the lines of


Do a fastloop, loop through each instance of the bullet target, and force the bullet that corresponds to that specific target to "look in that direction"

[King_Cool]

Rather than using A Floating Point Engine, you can just use the 8 direction movement (or any other non player movement that goes in 8-32 directions).

For this

+Player Clicks
-Create Bullet Target
-Create Bullet
-Set Bullet AV A to Fixed Value of Bullet Target (or you could pair each other with spreaded values)


Then your next event would be something along the lines of


Do a fastloop, loop through each instance of the bullet target, and force the bullet that corresponds to that specific target to "look in that direction"

This would cause a ZigZag type movement path for the Bullet, in other words it wont be traveling in a straight line:

The Movement Path will not be as extreme as in the image above, the ZigZag pattern becomes more apparent at higher speed, but still noticable at medium speeds.

I uppdated the example.
Movement Path Nodes are drawn as the Bullet travels, so you can easier judge the straightness and direction of the Bullet.
It now comtains 3 Frames:

#1 - 360 directional, Decimal coordinates Bullet
#2 - 360 directional, Integer coordinates Bullet
#3 - 32 directional, Integer coordinates Bullet ( look closely at the Momement Path, the Nodes go in a ZigZag pattern )

[ProdigyX]

If you use always, it would not cause any kind of zig zag formation. As it is changing the direction every frame.

[King_Cool]

If you use always, it would not cause any kind of zig zag formation. As it is changing the direction every frame.

You are wrong about that.
In the example i posted in my previous post, the 32 directional bullet uses an Allways Condition to direct itself towards the Target.

The presision problem with the 32 directional system has nothing to do with the coding, it has to do with the fact that it only has 32 directions ( and no decimal directions like 32.5 or 0.75 ).

...
Let me explain through this illustration:

- The black lines are the 32 possible directions for the Object
- The length of the Lines represent the Speed of the Object ( pixels moved per Frame )

As you see the Object wants to move a straight line ( Red Line ) from A to B ( 'Current Position' to 'Target' ).
As you also see the Object does not have a Direction which corresponds precicely with the direction to the Target, so the Object does the best it can and chooses the closest one ( marked Light Blue ).
This causes the Object to stray alittle from the straight path, as you see the Object ends up at the 'Green X' outside the Red Line.

And this is the way the Object/ Bullet continues to behave as it moves towards the Target, doing as best it can straifing slightly ( depending on speed ) back and forth along the decired straight path because the direction it is supposed to take does not exist in its Directional System.

[ProdigyX]

Exactly. Since its not 360. It continuously gets closer to the original target direction. Similar to an infinite series (or finite for that matter). Its not EXACTLY right from the get-go, but it gets to its target path in a 99% straight line. Does it stray from the "perfect" path? That it does. But since each direction change lasts for 1/60 of a second (assuming you have the framerate at 60) It is not noticeable in the least. I've use this method in several projects I have had in the past and works.

[King_Cool]

Yes very true ProdegyX, its a totally working method and nothing too wrong about it i guess.
Ive used this method in the past as well.
The Bullet will however not travel indefinitly, and you will have to do a collision check with a Target Object to destroy it at the destination ( If your not compairing 'Bullet distance from Origin' to 'distance from Origin to Target' that is ).