Як ігрові боти сприймають ігровий світ та інші сутності?

Це питання вже деякий час у мене на думці ... головним чином тому, що я бачу ботів для всіляких ігор, таких як WoW та інші. Моє запитання: як боти знають, що з’являється на екрані? Я не граю в WoW, тому мій приклад може бути неправильним, але якщо, наприклад, є монстр, то як бот знає, де знаходиться цей монстр на екрані і як він знає, як з ним взаємодіяти?

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

Спасибі заздалегідь :)

Є багато моментів, коли бот може ввести себе в гру.

• Екран - один із них, але далеко не найкорисніший. Однак я колись бачив дуже ранній приціл для Counter Strike, який використовував кольорове кодування. Він поставив альтернативні моделі персонажів з однокольоровими текстурами (гра досить зручна для моделювання, щоб це допустити), а потім просто виявила пікселі цих кольорів. Хоча не дуже ефективний метод. Тоді воно вже було досить незграбним, і стає все менш життєздатним, оскільки графічні двигуни стають все більш потужними, а це означає все більше і більше деталей для плутання будь-яких алгоритмів оптичного розпізнавання.

• Ще один момент - це читання пам'яті безпосередньо ^[1] . Можливо, щоб одна програма на вашому комп’ютері читала пам'ять іншої. Тож розробнику просто потрібно з’ясувати, за якою адресою пам'яті гра зберігає інформацію, що стосується бота. Є інструменти, які допомагають розробнику знаходити те, що вони хочуть, створюючи зображення пам'яті та надаючи різні інструменти пошуку. Контрзаходом є використання рандомізації компонування адрес, але розумний бот може все-таки автоматично знайти те, що шукають.

• Можна змінити саму програму гри. Для цього розробникам ботів потрібно вміти читати та програмувати в асемблері, що не так складно з певною практикою. Потім вони шукають код, який обробляє інформацію, яка їх цікавить, і переписують його, щоб передати його своєму боту. Можливим контрзаходом з точки зору розробника ігор є використання обфускатора, щоб зробити код асемблера гри менш читабельним, але це, як правило, не добре для продуктивності, і є інструменти для багатьох обскудаторів, які перетворюють свою роботу.

• А далі є мережевий код. В онлайн-грі сервер передає властивості та позиції всіх об'єктів у грі через мережу. Мережевий потік даних між сервером і клієнтом можна перехоплювати та аналізувати. Популярним інструментом для цього є проводка. Коли розробник зворотної інженерії мережевого коду, вони можуть написати бота, який перехоплює мережевий трафік так само, як це робить Wireshark і використовує інформацію для прийняття свого рішення. Коли розробник більш мотивований, він може навіть з нуля розробити повного ігрового клієнта, який реалізує мережевий протокол і грає в гру, навіть не маючи графічного виводу. Такі боти користуються великою популярністю у золотошукачів, оскільки без графічного виходу клієнт, як правило, набагато зручніший для використання ресурсів, а це означає, що вони можуть запускати багато з них відразу на невеликому сервері.

^1: Оскільки ви згадуєте WoW, варто зазначити, що рання і горезвісна програма ботингу WoWGlider використовувала прямий доступ до пам'яті. У Blizzard була підпрограма під назвою Warden, яка була розроблена для виявлення та блокування доступу сторонніх програм до внутрішнього стану WoW. Оскільки програма бота обійшла цей захист і прочитала пам'ять без дозволу, позов у 2006 році MDY v Blizzard був вирішений на користь Blizzard на тій підставі, що виробник ботів заохочував та дозволяв своїм користувачам вчиняти порушення авторських прав та порушувати DMCA .

Боти - це гравці. Вони просто читають позиції гравця / монстра на сервері, як і кожен інший гравець, і використовують ці значення в поєднанні з простим AI-скриптом для виконання дій у грі, імітуючи обведення клавіатури та натискання миші програмно. Якби боти насправді мали алгоритм для виявлення того, що монстр знаходиться на екрані, та взаємодії з ним, це було б досить вражаючою програмою, яка коштувала б мільйони. Це в основному AI для роботів.

Філіп вже дав чудовий огляд того, як працює більшість ботів, але я просто хотів висвітлити речі дещо детальніше, оскільки у мене є трохи особистого досвіду, що розвивається на або для всіх типів ботів, які він охоплював.

У Runescape був великий проект (RSBot), який би скопіював вміст пам’яті з клієнта Runescape у свою локальну пам’ять, де він міг переглядати весь стан гри, не маючи ризику, щоб клієнт зачепився. Це вимагало трохи зворотної інженерії, щоб визначити, де в пам'яті шукати, щоб знайти вказівники на дані, але як тільки вони це зробили, вони відкрили API, щоб скористатися цією інформацією. Він би точно знав, що було де у світі, отримуючи координати об'єкта, а потім перетворюючи їх матрицею перетворення камери, щоб отримати положення на екрані. Ударні маски також були читабельні, тому було неважливо точно визначити, в який діапазон рухати мишу, щоб отримати бажаний результат.

Бот надав купу налагоджувальної інформації, наприклад, примітки, які вказували розробнику, які координати плитки знаходяться, де, який ідентифікатор має цей об’єкт, який ідентифікатор належить даному елементу тощо. Потім ця інформація може бути використана для створення ботів. Фактичний процес створення скриптів бота був насправді досить простим. Рамка передбачала безліч функцій утиліти, таких як move_to(world_coordinates)або mouse_move(x,y)які могли б виконати зазначені дії дещо правдоподібно (переміщення миші по випадковому сплайну, багаторазове переміщення як мінімапи, так і екрану тощо)

Також у Runescape у вас є можливість різко знизити якість графіки. Створювати певні види ботів було насправді досить просто, знімаючи екран і застосовуючи основні концепції комп'ютерного зору, щоб побудувати модель світу. Я зробив як проклятий бот, так і плавильний бот, використовуючи цю техніку, обидва вони працювали досить добре. Він просто візьме кадр, збільшить насиченість наскільки це можливо, а потім спробує витягти з нього шаблони, які потім могли б створити карту ймовірностей для зон клацання.

У випадку з проклятим ботом, ціль була меншим демоном, що є просто величезною червоною річчю, яку тривіально знайти. Що стосується плавильного бота, то він шукав би маленьку помаранчеву трапецію, оточену сірим кольором, і це була б піч. Він також намагатиметься знайти велику світло-сіру форму L, яка була б банківським столом. Це було щойно зроблено із зменшенням шкали та базової евристики. Він також міг зорієнтуватися за допомогою зручного компаса поруч із мініматою, тому міг орієнтувати камеру у більш надійному положенні для пошуку цільових об’єктів.

У різних іграх Nexon сервери дуже довіряють своїм клієнтам. Я зловживав цією тоною в Maplestory, змінюючи карти, щоб усунути небезпеки або додати основи, щоб бот не повинен бути майже таким же складним. Я також контролював би трафік на сервер і з нього, щоб побудувати модель світу, яку потім можна було б використовувати для швидкого пошуку та вбивства монстрів.

Як тільки я зрозумів, що насправді більше не граю в MMO, а просто автоматизував їх, я вирішив припинити гру. Якби я не так переживав, щоб викрити себе на законних підставах, я, певно, міг би вчинити вбивство, продаючи боти MMO, але я справді не хотів подавати до суду. Ось чому я витрачаю свій час на справжнє програмування!

Відповідь Філіпа чудова, але лише коротка примітка про модель "Модель / Перегляд / Контролер" або короткий MVC.

Ваш екран є частиною "перегляду", в якому представлені дані з "моделі", що є реальним станом гри, якщо вам подобається. Боти та ваш персонаж все «існують» (у певному сенсі) в межах моделі. Уявіть собі, якби ви відключили екран - гра продовжувалася б, навіть якщо подання не було.

У мережевій грі поняття "моделі" трохи складніше, оскільки у вас насправді багато моделей. У вас є модель на сервері, а потім модель кожного клієнта, яка частково оновлює себе завдяки даних, які він отримує від сервера. Ви можете подумати про "модель" як про те, що охоплює модель сервера та модель вашого клієнта, або ви можете вважати це просто моделлю свого клієнта. Так чи інакше, тут живуть боти. Отже, їх "сприйняття", яке ми могли б використати як скорочення для введення даних та стану, ґрунтується на стані моделі на той час та взаємодії між різними об'єктами / об'єктами в межах цієї моделі. На практиці кожен бот може мати функцію під назвою "refreshState", яка запускається один раз на кадр чи щось таке, і що змушує його оновити "

Вони можуть читати координати з файлу чи сервера, але також із системою виявлення променів зіткнення. Зазвичай застосовують промені, що йдуть від бота (у такому випадку) до його зовнішнього. Якщо промінь стикається з чимось, то він повертає деяку інформацію до бота, наприклад, якщо те, що знайдено промінь, був гравцем, ботом, твариною чи простою стіною. Це відбувається тому, що, наприклад, у гравця та бота у них є невидима капсула, яка повністю залучає їх, наприклад, інформацію про його тип (людина, бот, ...). Завдяки цьому вони можуть уникнути зіткнення зі стінами та іншими елементами, якщо вони, наприклад, слідують за вами.

Ви можете побачити частину виявлення зіткнення цієї сторінки