[Discussion] Perfect AFK System

[Bribe]

Looking to review jim7777's Anti AFK System I was reminded of an idea I had some time back for a perfect anti-AFK system.

It would involve:

Checking the player's camera target position and synching it with the other players. If the camera has moved, the player is active.

Checking if any of the three order events have fired. If they have, the player is active (provided he has not shared his units, which is usually the case with AFK lamers).

Checking if the unit-selection event has fired. Though I can't remember if selecting a different player's unit fires that event. I will have to test this one.

What are your guys' thoughts on this one?

 

[shadowvzs]

a question, this not slow down a bit the map if u check everything in short period? (since in longer period can move back to that position the camera)

 

[Bribe]

The camera checking would be done only ever 5-10 seconds (AFK system typically register for >1 minute), for the other things no they won't slow the game down and they didn't slow the game down even on computers as old as the game itself.

 

[Magtheridon96]

hecking if any of the three order events have fired. If they have, the player is active (provided he has not shared his units, which is usually the case with AFK lamers).

Yay

Checking if the unit-selection event has fired. Though I can't remember if selecting a different player's unit fires that event. I will have to test this one.

Yay

Checking the player's camera target position and synching it with the other players. If the camera has moved, the player is active.

This could be optional (Some camera systems do "Breathing" effects by moving the camera up and down at a steady rate)

 

[shadowvzs]

about order check, not only smart order needed to check, coz mostly if somebody dont use right click then he dont play

 

[Meticulous]

Though I can't remember if selecting a different player's unit fires that event. I will have to test this one.

It does.

 

[Bribe]

Well even with selection and camera movement the lack of orders being issued is pretty much indicators that the player is doing nothing as it is. I suppose an AFK system should prompt the user after X time that he doesn't issue orders, tell him he is AFK, then he must check the box that he is not AFK and if he doesn't check it in Y seconds then he is kicked from the game. So no reason to complicate it more than that.

 

[Troll-Brain]

Nothing is perfect.

This thing should be up to the "host", let's say the "master" of the game.
What i mean, that is map specific, and the "host" can decide by itself which player is afk or not, since anyway you can't have a system which will work 100 % of time.

 

[Dr Super Good]

There is no point in an anti-afk system. People can share control...

 

[Troll-Brain]

Share control could be not enough or even inappropriate according to the game.

For example a mini game with no teamplay.

 

[Dr Super Good]

For example a mini game with no teamplay.

Then why is the person AFK? He should just lose time after time.

 

[Troll-Brain]

That would make the game lame (free kills or whatever).

And afk doesn't mean afk for ever, if you really need a sample, think of a map like uther party.

Anyway i'm kind of agree with you, in the sense that is map specific, you can't build one which will work for all maps at any moment.

 

[Magtheridon96]

Instead of building one that will act, you should build one that only determines for how long a player has been AFK.
The user should do the rest himself.

He could also define a constant value that marks a player as AFK so that a function like IsPlayerAfk would return time[GetPlayerId(player)] >= AFK_TIME.

I've always urged people to reduce the number of features their resources have and split them up into many tiny systems because the majority of systems out there are map-specific.

Look at Earth-Fury's Board system for example, it doesn't create a multiboard and update values in it (Multiboard values and parameters are map-specific), it makes it easier for the user to make his own multiboards.

edit

You can detect when a player shares his units.
If a player does that, start "listening" for chat events, selection events and order events where the triggering player is not equal to the triggering player.
Does GetTriggerPlayer() return the player who ordered the unit even if the owner shared his units? I should test this some day.

 

[Troll-Brain]

Well, i'm too lazy to argue more, i just want to answer your edit :

player_unit/player events always refers to the owner, i mean GetTriggerPlayer() will always returns the owner, regardless how the event fired.

 

[Magtheridon96]

Well, dang. I guess I just found a way to never get kicked while playing DotA ^.^

Although, you can render players incapable of sharing units.

If you're ok with not having the ability to let players share units, implement the AFK system, else deal with it :trollface:

 

[Bribe]

Well like I said in the first post, if the units are shared then him being AFK is not such a big deal. Mainly this should be used as a punishment for someone who is not doing anything contributory to the game.

Obviously not all map-types will register AFK as being a "lack of orders being issued". This type of AFK system would simply be used with the standard command-of-unit(s)-oriented gameplay style.

Some examples of stuff that wouldn't work with this: cinematic maps, tower defense (many tower defense maps don't need the player to interact at all times).