How do I stop my laser from destroying two items with one shot? (game design)

[Darkmisc]

TL;DR Summary

When the collision shapes for two on screen items overlap, the player's laser can sometimes destroy both items with one shot. The laser is only supposed to destroy one item per shot.

Hi everyone

I'm making a game in which a player's laser can destroy enemies and cancel out enemy lasers. My code for the player laser executes queue_free() when it enters the collisionshape for the enemy laser and enemy. The player laser is only supposed to destroy one item per shot.

Sometimes, the collision shapes for the enemies and enemy lasers overlap while they are very close to the player. If the player fires the laser at this moment, the laser will destroy both items.

At first, I thought the problem was that the player laser instances inside the collision shapes of the enemy and the enemy laser. This would eliminate both collision shapes with one shot.

I tried fixing this with the following code [from enemy_laser scene]:

func _on_enemy_laser_area_entered(area):
    if area.is_in_group("enemy"):
        ENEMYPOS = Global.enemies_pos
        share_space = true       

    if area.is_in_group("laser"):
        if share_space:
            if position.x<= Global.enemy_laser_pos:
                print("laserdestroyedpos=" + str(position))
                Global.enemy_laser_pos=1280
                $Sprite.visible=false
                $CollisionShape2D.set_deferred("disabled", true)        

        if share_space == false:
            Global.enemy_laser_pos=1280
            queue_free()

It's supposed to detect when the enemy and enemy laser overlap. When this happens share_space == true.
If the laser enters while share_space==true, the laser is supposed to queue_free the element that is closest to the left of screen (I have corresponding code for this in the enemy scene).

This code didn't fix the problem.

Then I thought if I instanced the player laser further to the left (from within the player), it won't instance into the overlapping collision shapes. Instead, it should only enter a collision shape as the laser moves from left to right. However, the laser will still sometimes destroy two items with one shot (when fired close to the items).

Does anyone know how to fix this problem?

Thanks

 

[DaveC426913]

It's a feature!

 

[Baluncore]

Give the laser_shot object a tag that says if it has been used.

 

[jedishrfu]

As dave said why not consider it a feature. Perhaps you could reduce the strength of the laser after it hits the first object so that its not as strong when it hits the next one.

Now you could add shields that deflect some or all of the laser light and allow for reflection hits and all sorts of unpredictable things.

I remember playing laser tag once (corporate team building exercise) and realized you could shoot at the mirrors in the room to get a player and I quickly racked up points until others caught on. I may have shared my secret in the interests of fair play then again maybe not.

 

[Darkmisc]

Give the laser_shot object a tag that says if it has been used.

Do you mean something like a global variable used = true/false?

 

[Darkmisc]

As dave said why not consider it a feature. Perhaps you could reduce the strength of the laser after it hits the first object so that its not as strong when it hits the next one.

Now you could add shields that deflect some or all of the laser light and allow for reflection hits and all sorts of unpredictable things.

I remember playing laser tag once (corporate team building exercise) and realized you could shoot at the mirrors in the room to get a player and I quickly racked up points until others caught on. I may have shared my secret in the interests of fair play then again maybe not.

Coincidentally, I have mirrors in my game too. I need the lasers fired to match the number of items destroyed because if they don't, the extra laser will reflect off a mirror and kill the player.

 

[jedishrfu]

Doesn't that make the game more exciting?

Its like the scene in The Hunt for Red October where the Russian captain of the hunter sub shoots a torpedo but removes some distance limit allowing the torpedo to miss Red October and circle around and kill his own sub.

 

[Darkmisc]

I think so. It stops the player from spamming lasers and forces them to be careful.

 

[Baluncore]

Do you mean something like a global variable used = true/false?

It could be global, but I thought a laser would be an object with parameterised performance, activity status and variables such as location.x and .y, and the direction of fire. That way, you can have an array of lasers and an array of enemies operating at the same time. If the direction of fire was a unit vector, then collision detection between the enemy and the laser beam could be done very quickly by subtracting vectors as complex numbers and comparing ratios.

 

[jack action]

How come the laser doesn't get destroyed when it hits the first target? I mean, what prevents the laser from hitting a second enemy or laser, and why isn't it working when "they are close together"?

 

[Darkmisc]

How come the laser doesn't get destroyed when it hits the first target? I mean, what prevents the laser from hitting a second enemy or laser, and why isn't it working when "they are close together"?

I'm not sure. The laser should queue_free upon entering the collision shape of an enemy or enemy laser.
When I instanced the laser in front of the player, there was a chance that it would appear inside the overlapping collision shapes of the enemy and enemy laser. It made sense that the player laser might destroy both items before it queued free.

Now, I'm instancing the laser within the player. It should have to travel left to right before it hits something. In theory, it should only hit one item at a time, unless there is a precise moment when the enemy and enemy laser collision shapes perfectly overlap, and the player laser strikes at this moment. However, the player laser is destroying two items with one shot too often for me to think that this is the cause.