With the correct rates and latencies it should be possible to be fair though?

I.e., if an event occurs in the game, it's placed in a queue and the AI "sees" events pop out the other end of that queue, at a minimum latency and at a maximum rate (i.e. if too many things happen at once the AI is overloaded).

After that the AI makes decisions and puts the command in a command queue. The command queue works the same way: commands pop out the other side (to the game) after a minimum latency and at a maximum rate, to simulate the minimum roundtrip from input to action, and the maximum action rate.

Latency ought to be easily enforced, yeah. The other vagaries of human play, like pixel-precision on mouseclicks and mathematical precision calculating damage and health, are harder to model. But I don't think they'll be impossible, and I think they soon won't be a disaster for the AI.

> Actions accessible by the bot API, chosen at a frequency comparable to humans

I would guess that this already includes all the delays you are asking for.

That's limiting the input bandwidth to the same as what's available to a human, but not limiting the input latency.

Just like with network traffic, they are two different numbers.

Very much depends on how you employ the frequency limits. If you say "You can only do 300 actions per minute", the bot could make all 300 actions in the first second if it sees that as optimal, breaking the latency limits. If you however say "You can only do 1 action after waiting 200ms since the last action", the bot will have to choose one optimal action every 200ms, effectively limiting the input latency.

No. Because the bot can choose the next action at the end of the 200ms, with all the information available then, not at the start.

Bandwidth limits are typically of the "You can only do 1 action (send 1 packet) 200ms since you sent the last packet", not "You can only send 300 packets per minute".

How about "You have to choose an action at the end of 200ms, with the information at the start"?

At the end of the day we can be nitpicky and speculate all day long, but we won't know for sure what they achieved/didn't achieve unless they publish something more concrete than a blog post that is intentionally written in accessible language, which has the side effect eroding some of the more specific measures that were taken to ensure a level playing field.

If they did than then they are simulating latency, but I see nothing to suggest they did that.

No, there is a difference. The human player has to see, react and then shot. The computer has a direct API.

gun.shoot()

as opposed to

image of a gun falls on the retina process the info sent by the eye synapses fired etc

:)

I considered that, and I don't think there is. The frequency of the actions is already a result of the "actual time it takes to executr the action" + "all human delays". If you limit the bot to that frequency, everything is accounted for.

----

EDIT: On second thought, there might be a difference, in that this leaves the bot with more time to think, unless you limit the time of that. Not sure if that would dramatically influence the performance though.

The thing is, every human has a different response time, but the bot doesn't have one. The day a bot will play the game like humans, a physical robot holding a console remote etc then maybe it'd be cancelling out the API advantage that the bot has.

but this doesn't undermine the achievement that they have made. It is phenomenal that an AI can play a complex game like DOTA.