I’m trying to make an enemy in my game such that when a player gets within a certain distance of the enemy, it will create an object indicator (the indicator is a large row of arrows) facing the player, and then change its animation to a charging animation, and then once that animation is done, it charges in the direction of the indicator. (The indicator is supposed to appear once the player gets in range of the enemy, and it should face the player when the player first gets in range, but after the indicator gets created, even if the player moves out of the way, the indicator still stays at the same place)
What I want to happen:
When the enemy is within a certain distance of the player, it should create the indicator object, which is a big row of arrows facing the player, then proceed to change into its charging animation, and once that animation is finished, it will charge in the direction of the row of arrows, by applying a permanent force to the enemy and then stopping it a fraction of a second later.
What actually happens:
However, when I first did this, for whatever reason, when the enemy first gets in range of the player, if the player moves while it is creating the indicator, it will create multiple instances of the indicator, which look ugly. I then tried to fix this by making the enemy create the indicator object via the object spawner behaviour so it would only create one, which worked when there was one of such enemy near the player, but it did not work when multiple of them were in range of the player. So, I tried to change it back to how it was before I used the object spawner behaviour, and now its even more broken than before, the enemy isn’t even creating indicators and charging in the direction of them, I don’t know what I’m doing wrong.
Below is the current version of my game code for this enemy (which is probably the most broken version)
The enemy is “rammer” and the indicator is “rammerAimer”
Uh… Do you use ‘for each’ condition for your rammer object?
If I were to do this, the logic I’d follow might go like so:
Set an object variable on the rammer.
Let’s say, a text variable ‘rmode’ initially set to “guard”
At beginning of scene (or when a new rammer is created)
repeat for each rammer:
start a timer “ramtime”
pause “ramtime”
Condition:
rammer distance to player is below 640
rammer variable rmode = “guard”
__repeat for each rammer Action:
create ramAim
link ramAim and rammer
rotate ramAim towards player
turn off pathfinding
change rammer animation to “charging”
change rammer variable rmode to: “prep”
Condition:
rammer variable rmode= “prep”
animation is finished
__repeat for each rammer Action:
unpause timer “ramtime”
change rammer animation to “normal”
change rammer variable rmode to: “banzai”
Condition:
rammer variable rmode = “banzai”
__repeat for each rammer
take into account ramAim linked to rammer Action:
add instant force to rammer toward ramAim.angle() and length 160 pixels
Subcondition:
if timer “ramtime” is greater than or equal to 0.35 sec
Action:
change rammer variable rmode = “cooldown”
Condition:
rammer variable rmode= “cooldown”
__repeat for each rammer
if ramtime is greater than or equal to 0.5 sec
take into account ramAim linked to rammer Action:
delete ramAim
reset timer “ramtime”
pause timer “ramtime”
turn on pathfinding
change rammer variable rmode = “guard”
So yeah, I believe it would go something like that.
I hope that makes sense.
I tried something like your idea here, the problem is that it doesn’t work when there’s multiple of them near the player at once. By the way, I don’t want them to all charge at the player at once, I want them to charge at the player on their own accord, which means based on when they individually get within range of the player
Forgive me, but I somehow don’t see how it wouldn’t work…
The screenshot of the events you put up, I don’t see a “for each” on there. That, I believe, is what you need.
What “for each” does is that only the ones that fulfill the distance condition execute the events under it. So those that are too far away are not included in that “for each” and thus will just go wander about or do according to whats written for them if their rmode variable=“guard”.
I am actually using this very logic in one of my projects. I’m still out at the moment. But when I get back and you still haven’t got it to work, I’ll try dig it up.
Sorry for the wait, i had a lot of other things to attend to during the period you posted this until now
I tried something like this, and it largely works, but with a weird visual result that I don’t want
Below is the code i changed it to, and the weird result that i was talking about
(The white circular thing in the middle of the rammers is the spawner, dont worry about that, its working perfectly fine)
Some stuff you might want to look into, though I’m not sure exactly which part causes the multiple objects getting created.
In the actions “Wait 0.30 seconds”
Whenever I try to do something similar to this, certain things have a tendency to get executed multiple times. So maybe you could setup an alternate way of doing the actions using a timer instead.
rammer is the primary object that has already been called in this set of conditions. You’d want to “take into account” the secondary object. So perhaps it might go thus:
[Take into account all “–rammerAimer” linked to “rammer”]
It seems kind of redundant, though i’m not particularly sure how that is supposed to work… Mind you, I’m not some pro or anything, so if that action has some specific use that I don’t know about, please do explain to me. I might find it handy in the future.
Here it looks like you’re using an extension. I don’t know how it works but I tend to do these things manually. So in my projects when an object is “dead” it is henceforth deleted. Once deleted, it can no longer be called in other events. If that is the case here, that rammerAimer is not going to get deleted as a consequence. But if I am wrong and the extension does manage the deletion of the linked object, then please ignore this number 4 part.
I have a strong suspicion that the “wait 0.30 seconds” is your culprit. Although I don’t exactly know how since it’s not in the same event box as the create rammerAimer action. As an alternate approach you might note in the sample clip I shared, CraftPointers are not dynamically created when needed. They are created and linked with their corresponding bulldozers for life. Though if you do have a lot of rammer objects going around and want to reduce the number of objects in the scene, your dynamic creation approach might be preferred.
