А не проще было выловить запрос, который скорее всего шлет игра на сервер для записи рекордов, и подменить там значение? (Если есть сигнатура запроса, можно декомпилировать флешку и вытащить алгоритм подсчета.)
Но конечно очень похвально и круто, что Вы выбрали подходящий язык для подобной цели!
Всегда пожалуйста!
Вопрос изначально был не в том, чтобы получить много-много очков (там даже рейтинга публичного нету, только среду друзей), а в том, чтобы переложить функции игрока на компьютер. А дальше уже азарт игрока заставлял пытаться набрать больше. =)
На форуме русского сообщества AutoIt есть целый раздел посвященный бототоводам, где всегда можно обменяться ценной информацией. Правда в основном там содержатся или запросы на написание бота, или самореклама, но иногда попадаются и очень полезные статьи.
А ещё WindowsConstants и Constants. Вот все необходимые файлы — zalil.ru/31585482
После этого нужно прописать путь к template.bmp, в DD_Habr.
Теперь следующая загвоздка, при запуске ошибка —
C:\Users\LostSenSS\Desktop\DiamondDash\ImageSearch.au3 (40): ==> Subscript used with non-Array variable.:
if $result[0]=«0» then return 0
if $result^ ERROR
Это ошибка DLL-ки ImageSearch. Возможно из за того что ее битность не совпадает с битностью системы. Сейчас выложу обе версии.
Еще есть вариант, что ее надо класть не в папку со скриптом, а в Windows(или любую другую прописанную в path)
— попробуйте эту, мне помогло.
Кстати, у меня получилось набрать максимум ~ 400 000 очков, при большом числе эффектов картинка начинает тормозить, машина слабовата.
Всё получилось.
Скачал с буржуйского форума отдельно ImageSearch.
Тут необходимые файлы и скомпилированный exe файл, если кому-то лень возиться :) zalil.ru/upload/31585781
у меня данный архив как бы работает хоткеи пашут, но при нажатии на F2 вылетает «corner template wasn't found», хотя окно открыто, template.bmp рядом с файлами из архива.
На самом деле это мой косяк. В последней версии путь до template.bmp остался абсолютным, хотя нужно было сделать просто «template.bmp». На гитхабе залил новую версию.
Посмотрите Sikuli.
Я ей пользуюсь для таких вещей.
Программируется на jython. Использует OpenCV для обработки экрана, в результате все очень быстро…
Да и вообще, удобная весчь…
Посмотрел на демку на их сайте, где они автоматизируют ввод сетевых настроек в MacOS. Интересная штука, но не скажу, что финальный результат там быстро работал. Наоборот. Чё-то по целой секунде оно находит кнопки.
Итак, я запустил-таки скрипт, с увлечением наблюдал за его работой, и теперь хочу задать несколько вопросов. Возможно, если подумать над ними — может и получится преодолеть рубеж в 2 кк очков.
1 — периодически бот начинает затупливать в конце игры (последние секунд 20-15) и тыкать абы-как, куча ошибок, цепочки не составляет, рамочка не загорается. Хотя (при дальнейшем наблюдении выяснилось) в этом может быть виновата сама игра, т.к. после пяти раз за раунд загоревшейся рамочки — она попросту не активируется. Возможно — программное ограничение самой игрушки.
2 — бриллианты — отдельная тема, самый высокий кпд у них — в последние 15 секунд (если избавиться от первой проблемы — тупняк в конце игры. Ну и как только доска сверху начинает пустеть — бриллианты могут помочь с её наполнением. Может, стоит учесть это в их использовании и выявлять их положение на доске каждый раз, как делаем скриншот, и знать, что у нас есть брюлик, если доска полупустая?
3 — совсем брутальный вопрос по улучшению поведения бота: есть такая вещь, как тетрис-бот. Он анализирует следующие выпадающие блоки и выстраивает комбинации ещё до того, как блоки выпадут. Может имеет смысл снизить скорость скрипта, но заставить его делать клики, которые приведут к бОльшим комбинациям через 2-3 хода (т.е. заставить его при прочих равных делать ход, который приведёт к объединению цветового массива)? Хотя (учитывая поведение игрушки в конце партии (произвольная смена цвета кубиков на поле) — все усилия могут сойти на нет.
Ну по порядку:
1 — начало или конец партии — не должно иметь значения для работы скрипта. Возможно начинает тупить из за снижения FPS. Насчет загораний рамки — ограничений не замечал, единственное ограничение которое приходится учитывать — на количество ошибок (или на процент ошибок, не знаю). Если часто ошибаться, то звук кликов становится монотонным, а рамка перестает загораться. Именно для того, чтобы этого не происходило добавлена задержка между кликами.
2 — алмазы вроде и сейчас неплохо определяются. У меня в конце минуты редко остается больше 1-2. Если у вас есть идея по эффективному выявлению алмазов при появлении — предлагайте, испробуем. =) Насчет того, чтобы кликать на них когда доска полупустая (а не когда только нашли)- пожалуй стоит попробовать, займусь этим.
3 — в начальных версиях скрипта были различные алгоритмы просчета на несколько ходов вперед. Но есть два фактора сводящие их эффективность на нет. Первый — спецэффекты и ошибки. ВТорой куда более важен. Если внимательно присмотреться к полю, то можно заметить, что довольно часто квадратики меняют свой цвет, чтобы составить новую область. Сделано это видимо для того, чтобы всегда было куда можно кликнуть. И такие смены, понятное дело, не дают нормально просчитать все.
Да и когда все взрывается мне кажется очков капает больше чем за большие комбинации с длинным просчетом.
да, у флеша то ли GC то ли общая криворукость разработчиков обычно просаживает фреймрейт после первых 3-5 минут, при этом степень просаживания может составлять порядки.
писал подобное на delphi для mail.ru
1.5 секунды на сканирование цветов поля это сильно много.
в игре Филлер на меилру в текстураз кубиков применяется дизеринг, в итоге пришлось измерять цвета соотношением составляющих
например если R > G > B то это красный работало с дикой скоростью.
Мне не жалко, просто грустно, когда статьи по тематике блога набирают максимум +50, а читерный скрипт, не имеющий собственно к разработке игр никакого отношения, легко уходит за +100 :)
P.S. если на это глаза закрыть, статья хорошая, я плюсик поставил :)
Я ведь и не говорил, что это не интересно, даже наоборот, подчеркнул, что поставил плюс :)
Просто посетовал на то, что статьи по разработке игр не набирают так легко своих ста плюсиков :)
P.S. признаю, возможно я слишком категорично сказал «не имеющего никакого отношения», конечно разработчику игр нужно знать как работают читы или как пишутся кряки
Я думаю, что большее количество людей способно оценить подобный скрипт, нежели обзор игрового движка или еще что-то такого рода.
Да и в принципе тема играния в игры ближе большему числу людей, чем тема разработки игр.
Автор не могли бы вы сравнить AutoIt и AutoHotKey, они очень сильно похожи, но хотелось бы узнать ваше мнение, я сколько ни пробовал AutoHotKey всегда прощще мне казался и удобнее AutoIt-а.
Может кто-то раскроет правду?
Если вам не сложно, то немогли бы вы снять видео с экрана во время игры бота. Не хочется возиться сейчас с установкой AutoIt, но очень любопытно посмотреть как это когда набирают полтора ляма очков ))
Ну ставить ничего не надо, запустится по даблклику, но видео сниму. На самом деле собирался сделать видео еще перед публикацией, но в 5 утра лениво стало.
В такого рода игрушках обычно дается гораздо больше очков, если уничтожается большое количество камней за раз.
Может есть смысл сделать алгоритм, который 90% времени будет собирать большие пятна правильно убирая мелкие, а в оставшееся время соберет с больших очки.
Чуть выше отвечал на подобный вопрос.
К сожалению так сделать не получится (по факту большие комбинации возможны только когда сразу падают сверху), кроме того в игре могут произвольно меняться цвета некоторых уже упавших кубиков, да и за взрывы дают очень немало очков. С нынешней скоростью бота почти всегда половина поля пустует.
Я не пытаюсь что-то доказать автору, но всё же вместо «безрекурсивного поиска в глубину» было бы проще и правильнее написать поиск в ширину, который «безрекурсивный» сам по себе.
Ну была бы вместо стека очередь, и что?
А для реализации ее на массиве нужно хранить 2 указателя (head и tail), вместо одного у стека. Кроме того места в памяти больше занимает. =) Мелочи это все конечно, но к вопросу о «проще».
Ну скажем так, для оптимизации часто разворачивают рекурсию в стек, а DFS со стеком (а не с рекурсией) наверное более правильный чем рекурсивный, просто во втором случае писать чуть меньше.
Интересно, спасибо. Я сам вот играю и написал бота для более известной игры — Травиан. Автопостройка, увод войска в лес, Фарм по расписанию и много чего ещё. Всё на C# и запросах к серверу (без gui, онли консоль). Если кому интересно, велком в профиль карму поднимать xDD
Хороший пример того, как из бессмысленного занятия типа игр для домохозяек и 12 летних детей может вырасти что-то весьма интересное и профессиональное. Спасибо вам.
Написал свой вариант бота, на Java + JNA (про awt.Robot только сейчас узнал), стараясь не подглядывать в текст статьи. Во многом идеи совпали, но есть и отличия (например, в принципе задержек и в выборе места для клика). Сомневаюсь, впрочем, что это стоит отдельной статьи.
Результат, полученный запуском скрипта время от времени спустя несколько дней:
Пришел к выводу, что вряд ли удастся набрать значительно больше подобным методом — все упирается в длительность анимаций в самой игре.
Интереснее решать более алгоритмические задачки, например взять игру play with friends. Вот там более широкое поле для воображения, но только вот из-за пошаговости будет тяжело отлаживать бота.
Написание макроса-бота для браузерной игры