Комментарии 30
Было бы еще интересно почитать про внутренне устройство ботов поподробнее. Как они «видят » монстров? Как переключаются состояния? Как достигается поведение, аналогичное поведению реального игрока (как оно корректируется)?
Боты общаются с игрой не через UI, а непосредственно вызывая те или иные функции, которые есть в игровом клиенте. Поэтому на ботах хранится список всех объектов окружающего его пространства — мобы, лут и прочее. В связи с чем достаточно просто пробегать по этому списку, который постоянно обновляется, и выбирать нужные элементы.
Состояния могут переключаться, как в связи с завершением состояния — из состояния «бег» вышли по ветке «добежали», так и в связи с каким-то внешними событиями — случился телепорт.
Есть дизайн, разрабатываемый гейм-дизайнерами, в котором указаны конкретные времена для конкретных активностей. Боты должны выдерживать этот дизайн.
Состояния могут переключаться, как в связи с завершением состояния — из состояния «бег» вышли по ветке «добежали», так и в связи с каким-то внешними событиями — случился телепорт.
Есть дизайн, разрабатываемый гейм-дизайнерами, в котором указаны конкретные времена для конкретных активностей. Боты должны выдерживать этот дизайн.
А что произойдет если злоумышленник поковыряется в вашем протоколе и начнет мечом рубить монстров на другом конце карты? Ну или по крайней мере, я могу «открыть» себе всю карту. Вы как-то боритесь с этим / тестируете такое поведение или подобные выкрутасы запрещены соглашением и преследуются по понятиям закону?
Конечно, боремся. Конечно, запрещено :)
Насчёт тестирования протокола на устойчивость против злоумышленников ничего сказать не могу — просто не владею информацией.
Насчёт тестирования протокола на устойчивость против злоумышленников ничего сказать не могу — просто не владею информацией.
Вы на самом деле спрашиваете элементарные вещи :) На сервере проверяются любые присылаемые клиентом данные, скажем в случае атаки выполняется проверка того, что игрок и монстр находятся на допустимом расстоянии, у игрока достаточно манны и т. д. Кроме того с сервера обычно никогда не приходит полная информация о состоянии игрового мира, лишь о том «кусочке» где находится данный персонаж, так что весь мир вы не просмотрите :)
На каких платформах выйдет? Mac и Linux будут?
На сколько омерзительна система монетизации в проектах mail.ru, на столько же хороши в последнее время статьи про геймдев от mail.ru.
Спасибо за статью, с нетерпением ожидаю вторую часть.
Спасибо за статью, с нетерпением ожидаю вторую часть.
Боты это только инструмент, и одна из сложных задач это анализ данных от инструмента:) Расскажите, какие метрики выделяете с помощью этих ботов и на какие смотрите? Делаете какие-то регрессионные задачи?:)
Есть еще какие-то сценарии у ботов? Ну например работа с инвентарем, аукцион, или под новый год большая доля пользователей собирается в одной локации ?:)
Тесты запускаете на отдельном стенде, где нет настоящих игроков?:)
Есть еще какие-то сценарии у ботов? Ну например работа с инвентарем, аукцион, или под новый год большая доля пользователей собирается в одной локации ?:)
Тесты запускаете на отдельном стенде, где нет настоящих игроков?:)
Спасибо за отличный вопрос!
Да, конечно, боты — это только инструмент. И во второй части статьи я как раз планировал подробно рассказать о том, какие характеристики мы смотрим. Но раз уж был задан вопрос, я на него отвечу.
Т.к. наш сервер написан на Java, то мы очень тщательно следим за JVM — за сборками gc, за safepoint'ами и прочее. Так же у нас есть метрики отзывчивости сервера.
По метриках баз данных лучше всех ответит Randll.
Нагрузочные тесты у нас входят в CI, поэтому мы быстро можем заметить сильный регресс. С медленным регрессом всё сложнее. Т.к. постоянно изменяется не только код, но и данные.
Сценарии — да, конечно. Боты либо поддерживают, либо должны поддерживать все активности, которыми игрок может заняться. В том числе, мы тестируем и большие компании в одной локации :)
Есть отдельный нагрузочный стенд, но и на стенд с тестировщиками боты тоже ходят, чтобы никому не было одиноко.
Да, конечно, боты — это только инструмент. И во второй части статьи я как раз планировал подробно рассказать о том, какие характеристики мы смотрим. Но раз уж был задан вопрос, я на него отвечу.
Т.к. наш сервер написан на Java, то мы очень тщательно следим за JVM — за сборками gc, за safepoint'ами и прочее. Так же у нас есть метрики отзывчивости сервера.
По метриках баз данных лучше всех ответит Randll.
Нагрузочные тесты у нас входят в CI, поэтому мы быстро можем заметить сильный регресс. С медленным регрессом всё сложнее. Т.к. постоянно изменяется не только код, но и данные.
Сценарии — да, конечно. Боты либо поддерживают, либо должны поддерживать все активности, которыми игрок может заняться. В том числе, мы тестируем и большие компании в одной локации :)
Есть отдельный нагрузочный стенд, но и на стенд с тестировщиками боты тоже ходят, чтобы никому не было одиноко.
Я имел ввиду не метрики и характеристики тестируемого приложения, а сами метрики по которым вы оцениваете производительность. Возможна ситуация когда разработчик решил подправить селект к базе и он стал тяжелым. По метрикам приложения вы этого не заметите, а вот на базе будет творится что-то страшное. Уследить за всеми метриками довольно сложно, хотя если мониторить общесистемные метрики на всех участвоваших машинках можно.
Я имею ввиду именно метрики производительности, время ответа, время отклика, пропускная способность запросов. Как реализована эта часть? Вы просто в CI запускаете, например, 500 ботов и смотрите только на общесистемные метрики, или же всматриваетесь в распределения времен ответов, смотрите как выполнение одних сценариев влияет на другие? Например сценарий инвернтаря хорошо нагрузил базу данных и получение информации об окружающих NPC или игроках замедлилось в N раз.
Я имею ввиду именно метрики производительности, время ответа, время отклика, пропускная способность запросов. Как реализована эта часть? Вы просто в CI запускаете, например, 500 ботов и смотрите только на общесистемные метрики, или же всматриваетесь в распределения времен ответов, смотрите как выполнение одних сценариев влияет на другие? Например сценарий инвернтаря хорошо нагрузил базу данных и получение информации об окружающих NPC или игроках замедлилось в N раз.
Как правило, это выглядит так. Мы запускаем ботов, смотрим царицу всех метрик — нагрузку на сервер, которая является величиной обратной тику, т.е. чем быстрее сервер обрабатывает все запросы — тем меньше нагрузка. Нормальной величиной нагрузки мы считаем 1. Так вот, если у нас нагрузка стала выше 1, кнопочка в UI окрашивается в красный цвет, и мы начинаем разбираться в причинах этого явления. Находим причины. Так появляется еще один график или даже несколько, посвященных именно этой причине — т.к. в процессе разбора полетов код для построения графика был написан, почему бы его не использовать.
И появляются некоторые ограничения, при которых нужно обращать внимание на этот график, даже при нормальной нагрузке. Скажем, превышена максимальная плотность объектов вокруг игрока — соответствующая кнопка красная.
По базам данных — у нас есть «шарфики» — это вид графиков, известный как stack. На этих графиках мы смотрим за тем, сколько операций одного типа у нас выполняется в единицу времени. Вместе с графиком нагрузки это очень ценная информация для отладки. И если состав операций не изменился, а нагрузка изменилась — значит есть регресс в операциях.
Надеюсь, что ответил на Ваш вопрос.
И появляются некоторые ограничения, при которых нужно обращать внимание на этот график, даже при нормальной нагрузке. Скажем, превышена максимальная плотность объектов вокруг игрока — соответствующая кнопка красная.
По базам данных — у нас есть «шарфики» — это вид графиков, известный как stack. На этих графиках мы смотрим за тем, сколько операций одного типа у нас выполняется в единицу времени. Вместе с графиком нагрузки это очень ценная информация для отладки. И если состав операций не изменился, а нагрузка изменилась — значит есть регресс в операциях.
Надеюсь, что ответил на Ваш вопрос.
Что такое «нагрузка» в вашем понимании? Что-то вроде Load Average?:)
Проблема вся в том, что для пользователя могут начатся тормоза даже при сохранении уровня «нагрузки».
Представьте ситуацию, пользователь открывает свой инвентарь и в базу летит селект и fetch всех строк. И раньше инвентарь был небольшим, и это было можно сделать за одну операцию. Но есть пользователи у которых инвентарь большой, и вы решили сделать select порциями по N строк, используя простой LIMIT. Так вот суть в том, что уровень нагрузки на сервер может остаться тем же, а клиенту необходимо еще все это скомпоновать и результируещее время ответа можеть быть выше чем прежде. На выполнение той же задачи нужно отправить, получить и обработать больше чем раньше.
Если выводить такую информацию в логи, и только изредка поглядывать, то можно пропустить знатные баги для всех пользователей:)
Лучше разграничить все метрики на 2 типа: метрики софта/железа (прикладные/системные) и метрики производительности(время, пропускная способность, времена ответа/отклика, квантили/процентили), и только по последним говорить о производительности. Первый тип имеет только косвенное отношение к производительности:)
Проблема вся в том, что для пользователя могут начатся тормоза даже при сохранении уровня «нагрузки».
Представьте ситуацию, пользователь открывает свой инвентарь и в базу летит селект и fetch всех строк. И раньше инвентарь был небольшим, и это было можно сделать за одну операцию. Но есть пользователи у которых инвентарь большой, и вы решили сделать select порциями по N строк, используя простой LIMIT. Так вот суть в том, что уровень нагрузки на сервер может остаться тем же, а клиенту необходимо еще все это скомпоновать и результируещее время ответа можеть быть выше чем прежде. На выполнение той же задачи нужно отправить, получить и обработать больше чем раньше.
Если выводить такую информацию в логи, и только изредка поглядывать, то можно пропустить знатные баги для всех пользователей:)
Лучше разграничить все метрики на 2 типа: метрики софта/железа (прикладные/системные) и метрики производительности(время, пропускная способность, времена ответа/отклика, квантили/процентили), и только по последним говорить о производительности. Первый тип имеет только косвенное отношение к производительности:)
Все метрики можно разделить, используя разные критерии. Как уже отмечал Андрей в своей статье, загруженный аватар — это своего рода кэш. Поэтому пример выбран не совсем удачно.
Со «знатными багами» мы боремся таким образом, что наши qa-специалисты, занимающимся ручным тестированием, иногда проверяют игру под нагрузкой.
Нагрузка на сервер — это величина, обратно пропорциональная времени, которое мы проводим в обработке. Есть контракт, что это время не может быть больше (допустим) 200 миллисекунд. Если пользователь видит «тормоза», это означает, что сервер стал дольше обрабатывать его запросы. Следовательно, сервер больше времени проводит в обработке. Таким образом, нагрузка увеличится.
Со «знатными багами» мы боремся таким образом, что наши qa-специалисты, занимающимся ручным тестированием, иногда проверяют игру под нагрузкой.
Нагрузка на сервер — это величина, обратно пропорциональная времени, которое мы проводим в обработке. Есть контракт, что это время не может быть больше (допустим) 200 миллисекунд. Если пользователь видит «тормоза», это означает, что сервер стал дольше обрабатывать его запросы. Следовательно, сервер больше времени проводит в обработке. Таким образом, нагрузка увеличится.
Для обычных серверов у нас есть метрика, называемая «нагрузка», которая включает в себя всё. :)
С базой чуть сложнее.
Мы смотрим
— сколько всего датабазных транзакций у нас прошло единицу времени.
— разбивка по типам. т.е. 100 операций взять предмет, 12 операций завершить квест и т.п.
— логируем, но не очень смотрим, мин/макс/среднее время отклика по одному типу транзакции за каждые 3 секунды. Это инфа для дебага а не для ежедневного просмотра.
— загрузку сервера исполнения транзакций в % от максимальной. Т.е. процент времени, который сервис тратит на обработку запросов.
— раз в несколько месяцев запускаем нагрузочный тест с логированием sql-я и потом, через pgfouine, находим и вычищаем топ тормозящих запросов.
Если кто-то подправил запрос и он стал тяжёлым, то мы увидим что нагрузка на датабазный сервис поднялась. Если кто-то сделал слишком частый запрос — мы увидим ненормальное количество операций определённого типа. Если кто-то написал медленный запрос, который выполняется редко, мы отловим это по профайлингу SQL-я.
С базой чуть сложнее.
Мы смотрим
— сколько всего датабазных транзакций у нас прошло единицу времени.
— разбивка по типам. т.е. 100 операций взять предмет, 12 операций завершить квест и т.п.
— логируем, но не очень смотрим, мин/макс/среднее время отклика по одному типу транзакции за каждые 3 секунды. Это инфа для дебага а не для ежедневного просмотра.
— загрузку сервера исполнения транзакций в % от максимальной. Т.е. процент времени, который сервис тратит на обработку запросов.
— раз в несколько месяцев запускаем нагрузочный тест с логированием sql-я и потом, через pgfouine, находим и вычищаем топ тормозящих запросов.
Если кто-то подправил запрос и он стал тяжёлым, то мы увидим что нагрузка на датабазный сервис поднялась. Если кто-то сделал слишком частый запрос — мы увидим ненормальное количество операций определённого типа. Если кто-то написал медленный запрос, который выполняется редко, мы отловим это по профайлингу SQL-я.
Не смотря на то, что играть в игры от mail.ru как геймеру со стажем не интересно, читать реально интересно. Затягивает. Поражаешься простоте и гениальности некоторых идей.
Хотя мысль об использовании бота в виде куска клиента+некоторой надстройки над ним была где-то на интуитивном уровне. Такой реализацией никогда не занимался (вообще не занят в разработках, ибо занимаюсь администрированием на текущий момент), но писал в своё время бот, выполнявший строгое количество функций (суть — простой цикл) и плодивший себя до определённого количества, чтобы проверить, выдержит ли сервер нагрузку.
А читаешь о реализациях, описанных у Вас и думаешь «Это же реально просто почему мне такая мысль не приходила в голову?»
А технических подробностей можно в будущих публикациях узреть? Ну там, например, сколько в штуках всего, сколько не справилось со своей задачей (упёрся в дерево и тупил, созерцая его ствол (условно)), и т.д.
Хотя мысль об использовании бота в виде куска клиента+некоторой надстройки над ним была где-то на интуитивном уровне. Такой реализацией никогда не занимался (вообще не занят в разработках, ибо занимаюсь администрированием на текущий момент), но писал в своё время бот, выполнявший строгое количество функций (суть — простой цикл) и плодивший себя до определённого количества, чтобы проверить, выдержит ли сервер нагрузку.
А читаешь о реализациях, описанных у Вас и думаешь «Это же реально просто почему мне такая мысль не приходила в голову?»
А технических подробностей можно в будущих публикациях узреть? Ну там, например, сколько в штуках всего, сколько не справилось со своей задачей (упёрся в дерево и тупил, созерцая его ствол (условно)), и т.д.
Вторая часть, которая ожидается где-то через 2 недели, как раз будет более техническая, правда, скорее о инфраструктуре тестов.
Статья о том, как устроены различные состояния в ботах, в том числе, хитроумный поиск точки, в которую боту стоит пойти, чтобы не найти дерево, не планировалась, но, судя по комментариям, читателям это интересно, поэтому я постараюсь найти время, чтобы её написать. Но ничего обещать не буду :) Если есть конкретные вопросы — задавайте, с радостью отвечу.
Статья о том, как устроены различные состояния в ботах, в том числе, хитроумный поиск точки, в которую боту стоит пойти, чтобы не найти дерево, не планировалась, но, судя по комментариям, читателям это интересно, поэтому я постараюсь найти время, чтобы её написать. Но ничего обещать не буду :) Если есть конкретные вопросы — задавайте, с радостью отвечу.
Анализировали ли вы, насколько стратегия среднего игрока отличается от
появляется на карте, бежит, видит монстра и убивает его. Если есть трофеи – поднимает, если нет – бежит дальше.
Боты изначально разрабатывались для проведения нагрузочного тестирования. Для этой цели не очень важно, чем занят каждый конкретный «средний игрок» — главное, чтобы профиль создаваемой нагрузки был похож на то, что ждет нас на боевых.
И да, описанное в статье поведение — это простой пример. В наших сценариях есть много разных стратегий поведений, но почти все содержат ядро — «бегаю, убиваю, собираю лут». Т.к. согласно нашим представлениям именно это поведение будет вносить наибольший вклад в нагрузку на сервера.
И да, описанное в статье поведение — это простой пример. В наших сценариях есть много разных стратегий поведений, но почти все содержат ядро — «бегаю, убиваю, собираю лут». Т.к. согласно нашим представлениям именно это поведение будет вносить наибольший вклад в нагрузку на сервера.
ну Headless боты это не новинка.
А почему конечные автоматы-то? Behaviour Trees гораздо более гибкие, меньше переписывать при изменении окружающих условий, да и на ниве бото-строения они себя зарекомедовали прекрасно.
Оффтоп: если честно, то вообще хотелось бы почитать статьи об ИИ…
Когда я только начинал работать в Allods Team, и искал статьи об ИИ в рунете, то наткнулся на статью Тимура Бухараева, написанную так же по мотивам КРИ и посвященную Героем V.
Сейчас, правда, Тимур уже не занимается ИИ.
Сейчас, правда, Тимур уже не занимается ИИ.
Отличная статья! Действительно отличная!
Основная цель у игры — развлечь человека, сделать ему приятное. А человек любит побеждать, любит ощутить свое превосходство, пусть даже над электронным болваном. Поэтому ИИ, который тоже работает на индустрию развлечений, должен сначала посопротивляться для вида, а потом проиграть.
Надо отметить, что сам принцип хотя и является очень простым и понятным, изначально вызывает у программистов противоречие. Они не хотят делать ИИ, который красиво отдается. Им хочется сделать такой ИИ, который заставит игрока рыдать от собственного бессилия. Но так делать не стоит.
Не пойман — не вор
Должен ли ИИ читить? В идеале, конечно, нет. Но даже создание ИИ, который не побеждает, а оказывает достойное сопротивление хорошему игроку — тоже очень сложная задача. И сложность эта абсолютно не соответствует времени, которое для этого отводится. Поэтому приходится использовать обходные пути для увеличения силы ИИ.
В принципе, ничего плохого в этом нет. Необязательно делать достойного противника. Достаточно создать иллюзию достойного противника. И если вы обманете, но вас не поймают за руку — то вы на коне.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нагрузочное тестирование в Skyforge, или Боты – санитары сервера. Часть 1