Когда я только начинал работать в Allods Team, и искал статьи об ИИ в рунете, то наткнулся на статью Тимура Бухараева, написанную так же по мотивам КРИ и посвященную Героем V.
Сейчас, правда, Тимур уже не занимается ИИ.
Боты изначально разрабатывались для проведения нагрузочного тестирования. Для этой цели не очень важно, чем занят каждый конкретный «средний игрок» — главное, чтобы профиль создаваемой нагрузки был похож на то, что ждет нас на боевых.
И да, описанное в статье поведение — это простой пример. В наших сценариях есть много разных стратегий поведений, но почти все содержат ядро — «бегаю, убиваю, собираю лут». Т.к. согласно нашим представлениям именно это поведение будет вносить наибольший вклад в нагрузку на сервера.
Так исторически сложилось, что в самой первой версии ботов, разрабатываемых еще для Аллодов, были использованы именно конечные автоматы. Каких-то проблем с добавлением новых состояний или с производительностью мы не испытываем, поэтому остаются конечные автоматы.
Конечно, боремся. Конечно, запрещено :)
Насчёт тестирования протокола на устойчивость против злоумышленников ничего сказать не могу — просто не владею информацией.
Все метрики можно разделить, используя разные критерии. Как уже отмечал Андрей в своей статье, загруженный аватар — это своего рода кэш. Поэтому пример выбран не совсем удачно.
Со «знатными багами» мы боремся таким образом, что наши qa-специалисты, занимающимся ручным тестированием, иногда проверяют игру под нагрузкой.
Нагрузка на сервер — это величина, обратно пропорциональная времени, которое мы проводим в обработке. Есть контракт, что это время не может быть больше (допустим) 200 миллисекунд. Если пользователь видит «тормоза», это означает, что сервер стал дольше обрабатывать его запросы. Следовательно, сервер больше времени проводит в обработке. Таким образом, нагрузка увеличится.
Вторая часть, которая ожидается где-то через 2 недели, как раз будет более техническая, правда, скорее о инфраструктуре тестов.
Статья о том, как устроены различные состояния в ботах, в том числе, хитроумный поиск точки, в которую боту стоит пойти, чтобы не найти дерево, не планировалась, но, судя по комментариям, читателям это интересно, поэтому я постараюсь найти время, чтобы её написать. Но ничего обещать не буду :) Если есть конкретные вопросы — задавайте, с радостью отвечу.
Как правило, это выглядит так. Мы запускаем ботов, смотрим царицу всех метрик — нагрузку на сервер, которая является величиной обратной тику, т.е. чем быстрее сервер обрабатывает все запросы — тем меньше нагрузка. Нормальной величиной нагрузки мы считаем 1. Так вот, если у нас нагрузка стала выше 1, кнопочка в UI окрашивается в красный цвет, и мы начинаем разбираться в причинах этого явления. Находим причины. Так появляется еще один график или даже несколько, посвященных именно этой причине — т.к. в процессе разбора полетов код для построения графика был написан, почему бы его не использовать.
И появляются некоторые ограничения, при которых нужно обращать внимание на этот график, даже при нормальной нагрузке. Скажем, превышена максимальная плотность объектов вокруг игрока — соответствующая кнопка красная.
По базам данных — у нас есть «шарфики» — это вид графиков, известный как stack. На этих графиках мы смотрим за тем, сколько операций одного типа у нас выполняется в единицу времени. Вместе с графиком нагрузки это очень ценная информация для отладки. И если состав операций не изменился, а нагрузка изменилась — значит есть регресс в операциях.
Спасибо за отличный вопрос!
Да, конечно, боты — это только инструмент. И во второй части статьи я как раз планировал подробно рассказать о том, какие характеристики мы смотрим. Но раз уж был задан вопрос, я на него отвечу.
Т.к. наш сервер написан на Java, то мы очень тщательно следим за JVM — за сборками gc, за safepoint'ами и прочее. Так же у нас есть метрики отзывчивости сервера.
По метриках баз данных лучше всех ответит Randll.
Нагрузочные тесты у нас входят в CI, поэтому мы быстро можем заметить сильный регресс. С медленным регрессом всё сложнее. Т.к. постоянно изменяется не только код, но и данные.
Сценарии — да, конечно. Боты либо поддерживают, либо должны поддерживать все активности, которыми игрок может заняться. В том числе, мы тестируем и большие компании в одной локации :)
Есть отдельный нагрузочный стенд, но и на стенд с тестировщиками боты тоже ходят, чтобы никому не было одиноко.
Windows — платформа для нас приоритетная, т.к. именно на ней сосредоточено больше всего игроков. Но и для других платформ какие-то компоненты Skyforge будут доступны. Дальше, увы, рассказать не могу — NDA.
Боты никогда никуда не выйдут. На Маке их запускать не пробовал — хотя любопытство было. А на Линуксе они не очень производительно из под wine работают.
Боты общаются с игрой не через UI, а непосредственно вызывая те или иные функции, которые есть в игровом клиенте. Поэтому на ботах хранится список всех объектов окружающего его пространства — мобы, лут и прочее. В связи с чем достаточно просто пробегать по этому списку, который постоянно обновляется, и выбирать нужные элементы.
Состояния могут переключаться, как в связи с завершением состояния — из состояния «бег» вышли по ветке «добежали», так и в связи с каким-то внешними событиями — случился телепорт.
Есть дизайн, разрабатываемый гейм-дизайнерами, в котором указаны конкретные времена для конкретных активностей. Боты должны выдерживать этот дизайн.
Сейчас, правда, Тимур уже не занимается ИИ.
И да, описанное в статье поведение — это простой пример. В наших сценариях есть много разных стратегий поведений, но почти все содержат ядро — «бегаю, убиваю, собираю лут». Т.к. согласно нашим представлениям именно это поведение будет вносить наибольший вклад в нагрузку на сервера.
Насчёт тестирования протокола на устойчивость против злоумышленников ничего сказать не могу — просто не владею информацией.
Со «знатными багами» мы боремся таким образом, что наши qa-специалисты, занимающимся ручным тестированием, иногда проверяют игру под нагрузкой.
Нагрузка на сервер — это величина, обратно пропорциональная времени, которое мы проводим в обработке. Есть контракт, что это время не может быть больше (допустим) 200 миллисекунд. Если пользователь видит «тормоза», это означает, что сервер стал дольше обрабатывать его запросы. Следовательно, сервер больше времени проводит в обработке. Таким образом, нагрузка увеличится.
Статья о том, как устроены различные состояния в ботах, в том числе, хитроумный поиск точки, в которую боту стоит пойти, чтобы не найти дерево, не планировалась, но, судя по комментариям, читателям это интересно, поэтому я постараюсь найти время, чтобы её написать. Но ничего обещать не буду :) Если есть конкретные вопросы — задавайте, с радостью отвечу.
И появляются некоторые ограничения, при которых нужно обращать внимание на этот график, даже при нормальной нагрузке. Скажем, превышена максимальная плотность объектов вокруг игрока — соответствующая кнопка красная.
По базам данных — у нас есть «шарфики» — это вид графиков, известный как stack. На этих графиках мы смотрим за тем, сколько операций одного типа у нас выполняется в единицу времени. Вместе с графиком нагрузки это очень ценная информация для отладки. И если состав операций не изменился, а нагрузка изменилась — значит есть регресс в операциях.
Надеюсь, что ответил на Ваш вопрос.
Да, конечно, боты — это только инструмент. И во второй части статьи я как раз планировал подробно рассказать о том, какие характеристики мы смотрим. Но раз уж был задан вопрос, я на него отвечу.
Т.к. наш сервер написан на Java, то мы очень тщательно следим за JVM — за сборками gc, за safepoint'ами и прочее. Так же у нас есть метрики отзывчивости сервера.
По метриках баз данных лучше всех ответит Randll.
Нагрузочные тесты у нас входят в CI, поэтому мы быстро можем заметить сильный регресс. С медленным регрессом всё сложнее. Т.к. постоянно изменяется не только код, но и данные.
Сценарии — да, конечно. Боты либо поддерживают, либо должны поддерживать все активности, которыми игрок может заняться. В том числе, мы тестируем и большие компании в одной локации :)
Есть отдельный нагрузочный стенд, но и на стенд с тестировщиками боты тоже ходят, чтобы никому не было одиноко.
Состояния могут переключаться, как в связи с завершением состояния — из состояния «бег» вышли по ветке «добежали», так и в связи с каким-то внешними событиями — случился телепорт.
Есть дизайн, разрабатываемый гейм-дизайнерами, в котором указаны конкретные времена для конкретных активностей. Боты должны выдерживать этот дизайн.
Впредь я буду обновлять и писать комментарии быстрее.