Possible Client Combat Optimization: "Player is attacking Enemy" instead of "Player executes attack"

[rezecib]

Now, I'm not sure this is exactly how it works, because the net code is less available/readable to me, but from playing my impression was that, at least if you're using keyboard commands, this is how the client communicates with the server in combat:

 

Player holds F to attack a nearby enemy (spider). When the spider appears in range on the client, the client says to the server "Okay, player is executing an attack on the spider". The client then shows the attack animation, and if the spider was in range on the server, the client hits.

 

If this is actually how it's working, then it opens up some loopholes for bad behavior, mainly that if the client player isn't actually in range, they're doing a useless attack animation. In laggy situations, this can mean that even though they're holding down F, the spider gets an attack in before they can.

 

If possible, it might be better to do this as follows:

 

Player holds F to attack a nearby enemy (spider). The server registers that the client has requested an attack on the nearest enemy. The client player then moves to and attacks the closest enemy on the server (even if the client may have a different closest enemy).

 

In the case of using the mouse to attack, it may already be doing this, but instead of telling the server to attack the nearest thing, it can tell the server to attack that specific enemy.

 

Granted, this opens up scenarios where the prediction looks bad (client is attacking the spider closest to them locally, but on the server a different one is closer, and that's the one showing its on-hit animation), but it at least transforms a damage-related bad scenario for a cosmetic bad scenario.

Edit: I wanted to add that this could also be extended to pretty much all keyboard input (space bar interactions are directly analogous), which at the moment is, in practice, inferior to mouse input due to the way it interacts with lag. If you click on a location to move there, you will move there at your normal pace, with whatever delay you have on starting to move. If you use WASD in laggy conditions, on the server it looks like you're taking tiny steps and stopping, presumably because these are gaps in which the server is not getting the message that you're still moving. It seems like it would make more sense for the client to send the time of key down and key up for direction keys, rather than periodic "I am moving in x direction". The obvious mishap here is uncontrolled continuous movement into say, a bee field or a group of spider dens. This could be reduced a bit by sending periodic "key is still down" messages, and having the server time out movement after twice (exact amount may need tuning) that period without a "key is still down" message.

[Isosurface]

Klei should consider implementing auto-move and auto-combat system (toggle on/off by user). Instead of telling the server to swing a weapon once or walk one step to the east per click/tap, we send start/stop combat/movement commands to the server and the server will take over entirely until we say stop. Let the AI control a player like an ordinary mob (tank) or like a pigman (kite, use hit-and-run cycle).

 

Also, there should be an toggle-able auto-retaliate option. When you get hit, the server takes over and automatically engages the enemy until the client intervenes.

 

 

Controlling players using the existing AI should be no more difficult than controlling a follower (pigmen can automatically fight treegaurds, and Chester can move and teleport). It shouldn't be difficult to implement.