Being combat-tagged in a PVP game means the game recognizes you are currently in combat against another player. Combat-logging then means disconnecting during a fight (usually when you’re about to die) so your opponent won’t be able to loot your corpse nor be awarded the kill. Any respectable game will punish combat-loggers, but the implementation of detecting this can vary between games.

To solve this issue for a Minecraft PVP minigame I was working on, I came up with the following design. Although the idea was conceived with a Minecraft minigame in mind, the design can be applied to any PVP game.

All players keep track of an attacker data field. This is similar to Minecraft’s built-in on attacker, but lasts longer than 5 seconds. Here’s how the field works:

1. If you attack someone, that player’s attacker field is set to you.
2. If you attack someone, and yourself do not have an attacker set, the person you just attacked becomes your attacker. Why?
3. If you do not damage — or take damage from — any players in 30 seconds, your attacker field is cleared.
4. (obviously) If you die and your attacker is set, your attacker is awarded the kill.

That’s it!

Intuitively, since you’re combat-tagging someone when you start a fight with them, players should keep track of their target (each player keeps track of who they attacked last), right?

The first problem with setting a target field is that it does not account for a player going against multiple enemies. If you attack enemy A then enemy B, then enemy A dies by environmental damage a few seconds later, that kill should still count as yours.

The second problem occurs if you lose the fight and die. For both A and B, you were the last person they attacked, so do they both get kill credit?

Both stem from the fact that kill credit must be one-to-many: one player can kill multiple enemies, but you can only be killed by one player, which is why flipping the direction of the data solves it. But there’s a third, more subtle problem:

• Imagine A is attacked by B, and A has no target. Per rule 2 earlier, A’s target is B.
• Then B is attacked by C. Logically, B’s target should be set to C, but it doesn’t happen because B already has a target.

At this point, if C dies without B doing anything, B does not get credit for killing C; but if B dies without A doing anything, A does get credit for killing B. Clearly that’s kinda unfair, but why are we giving A credit at all if they didn’t do anything?

The simple reason is that if you start a fight and then lose it, the person you picked on should get credit even if they didn’t land a hit on you. In the case of Minecraft minigames, it also seeks to compensate the fact that Minecraft doesn’t credit kills without physical contact. If you baited your enemy into an insta-kill dripstone trap but didn’t punch them beforehand, you don’t get credit. Servers like Hoplite mitigate this by also checking for e.g. who placed the dripstone block that did the kill, but that requires non-vanilla plugins if you want to do it efficiently.

However, it’s important that the above paragraph only applies to 1v1 scenarios. If someone else did do direct damage, then obviously, whoever did direct damage last should be credited for the kill.

Let’s revisit the earlier scenario with three players:

• A is attacked by B, and their attackers are set to each other.
• B is attacked by C. B’s attacker is now C (obviously), and C’s attacker is B per rule 2.

After C’s attack, A is no longer the last person to be in contact with B. Sure, B couldn’t have died without A’s insta-kill trap, but maybe C hit them into the trap? You have to draw the line somewhere, and in this case it’s easiest to draw it at “whoever dealt direct damage last” and chalk everything else up to environmental damage.

Rule 2 also dictates the victim becomes the attacker’s attacker only if the attacker doesn’t already have an attacker, but this is pretty obvious — the victim cannot steal kill credit from someone who has actually done direct damage.