Lock on Target!

tomas12343

Hello everyone!

I have a rather difficult task for the strong minds!

For my game I have an actor spawned randomly (called Enemy), and it passes through the screen from the right to the left.
What I want to do is when the player touches the spawned actor,a target icon is spawned on top (following the actor "Enemy") and then a homing missile is spawned to destroy the specified actor.

I tried the following:

------------------
Create a Boolean attribute called "EnemyLifeSpawn"
Create a real attribute called "FollowX"
Create a real attribute called "FollowY"

IN ACTOR "ENEMY":
RULE 1:
When enemy is touched - Change attribute "EnemyLifeSpawn" to true
Spawn Actor "target" On top layer from the actor

RULE 2:
When EnemyLifeSpawn is true:
Constrain attribute FollowX to positionX
Constrain attribute FollowY to positionY

IN ACTOR "TARGET"
Constrain attribute positionX to FollowX
Constrain attribute positionY to FollowY

RULE 1:
When EnemyLifeSpawn is false - Destroy the actor
------------------

Believe it or not, when I touch on the Enemy the system goes haywire!
Sometimes it selects the actor that is coming (not the actor that I am touching,but the next one!
Sometimes the actor target stays stationery
Sometimes the actor target gets destroyed in half a second

ANY IDEAS????

tomas12343

Anyone...??

hotMagic

The logic seems to make sense. If you make debug outputs so that the enemy always shows position x and some dummy object shows followx, are they the same? That's a good way to tell.

tomas12343

Actually what happens is that when GS spawns a new actor,gets confused in which actor will he follow. You see,we have two actors with the same algorithms on the screen. How will GS know which one to follow?

MattGibbard

Can you not spawn an invisible actor that is contrained to the lock on target. The missile just aims towards that actor rather than the actual Enemy.

hotMagic

tomas, I was thinking the same thing, but he only has one possible target, and it constrains its X,Y to a game attribute, right?

Any new objects of that proto wouldnt interfere cause they are set not to output the X,Y unless they are clicked.

So only one of that prototype is designating the position.

And then the target thing follows it. At least, that's if Im reading it right.

RThurman

Perhaps it would be easier to change the image of the enemy actor? When it is spawned, it has a regular image. When it is touched, its image changes to have a target on it. (This would save the headache of constraining another actor to the enemy's coordinates.) Then all you need to worry about is spawning the homing missile and getting it to hit the enemy.

AjBlue

RThurman said:
Perhaps it would be easier to change the image of the enemy actor? When it is spawned, it has a regular image. When it is touched, its image changes to have a target on it. (This would save the headache of constraining another actor to the enemy's coordinates.) Then all you need to worry about is spawning the homing missile and getting it to hit the enemy.

but if the enemy has complex moving animations it would take up a lot of space having to load a whole new set of animations with a target on it. I would think it would be easy to just put target off screen and when actor is touched> constrain target x / y to actor x / y. then the missle could be set to rotate to the target. i would think if the missle is propelled by a move attribute or something that it would be possible for the enemy to shake off the homing missle , like most games do. because the angle of momentum would be facing the target it would naturally drift when turning at too much of an angle.

RThurman

@AjBlue -- There probably is a point in which changing the image starts to become more of a hassle than trying to figure out the logic of interdependent actors. In your example, a complex animation might justify using a separate actor. But even then, adding an extra animation sequence might not be that much of a deal breaker. It might only add a small fraction to overall size of the project and to memory usage.

However, I don't think thomas12343 has that challenge. He simply wanted to have a target stuck on top of the actor (and did not mention anything about animations). Why not just change the actor's image? He can take under 10 minutes to copy and paste the target on top of the artwork (in a graphics editor), or he can spend 10 hours locked in a battle of logic with GS. (Really the logic battle resides within us -- GameSalad is simply following the rules and behaviors we give it.)