ochadenas / cpudefense

A tower defense game for Android based on a microprocessor theme
MIT License
130 stars 8 forks source link

Attackers trigger more than one chip #114

Closed Kutabu closed 8 months ago

Kutabu commented 8 months ago

Especially in endless mode, it happens that some attackers activate several chips at once. I noticed this when two MEM chips were blocked with one attacker after the recent upgrades. On closer inspection, this also happens to other chips (observed especially in endless mode lv 30+).

The bug mainly occurs when the chips are close to each other and the attackers are very fast. In addition to the double MEM chips, it is particularly annoying in combinations of ACC (first) and a second chip ( for example SHL). As soon as two attackers run across the track/chip almost at the same time, the following bug occurs: The ACC chip should save the first attacker and the SHL ship should affect the second attacker. However, as the first attacker triggers the SHL chip too, it is in the cool-down phase and the second attacker passes the chip(s) unaffected.

The bug can be reproduced when two MEM chips are placed in pause mode and an attacker is between the chips.

ochadenas commented 8 months ago

You mean, they trigger the chip they are coming from and the chip they are going to?

That may be right ... will have a look at it.

ochadenas commented 8 months ago

The issue with the two MEMs acting on the same attacker is fixed in 3.32. Once a number is stored within a MEM, it becomes immune to all other chips, even if it is still visible.

As for the other issue ... although your observation is correct, I do not know how to resolve this. It is true that the chips on both ends of the link "know" of the attacker, and if their ranges overlap, they might fire both on the same number.

However, which one should be refrained from shooting? The correct, or let's say: better, choice depends on many parameters. If one chip is a SHL, and the other a MEM or ACC that swallows the number anyway, then it should better not fire. Unless, of course, the other chip is in its cool down phase and unable to fire. Except if it is near the end of the cool down and will be ready to fire soon. Unless again there is a more dangerous attacker within its range (stronger, or closer to the CPU), that should be eliminated first.

And so on. Since the last version the chips try to act "intelligently", because people were complaining that they didn't. Which means that currently, SUB targets the smallest number and all other the largest number. But this causes exactly the behaviour you are describing.

I fear that however you do it, it'll be wrong.