6 ms·

Exactly my thoughts after Elon Musk's tweet: https://twitter.com/elonmusk/status/896163163581825025 https://twitter.com/elonmusk/status/896163163581825025 Unle

by fridek 9y ago

Exactly my thoughts after Elon Musk's tweet: https://twitter.com/elonmusk/status/896163163581825025 https://twitter.com/elonmusk/status/896163163581825025 Unless AI is constrained to pro player max pointer move delta, click rate, and vision latency, I don't really see much difference between AI and a team of kids running with aimbot shouting "cyka cyka".

hobofan 9y ago
> 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.
- thewhitetulip 9y ago
  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 :)
  - hobofan 9y ago
    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.
    - thewhitetulip 9y ago
      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.
- gpm 9y ago
  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.
  - hobofan 9y ago
    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.
    - gpm 9y ago
      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".
      - hobofan 9y ago
        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.
        gpm 9y ago
        If they did than then they are simulating latency, but I see nothing to suggest they did that.
deleted 9y ago
[deleted]
alkonaut 9y ago
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.
- Bartweiss 9y ago
  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.

by fridek 9y ago

hobofan 9y ago

> 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.

thewhitetulip 9y ago
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 :)
- hobofan 9y ago
  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.
  - thewhitetulip 9y ago
    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.
gpm 9y ago
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.
- hobofan 9y ago
  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.
  - gpm 9y ago
    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".
    - hobofan 9y ago
      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.
      - gpm 9y ago
        If they did than then they are simulating latency, but I see nothing to suggest they did that.

deleted 9y ago

[deleted]

alkonaut 9y ago

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.

Bartweiss 9y ago
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.