Comments 6
Интересный вариант. А в зависимости от прохождения уровня ботом — какие параметры уровня меняются для баланса?
Я в своё время делал чуть иначе. Задавал оптимальную стратегию боту через подсчёт «уничтожаемых» или «снимаемых» в результате хода предметов, сортировал их в соответствии с неким приоритетом и только тогда выполнял ход. Игровая сессия при этом могла длиться бесконечно, а точнее — сколько боту понадобится для прохождения уровня. Для балансировки каждого уровня он проходился порядка пары тысяч раз, а собранная статистика позволяла нарисовать график, который и был конечной целью тестирования.
Сам же график всегда напоминал кривую с двумя псевдо-ассимптотами. По абсциссе измерялось количество сделанных ходов для прохождения уровня, а по ординате — сколько раз при прохождении этого уровня боту _хватило_ ходов для успеха. Таким образом, при первом взгляде на кривую можно было сразу сказать, сколько ходов надо выставлять на уровень при балансировке, учитывая заданную гейм-дизайнером сложность конкретного уровня. А вторым взглядом, изучая кривизну линии — можно было «крутить» и другие параметры уровня (количество «дырок», вероятность выпадения предметов, количество предметов для сбора).
Единственным минусом бота, конечно, была производительность. Запущенный в 24 потока, распределённых на 8 ядер (эмпирически полученное оптимальное количество потоков), он делал проход сотни уровней по паре тысяч раз примерно за 10-15 часов.
Я в своё время делал чуть иначе. Задавал оптимальную стратегию боту через подсчёт «уничтожаемых» или «снимаемых» в результате хода предметов, сортировал их в соответствии с неким приоритетом и только тогда выполнял ход. Игровая сессия при этом могла длиться бесконечно, а точнее — сколько боту понадобится для прохождения уровня. Для балансировки каждого уровня он проходился порядка пары тысяч раз, а собранная статистика позволяла нарисовать график, который и был конечной целью тестирования.
Сам же график всегда напоминал кривую с двумя псевдо-ассимптотами. По абсциссе измерялось количество сделанных ходов для прохождения уровня, а по ординате — сколько раз при прохождении этого уровня боту _хватило_ ходов для успеха. Таким образом, при первом взгляде на кривую можно было сразу сказать, сколько ходов надо выставлять на уровень при балансировке, учитывая заданную гейм-дизайнером сложность конкретного уровня. А вторым взглядом, изучая кривизну линии — можно было «крутить» и другие параметры уровня (количество «дырок», вероятность выпадения предметов, количество предметов для сбора).
Единственным минусом бота, конечно, была производительность. Запущенный в 24 потока, распределённых на 8 ядер (эмпирически полученное оптимальное количество потоков), он делал проход сотни уровней по паре тысяч раз примерно за 10-15 часов.
Ну у нас, насколько я понял, то же самое по сути, в плане оценки ходов. А вот постройку графика мы поленились сделать:) Сейчас просто куча разных метрик рассчитываются и вываливаются в распечатку.
Для подкрутки баланса меняются вероятности выпадения фишек в том же excel файле. За пару минут можно изменить вероятности, сгенерировать новый xml описывающий уровень и собрать новую «черновую» статистику (50-100 прогонов). Если опять не то что нужно, то подкручиваем еще и собираем новую статистику. Когда черновая статистика выходит правильная, то проверяем на большом количестве прогонов.
В идеале бы конечно хорошо иметь возможность после каждой подкрутки сразу получать большую статистику, но для этого нужно ускорять бот… Вы мне интересную мысль подкинули с потоками — спасибо! Я этим правда раньше никогда не занимался — надо будет изучить вопрос.
А режим бота, когда он играет до победы (бесконечное число ходов) мы тоже делали, но потом решили отказаться от этого опять таки из-за производительности — все равно количество ходов для уровня должен определять дизайнер, и если он решил нужен короткий уровень на 15 ходов, то не хочется ждать, пока бот будет тестировать ходы с 15го по 50ый.
Для подкрутки баланса меняются вероятности выпадения фишек в том же excel файле. За пару минут можно изменить вероятности, сгенерировать новый xml описывающий уровень и собрать новую «черновую» статистику (50-100 прогонов). Если опять не то что нужно, то подкручиваем еще и собираем новую статистику. Когда черновая статистика выходит правильная, то проверяем на большом количестве прогонов.
В идеале бы конечно хорошо иметь возможность после каждой подкрутки сразу получать большую статистику, но для этого нужно ускорять бот… Вы мне интересную мысль подкинули с потоками — спасибо! Я этим правда раньше никогда не занимался — надо будет изучить вопрос.
А режим бота, когда он играет до победы (бесконечное число ходов) мы тоже делали, но потом решили отказаться от этого опять таки из-за производительности — все равно количество ходов для уровня должен определять дизайнер, и если он решил нужен короткий уровень на 15 ходов, то не хочется ждать, пока бот будет тестировать ходы с 15го по 50ый.
Мне кажется водолазы все-таки должны всплывать, а не погружаться ))
Собирает ли игра статистику попыток прохождения?
Sign up to leave a comment.
Создание бота-тестера для match-3 игры