• 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!

SOLVED Please help making enemy bullets faster over time.

N

nicholaswdawson

Guest
I created an object bullet that in the create event shoots towards the player

//create event
acceleration = 1;
move_towards_point(obj_player.x,obj_player.y,acceleration);

in the step event, I thought by increasing acceleration, it would make the bullet faster. the first time i set up a series of alarms to make it slowly increase, then increase even faster. but the bullet never changed speed.
then i just tried making it go faster more simply by doing this:

//step event
acceleration += 1;

nothing worked.

Can someone please explain why this is not working as I thought it would? And also what I should do to make the speed increase the way I want it to?
 

Amon

Member
All your doing is increasing acceleration in the step event without assigning acceleration to the x/y in the step event. From what I can see if that is the only thing in your step event then that will be the only thing that updates. Try moving what you have in the create event to the step event.

EDIT// Only move the move_towards_point function to the step event.
 

SeraphSword

Member
To clarify Amon's point, a Create event happens precisely once, at the moment the object is created. So increasing acceleration afterward does nothing, because the move_toward_point code is already being run with whatever value it was set to originally.

Technically, even after moving it to the Step event, the code you have will probably need to be modified, because within one second the speed would be 60 (moving 60 pixels per step). So you may want to use a decimal amount to increase it by, or use some other method. But maybe a super quick bullet is what you're after.
 
N

nicholaswdawson

Guest
All your doing is increasing acceleration in the step event without assigning acceleration to the x/y in the step event. From what I can see if that is the only thing in your step event then that will be the only thing that updates. Try moving what you have in the create event to the step event.

EDIT// Only move the move_towards_point function to the step event.
To clarify Amon's point, a Create event happens precisely once, at the moment the object is created. So increasing acceleration afterward does nothing, because the move_toward_point code is already being run with whatever value it was set to originally.

Technically, even after moving it to the Step event, the code you have will probably need to be modified, because within one second the speed would be 60 (moving 60 pixels per step). So you may want to use a decimal amount to increase it by, or use some other method. But maybe a super quick bullet is what you're after.

I tried moving it to the step event but then the bullet was basically a tracking missle on they player and went wherever he went.
I need to make it so the trajectory doesn't change, only the speed.
Is there a way to keep it going in the same direction and only make it faster?
 

Nidoking

Member
Grab the player's x and y in the Create event, and call them targetX and targetY or something similar. Then move toward that point in the step event instead of where the player actually is. Better yet, get the direction from the starting location to that targetX and targetY, store that, and move in that direction instead of having a target at all - so you don't have to worry about what happens when the bullet passes that point. It can just keep going in the same direction until it hits something.
 

Amon

Member
I tried moving it to the step event but then the bullet was basically a tracking missle on they player and went wherever he went.
I need to make it so the trajectory doesn't change, only the speed.
Is there a way to keep it going in the same direction and only make it faster?
If you just want it to just fire like a normal bullet then don't use move_towards_point. Just fire the bullet and update its x or y location, depending on the orientation of your screen.
 
N

nicholaswdawson

Guest
Grab the player's x and y in the Create event, and call them targetX and targetY or something similar. Then move toward that point in the step event instead of where the player actually is. Better yet, get the direction from the starting location to that targetX and targetY, store that, and move in that direction instead of having a target at all - so you don't have to worry about what happens when the bullet passes that point. It can just keep going in the same direction until it hits something.

so i put
targetX = obj_player.x;
targetY = obj_player.y;
in the create event

and in the step event did:
move_towards_point(targetX,targetY,acceleration);
acceleration += .2;

looked like it was going to work, but once it got to where my player was at the time of creation, it glitched out, created two, and they slowly drifted, separating extremely slowly.

any ideas of what i can do to fix it so even when it gets to the players previous location, it doesn't freak out?
 
N

nicholaswdawson

Guest
If you just want it to just fire like a normal bullet then don't use move_towards_point. Just fire the bullet and update its x or y location, depending on the orientation of your screen.
Sorry I'm not very skilled in GML,
I'm not sure what else I can use here besides move_towards_point. :(
 

Nidoking

Member
Better yet, get the direction from the starting location to that targetX and targetY, store that, and move in that direction instead of having a target at all - so you don't have to worry about what happens when the bullet passes that point.
This is what I said, and I stand by it, because exactly what you said happened is what I warned you about. You can use lengthdir_x and lengthdir_y to move a specific distance in a specific direction, and you get the direction with point_direction.
 
N

nicholaswdawson

Guest
This is what I said, and I stand by it, because exactly what you said happened is what I warned you about. You can use lengthdir_x and lengthdir_y to move a specific distance in a specific direction, and you get the direction with point_direction.
yeah you warned me and now i understand. I'm trying really hard to understand what you're telling me to do. Can I still use the move towards point function or am i supposed to use instance create now instead?
 
Ok, so what is happening directly is that because you are using move_towards_point the bullet is going to be aiming at a particular point on the screen. Let's say the bullet starts at an x and y of 0, 0 and is heading towards an x and y of 100,100 at a speed of 3 (forget about increasing the speed for now). The bullets x and y position are going to update each step, moving 3 pixels per step. So the first frame it's at an x and y of 3,3, then the next frame it's at x,y 6,6 and so on. Eventually it'll get to 99,99 (the nearest point divisible by it's speed of 3)...On the next frame it'll go to 102,102 (so slightly overshoot) and then the frame after that it'll start to move backwards to 99,99, because remember it is ALWAYS aiming at 100,100 and it'll keep bouncing between these coordinates forever. If we reintroduce the idea of increasing speed, the same thing will happen, but each frame the bullet will move back and forth at greater and greater intervals (instead of it being 99,99 to 102,102, it'll be 99,99 to 110,110 and then to 98,98 and then to 111,111 and so on, this is why it seems like there's "two" bullets that are slowly seperating, because it's jumping back and forth at increasing intervals 60 times a second (or whatever your room speed is)).

One way to fix this, that has already been mentioned by @Nidoking, is instead of moving towards a particular point, simply set a direction and a speed and let the bullet continue in that direction forever. The simplest way is to put this in the Create Event:
Code:
direction = point_direction(x,y,obj_player.x,obj_player.y);
speed = 3;
Now the bullet will move in the direction the player was at the instant the bullet was created, it won't jump back and forth like it would with move_towards_point, because it's not aiming at any particular point, just a particular direction. Now how do we get it to increase in speed? We could do this in the Step Event:
Code:
speed += 0.1; // This number will probably be quite small as even a small speed increase every step will lead to a fairly rapid acceleration
This is the most simplistic version of what you are trying to achieve. As you get better, you'll want to start taking manual control of more and more things, and will probably drop the built-in speed variable in favour of your own custom speed variable (most people name it spd, since speed is already annoyingly taken).

One extra note is that since your bullet is now going to travel in a particular direction forever, don't forget to destroy it when it leaves the room or the screen or whenever is best for your game. Otherwise you'll gradually fill up the processing and memory of the computer with a ton of bullet instances that are all miles away from the play area and aren't needed.
 
N

nicholaswdawson

Guest
Ok, so what is happening directly is that because you are using move_towards_point the bullet is going to be aiming at a particular point on the screen. Let's say the bullet starts at an x and y of 0, 0 and is heading towards an x and y of 100,100 at a speed of 3 (forget about increasing the speed for now). The bullets x and y position are going to update each step, moving 3 pixels per step. So the first frame it's at an x and y of 3,3, then the next frame it's at x,y 6,6 and so on. Eventually it'll get to 99,99 (the nearest point divisible by it's speed of 3)...On the next frame it'll go to 102,102 (so slightly overshoot) and then the frame after that it'll start to move backwards to 99,99, because remember it is ALWAYS aiming at 100,100 and it'll keep bouncing between these coordinates forever. If we reintroduce the idea of increasing speed, the same thing will happen, but each frame the bullet will move back and forth at greater and greater intervals (instead of it being 99,99 to 102,102, it'll be 99,99 to 110,110 and then to 98,98 and then to 111,111 and so on, this is why it seems like there's "two" bullets that are slowly seperating, because it's jumping back and forth at increasing intervals 60 times a second (or whatever your room speed is)).

One way to fix this, that has already been mentioned by @Nidoking, is instead of moving towards a particular point, simply set a direction and a speed and let the bullet continue in that direction forever. The simplest way is to put this in the Create Event:
Code:
direction = point_direction(x,y,obj_player.x,obj_player.y);
speed = 3;
Now the bullet will move in the direction the player was at the instant the bullet was created, it won't jump back and forth like it would with move_towards_point, because it's not aiming at any particular point, just a particular direction. Now how do we get it to increase in speed? We could do this in the Step Event:
Code:
speed += 0.1; // This number will probably be quite small as even a small speed increase every step will lead to a fairly rapid acceleration
This is the most simplistic version of what you are trying to achieve. As you get better, you'll want to start taking manual control of more and more things, and will probably drop the built-in speed variable in favour of your own custom speed variable (most people name it spd, since speed is already annoyingly taken).

One extra note is that since your bullet is now going to travel in a particular direction forever, don't forget to destroy it when it leaves the room or the screen or whenever is best for your game. Otherwise you'll gradually fill up the processing and memory of the computer with a ton of bullet instances that are all miles away from the play area and aren't needed.
That is EXACTLY what happened! This makes so much more sense now I cannot thank you enough.
And as for the code, it worked perfectly. I was so frustrated because I couldn't figure out an alternative. Thank you and @Nidoking I really appreciate your alls help!
 
Top