Предложения по улучшению производительности клик-бота

Question

Я работаю над ботом, который играет в простую флэш-игру, требующую от игрока нажимать на несколько быстро движущихся целей, а именно:

Мой текущий алгоритм -довольно просто:

1. Захват изображения на экране
2. Проход по пикселям на изображении на экране и сравнение их значений RGB с известным значением RGB целевого изображения
3. Вернуть координаты, где найдено совпадение
4. Переместить указатель мыши на координаты и нажать

Код алгоритма поиска выглядит следующим образом:

    public Point findImg(BufferedImage img) {
        screen = bot.createScreenCapture(screenRectangle); // Image of screen
        int target = 2424318; // RGB value to look for
        int rgb;

        // Approximate boundaries (400,200) and (1000,700) of the flash game were           
        // hardcoded in
        for (int i = 400; i < 1000; i += 5) {
            for (int j = 200; j < 700; j += 5) {
                rgb = -(screen.getRGB(i, j));
                if (rgb == target) { // Target found
                    return new Point(i, j);
                }
            }
        }
        return null;
    }

В настоящее времябот способен поразить около 75% целей.Тем не менее, он регулярно не может поразить быстро движущиеся цели и по сути "преследует" их по экрану.Я предполагаю, что это потому, что мой алгоритм не может найти их достаточно быстро.Я пытался увеличить размер шага в пикселях, но это, похоже, не дало заметного эффекта.Любые предложения будут оценены, спасибо.

Answer 1

Вы не учитываете задержку в системе (это то, что игроки делают почти автоматически).Флэш-игра, вероятно, оценивает щелчки фрейма после их получения.Двойная буферизация и vsync оба добавляют задержку.Все это должно закончиться, прежде чем снимок экрана сможет захватить изображение.

Чтобы поразить быстро движущиеся цели, вам нужно будет провести некоторое отслеживание.Если вы сможете выяснить, где находится ваша мисс , вы узнаете, насколько далеко она находится за целью.В противном случае, возможно, ваш код сможет распознать, когда последовательные промахы находятся рядом друг с другом, и делать все больше и больше шагов, пока вы не нажмете что-то.

Answer 2

Совершенно очевидно, что вы не можете «поймать» быстро движущиеся цели, потому что к тому времени, когда ваши два цикла for завершат обработку этого огромного экрана, цель переместится в другое место, поэтому ваши клики определенно будут «следовать» за более быстрыми целями.Вместо этого, если возможно, установите «зоны поражения цели».Допустим, вы поражаете цели только в центральной части экрана.Таким образом, вы можете значительно сократить количество сравнений.Вы также можете иметь несколько зон поражения цели.Это зависит от того, где эти цели происходят.Если они приходят, например, с боков экрана, то имеет смысл иметь зоны поражения цели там.

Кроме того, если вы не получаете «штраф» за несколько щелчков мышью, то лучше щелкнуть во многих разных местах вокруг соответствующего пикселя.Так что, если вы обнаружите, что (450 500) - это совпадение, то имеет смысл нажать (450 500), (455 500), (445 500), (450 505), (450 495) и т. Д., В зависимости от диаметра цели.(т. е. сколько пикселей в ширину), а также насколько ваши текущие клики отстают от цели.

Надеюсь, это поможет.

Answer 3

Во-первых, используйте максимальный шаг, который вы можете: это размер самого большого однородного квадрата, вписанного в целевую форму (внутри центрального диска). Вы убедитесь, что цель не может быть пропущена.

Если этого недостаточно, чтобы позволить вам нажать на время, вы можете предпринять две меры:

1) уменьшить зону поиска с учетом максимальной скорости цели и поиска вокруг предыдущего местоположения;

2) прогнозировать, где щелкнуть, оценивая скорость и направление цели (при условии, что они остаются постоянными); Вы делаете это путем сравнения целевого местоположения в последовательных кадрах.

Эти две стратегии можно комбинировать, но обязательно запомните параметр времени: чем быстрее будет поиск, тем меньше коррекция смещения на основе оценки скорости. Вам нужно будет предсказать время, необходимое для поиска, чтобы оценить смещение.