Анализ шансов в настольных играх через эмуляции
Как вам игровая сессия с 1000+ ходами в обычной ходилке? А такое вполне реально. Попробуйте по превьюшке понять, о какой из 4 игр речь.
До этого я уже проанализировал одну немного бесячую настольную игру ходилку через эмуляции [1] [2]. В комментариях мне накидали кучу других запомнившихся игр с предложением и их потыкать. Ну вот я и потыкал. Для этого немного оптимизировал код эмулятора через javascript, чтобы он мог запускать по 100 миллионов игр. Скрипты выложены на гитхабе [3].
Вокруг света
В качестве механики большого отбрасывания (аналог чёрной дыры из прошлой статьи) я учитывал две позиции: 100->46, 107->37. А вот отбрасывание на начало 21->0 я не стал считать аналогом чёрной дыры, т.к. возврат на 21 ход примерно равнозначен обычным "стрелкам-назад". Статистика [4] вышла такая:
среднее число ходов 36;
максимальное число ходов 235;
минимальное число ходов 11;
число игр с попаданием хотя бы в одну отбрасывалку 54%, при этом игр с неравным числом попаданий в ловушки 43%;
вероятность проигрыша при более частом попадании в отбрасывалку 88%;
частота победы у первого игрока 50,85%.
График вероятности завершить игру за X ходов
Что интересного тут можно увидеть.
Плюсы:
- Красивая картинка, которую интересно разглядывать.
- Средняя длина игрового поля, очень долгая игровая сессия случается редко. Игра на 235 ходов случилась лишь однажды из 100 миллионов игр.
- Преимущество первого хода с 50,85% весьма небольшое.
Минусы:
- Мега отбрасывания, как всегда, подбешивают, но есть механика для камбека, так как оппонент сам может попасть в одну из двух ловушек у самого финиша.
- Если кого-то отбросило ловушкой чаще (что происходит с частотой 43%), то он проиграет с очень большой вероятностью: 88%.
Веселое путешествие
Здесь два отбрасывания в начало. При этом первая ловушка отбрасывает недалеко, поэтому её рассматривать как критическую я не стал. Поэтому ловушками я посчитал следующие комбинации: 63->0, 75->35. Статистика [5] вышла такая:
среднее число ходов 35;
максимальное число ходов 271;
минимальное число ходов 11;
число игр с попаданием хотя бы в одну отбрасывалку 50%, при этом игр с неравным числом попаданий в ловушки 41%;
вероятность проигрыша при более частом попадании в отбрасывалку 81%;
частота победы у первого игрока 50.78%.
Что интересного тут можно увидеть.
Статистически игра очень похожа на предыдущую, и даже немного лучше сбалансирована. Хотя на глазок, я думал, что будет наоборот, и в этой игре окажется кошмарный баланс.
Большое космическое путешествие (гребаный поезд)
Как подсказал, один из комментаторов AlexKoz1980, настоящее название этой игры - гребаный поезд. В качестве больших ловушек я считал за точки: 57, 70, 77, 88, 90. И судя по статистике такое название он полностью оправдывает [6].
среднее число ходов 102;
максимальное число ходов 1615;
минимальное число ходов 10;
число игр с попаданием хотя бы в одну отбрасывалку 92%, при этом игр с неравным числом попаданий в ловушки 70%;
вероятность проигрыша при более частом попадании в отбрасывалку 77%;
частота победы у первого игрока 50.14%.
Это самая несбалансированная игра из тех, что я видел. Помимо 5 самых опасных ловушек, тут есть ещё и мелкие ловушки, откатывающие на 1-2 этажа. Проблема в том, что после мелкой ловушки сбрасывается риск попадания в одну из опасных ловушек. И сохраняется он до самого конца. К 100-ому ходу становится уже неважно кто победит, лишь бы хоть кто-нибудь игру закончил.
Космос от шестилетнего ребенка с дедушкой
А дальше идёт ходилка "Космическое приключение с чёрными дырами и кротовыми норами", созданная под руководством ребёнка. Картинка немного доработана, чтобы появились числа на шагах и легенда к игре.
Весьма типичная особенность новичка - циклопических размеров игровая карта, аж на 509 шагов. По первости часто кажется, что чем больше тем лучше, но это почти всегда не так.
Вторая особенность - наличие механики кротовой норы, в результате попадания в которую игрок моментально побеждает. На карте 4 кротовые норы и 4 чёрные дыры (возврат в начало).
Эмуляция [7] на 100 миллионов игр дало следующие результаты:
среднее число ходов 35;
максимальное число ходов 232;
минимальное число ходов 3;
число игр с попаданием хотя бы в одну чёрную дыру 65%, при этом игр с неравным числом попаданий в чёрные дыры 57%;
вероятность проигрыша при более частом попадании в чёрную дыру 54%;
побед через кротовую нору 83,5%;
частота победы у первого игрока 50,48%.
Что интересного тут можно увидеть.
Плюсы:
- Влияние чёрных дыр почти полностью нивелировано. 54% вероятности проиграть если ты попадал в чёрную дыру чаще оппонента - почти 50/50.
- Довольно часто игры заканчиваются до 20 ходов, быстрые игровые сессии это хорошо.
- Преимущество первого хода с 50,48% минимальное.
Минусы:
- Огромный путь в 509 шагов приводит к тому, что чаще всего игра очень сильно затягивается. Обычно это сильно утомляет. Рецепт простой - уменьшать карту до ~100 шагов и меньше.
- Победа почти всегда происходит за счёт попадания в кротовую нору. Поэтому, как вариант, следовало по максимуму использовать эту механику и многократно увеличить число кротовых нор при удалении от старта.
Заключение
Среди проверенных игр лишь гребаный поезд оказался сильно перекошенным. Остальные, на удивление, примерно одинаково проходятся за 35 ходов в среднем. Если вам известны другие безумные ходилки - скидывайте в комментариях. Если наберутся новые ещё более дикие, то я сделаю ещё подборку.
Источники
Кто хочет нечто подобное не пропустить в будущем, подписывайтесь на автора (на меня то есть).
Насколько дизморалящий баланс в этой настолке с чёрной дырой
(этот пост про настолку, но касается автоматизированного тестирования, что одинаково полезно и для видеоигр)
Появилась у меня с маленьким ребенком новая красивая настолка - классическая ходилка с одним кубиком. Симпатичная картинка, достаточная длина игровой сессии. И есть в этой игре странная особенность - чёрная дыра на 39 шаге (из 120), которая сразу отбрасывает игрока в самое начало. Давайте посчитаем насколько это странно. И мелкий совет в конце по расширению правил для возможного исправления.
В чем проблема?
У игрока нет никакого контроля и возможности повлиять на результат. То есть победа или поражение - полная случайность. Поэтому если уж не повезло попасть на черную дыру, то догнать оппонента почти нереально, ведь это одна треть всего маршрута.
В игре нет никакой механики камбека. Более того всегда есть заметная вероятность второй раз попасть на черную дыру. Уныние у такого игрока обеспечено.
Насколько проблема большая?
С ходу может показаться, что риск такого события всего лишь ~17% (1/6 для шестигранного кубика). Вроде терпимо. Но если подумать ещё, то окажется, что проверять надо не одного игрока, а двух, т.к. нас интересует интересность в игре обоих игроков. Ещё хуже если игроков больше одного. Но можно подумать ещё, и тогда окажется, что для одного игрока опасных бросков не один, а обычно больше (2, иногда 3). Например, игрок находится на расстоянии 6 от чёрной дыры, выпадает 2 и он вздыхает с облегчением, но зря, т.к. на следующий свой ход он опять в той же ситуации и фатальной для него теперь является четвёрка.
Рассчитать вероятность всего этого через теорию вероятности несколько проблематично. Зато можно заэмулировать и просто собраться статистику.
const bonusTurn = [7, 22, 55, 70, 77, 93, 104, 115];
const skipTurn = [13, 28, 46, 62, 85, 98, 110];
function main(gamesCount) {
let games = [];for (i = 0; i < gamesCount; i++) {
games[i] = emulateGame();
}//console.log(games);
let catchedGames = 0;
let catchedGamesUnfair = 0;
let catchedMoreLoseGames = 0;
for (i = 0; i < gamesCount; i++) {
if (games[i].p1Catched > 0 || games[i].p2Catched > 0) {
catchedGames++;
if (games[i].p1Catched != games[i].p2Catched) {
catchedGamesUnfair++;
}
}if (games[i].p1Catched > games[i].p2Catched && games[i].winner == 'p2') {
catchedMoreLoseGames++;
} else if (games[i].p1Catched < games[i].p2Catched && games[i].winner == 'p1') {
catchedMoreLoseGames++;
}
}console.log('Count of games: ' + gamesCount);
console.log('Percent of games with black hole: ' + Math.round(100*catchedGames/gamesCount) + '%');
console.log('Percent of unfair games with black hole: ' + Math.round(100*catchedGamesUnfair/gamesCount) + '%');
console.log('If go to black hole more then lose: ' + Math.round(100*catchedMoreLoseGames/catchedGamesUnfair) + '%');
}
function emulateGame() {
let game = {
'p1': 0,
'p2': 0,
'winner': null,
'p1Catched': 0,
'p2Catched': 0,
'turn': 0
}while(true) {
game.turn++;game.p1 += getDice();
game = checkMove(game, 'p1');if (game.p1 >= 120) {
game.winner = 'p1';
break;
}game.p2 += getDice();
game = checkMove(game, 'p2');if (game.p2 >= 120) {
game.winner = 'p2';
break;
}
}return game;
}
function checkMove(game, player) {
let anotherPlayer = 'p1';
if (player == anotherPlayer) {
anotherPlayer = 'p2';
}if (bonusTurn.indexOf(game[player]) !== -1) {
game[player] += getDice();
game = checkMove(game, player);
}if (skipTurn.indexOf(game[player]) !== -1) {
game[anotherPlayer] += getDice();
game = checkMove(game, anotherPlayer);
}if (game[player] == 39) {
game[player] = 0;
game[player + 'Catched']++;
}if (game[player] == 4) {
game[player] = 8;
}if (game[player] == 23) {
game[player] = 9;
}if (game[player] == 24) {
game[player] = 34;
}if (game[player] == 30) {
game[player] = 20;
}if (game[player] == 42) {
game[player] = 52;
}if (game[player] == 60) {
game[player] = 50;
}if (game[player] == 65) {
game[player] = 74;
}if (game[player] == 79) {
game[player] = 88;
}if (game[player] == 101) {
game[player] = 91;
}if (game[player] == 107) {
game[player] = 112;
}return game;
}
function getDice() {
return Math.floor(Math.random() * 6 + 1);
}
main(1000000);
Все оформление кода безнадежно поломалось, кому нужен javascript, можете посмотреть его в хабровской статье из моего профиля со списком: https://habr.com/ru/users/qnok/posts/
Для запуска подойдет любое окно браузера, F12, console, copy-paste
Итого, при эмуляции одного миллиона игр мы получаем такую статистику:
1) Вероятность того, что хоть кто-нибудь хотя бы раз попадет в черную дыру: 50% (!!!);
2) Вероятность того, что игра будет несправедливой, когда у кого-то будет больше попаданий в черную дыру, чем у оппонента: 45%;
3) Вероятность того, что игрок с большим попаданием в чёрную дыру проиграет: 92%.
А что можно сделать?
Самый примитивный вариант: игнорировать чёрную дыру или считать её за обычный пропуск хода.
Вариант посложнее: каждому игроку дать по две фишки, чтобы была возможность выбора, кем передвигаться. В этом случае игра превращается из простого рандома в чуть более тактическую игру. И ребёнку гораздо полезнее, когда он не просто тренируется соблюдать игровые правила, но и учится играм с контролем.
Заключение
Вероятность попадания в черную дыру на 50% меня весьма удивила, я ожидал поменьше. Не менее удивительны целых 8% победы даже в случае чёрной дыры. Вот они когнитивные искажения.
А вот гейм-дизайнерам, я считаю, нужно всё же тестировать свои собственные игры получше. Анализ "на глазок" может подложить подобную свинью. Данная механика приносит почти всегда только разочарование и 8% на "победу вопреки" того не стоит. Особенно в игре, где это "вопреки" происходит исключительно по воле случая.
Мой собственный клон популярной игры #5
Все привет.
Я продолжаю делиться успехами своего самообразовательного процесса по разработке клона игры MagicSurvival.
С момента последнего поста прошло довольно много времени и немало часов работы.
Как показал мой опыт, в таких проектах очень много времени уходит на тестирование игры.
Только бесконечно играя и пытаясь выигрывать в собственной игре можно увидеть что какие-то её элементы работают неправильно или не работают вовсе.
Например под моим предыдущим постом, кто-то заметил, что я для экипировки персонажа использую слишком много слотов. Тогда я подумал, что это будет моей фишкой, однако практика игры показала, что это совершенно неудобно. Большое количество снаряжения постоянно путает. Сбивает с толку и не позволяет оценить а что вообще в билде работает некорректно, на это тратится много времени, а сам процесс утомителен до безумия.
В качестве решения этой проблемы первично из снаряжения было исключено 4 предмета, налокотники и наколенники (как будто бы добавлять их не было абсурдом изначально).
Затем дальнейшие тесты выявили что очень часто бонусы выпадающие на предметах бывают очень полезными, заменять один полезный предмет на другой не хочется, а отдельные виды бонусов падают ну очень редко, хотя они имеют крайне важное значение в совокупном прогрессе силы персонажа. решение было крайне простым, подсмотренным в дьябло. Для различных слотов снаряжения были приняты ограниченные наборы бонусов. Теперь например увеличение скорости передвижения и радиуса поднятия предметов привязаны к сапогам, и на сапоги прочие 52 бонуса не падают, таким образом когда игрок получит новые сапоги, ему не придётся делать выбор между уроном одной способности и бонусом к скорости передвижения. теперь предметы более сконцентрированы. Но очевидно это не последняя итерация.
На текущий момент запроектировано 12 арен, на которых игроку необходимо выживать в течении определенного периода времени. С каждой новой ареной уровень сложности игры растёт. По этому игроку придётся закупаться снаряжением. Предложив поиграть в заготовленный билд своему другу, он заметил, что пройдя первую арену, он не получил достаточно золота, чтобы купить какой-то предмет, в самом начале игры. Ранее мне казалось справедливым что за золото игроку придётся побегать, потому что золото это награда. Но по факту, бегать по уровня раз за разом не имея гарантированного результата, это скорее удручает.
Решение было столь же простым. Включить в игровой процесс гарантированную награду за прожитые минуты на арене. Теперь после каждого забега у игрока будет гарантированный элемент прогрессии, что в теории должно увеличить вовлеченность.
За долгие часы тестирования у меня самого уже замылился глаз и я не могу понять что является сложным а что лёгким, потому что играю уже очень много. Поэтому предлагаю всем желающим поучаствовать в очередном тестировании нового билда игры, который доступен по ссылке:
https://disk.yandex.ru/d/YuGOefGFTAqMuQ
На самом деле у меня уже есть длинный список замечаний и предложений к получившемуся билду. Однако я хочу собрать как можно больше критики, чтобы не делать в будущем двойную работу, по переделыванию каких-то элементов или пытаясь интегрировать то, что уже сильно коверкает сформированную игровую логику.
Я стараюсь документировать свою работу, создавая для самого себя элемент визуальной прогрессии. На текущий момент на разработку затрачено примерно 120 часов, а что я делал всё это время представлено на графике ниже:
Шакальное видео с демонстрацией игрового проекта прикрепляю ниже:
Проект делается под PC на UE4 без использования С++, только на Blueprints.
Группа в ВК: https://vk.com/public213932674
Примите участие в Playtest игры The Last World
Всем привет! Давно я не писал девлоги, а всё потому, что было очень много работы. Небольшой анонс для тех, кому интересны игры данного типа. Через 2 недели (+-) начнется полуоткрытое тестирование игры TheLastWorld. Мест будет ограничено, так что успейте подать заявку на участие.
Подробней об игре можно узнать в статьях Тут и Тут и Тут.
Итак, как написал выше - близится важный этап для игры TheLastWorld и это тестирование. Сейчас проходит закрытое альфа тестирование, где принимает участие не так уж и много человек, 6 человек.
В следующем же этапе может принять участие любой желающий, при условии, что он успел попасть в то ограниченное количество участников. Количество участников ещё под вопросом, но это количество будет больше, чем в первом этапе в несколько раз.
Проводим небольшой тест
Не хотелось бы чтобы у игроков были технические проблемы при прохождении нашей головоломки. По этой причине мы решили провести небольшой тест работоспособности базового функционала нашего проекта под техназванием T-Drones. Пока доступны Windows & OSX версии сборок. Позже, возможно, появится Linux.
Тест направлен на проверку работоспособности настойки управления клавиатуры и геймпадов, заодно проверим:
- работоспособность игры
- графику
- игровое меню в целом
Если после запуска T-Drones появился персонаж, есть возможность им управлять и экран выглядит примерно как на рис. ниже, то грфическая часть успешно работает:
Доступ к настройкам можно получить по нажатию на клавишу ESC.
Друзья! Тест частично автоматизирован, в случае каких-либо проблем вышлет разработчикам соответствуюшие логи. Если Вы заметите неадекватное поведение управления (клавиатура / геймпад), то, пожалуйста, уведомите нас об этом.
Заранее благодарен за Ваш интерес :)
Утечка бета-геймплея Redfall
Автор: Dead By Daylight
Короткий ролик, а так же некоторые подробности будущего проекта Arkane.
Собственно о чем рассказывается в видео, где и демонстрируется отрывок с плей-теста:
- Всего 4 героя доступно в бета-тесте (ранее была информация что в билде было 6 героев)
- Протестировать ко-оп не было возможности
- На тесте были квесты посвященные «гнездам» (видимо подразумевается вампирским), довольно сложные, а так же упоминалась «ведьма», которую было не просто победить
- В квесте пришлось переключаться между видом от первого лица к третьему лицу
- Идет глобальное тестирование и из-за наплыва игроков частые краши (тестер из Пуэрто-Рико)
- Тестер пообещал показать больше на следующей недели (не думаю что у него получится)
- Билд который был у игрока датирован сентябрём 2021 года
Видео которое еще можно найти на ютубе, ниже:
Устану ли я играть, нужно ли уметь кодить и чем вообще занимаются QA в геймдеве
До прихода в индустрию я искал материалы про QA в геймдеве, чтобы понять отличия от других областей. Результатов нашлось немного — обычно пишут про общие или абстрактные вещи, или о том, что это простой путь в геймдев, или рекламируют курсы. В итоге захотелось закрыть некоторые вопросы самому, так как на собеседованиях я вижу, что далеко не все представляют себе эту профессию на практике.
Надеюсь, материал поможет получить знания о реальной работе тестировщика в геймдеве, а попутно прокомментирую некоторые мифы и опишу наш воркфлоу на конкретных примерах.
Дисклеймер: в статье я не буду разделять специалистов QA и тестировщиков. Кому-то просто не нравится термин «тестировщик», кто-то акцентирует на том, что тестирование это только частный случай контроля качества. Вопрос во многом философский, оставим его за рамками этого материала.
Начнем с небольших общих вопросов, которые часто получаю или встречаю в сети. А потом перейдем к более практичным вещам — инструментам, задачам и воркфлоу.
FAQ
— Правда ли, что QA — это легкий путь в геймдев?
Возможно, при одинаковом отсутствии навыков войти в геймдев тестировщиком легче, чем, например, серверным разработчиком. Но назвать этот путь легким точно нельзя. Просто потому что не любой человек сможет этим заниматься. У нас в среднем из 10 кандидатов на позицию джуна работу получают только двое, хотя специалисты нужны почти всегда.
Тем не менее, периодически наши тестировщики меняют специализацию и переходят в геймдизайн, левел-дизайн и даже UI. И это хорошо, потому что отделу QA намного легче работать с геймдизайнером, который ранее был тестировщиком.
— Нужно ли тестировщику уметь кодить?
На позиции джуна точно нет. Но в последствии нужно научиться понимать хотя бы синтаксис, это всегда пригодится.
Мы, кстати, периодически помогаем разработчикам обнаружить опечатки в коде. В Git есть история изменений, тянем коммит, который только запушили, он не запускается, открываем лог и понимаем, где может быть проблема. Идем с этим к программисту и фиксим за пару секунд.
— Какие навыки нужны тестировщику?
Банально, но первый пункт — человек должен сильно любить игры, посвящать им много времени. Самые простые баги, основанные на игровых механиках, геймер увидит сразу, а человек, не увлекающийся играми, может легко пропустить.
Второе — софт-скиллы. Хард-скиллов у новичка обычно нет, но всегда можно научить пользоваться ADB Tools, Xcode, Git, Jira или Unity. А вот научить правильно и лаконично общаться письменно и устно — намного сложнее. Мы больше остальных коммуницируем с другими отделами: и устно, и письменно. Например, нужно завести баг так, чтобы он был понятен другим тестировщикам, разработчикам, геймдизайнерам и фиче-овнеру.
Скажу так: интроверт может быть прекрасным разработчиком, но для тестировщика это может привести к сложностям в процессе обучения, работы и роста. Потому что у нас тестировщик является связующим звеном между отделами.
Например, есть фича. Читаешь ТЗ, начинаешь проверять и находишь подводные камни — моменты, которые не описаны в ТЗ и непонятно, как они должны правильно работать. У тестировщика есть два варианта действий: плохой и хороший. Плохой — придумать самому, как она должна работать, но с большой долей вероятности это закончится повторной проверкой функционала. Хороший вариант — идти к геймдизайнеру, который ведет эту фичу, и вместе с ним пытаться понять и отрегулировать неопределенное место так, чтобы всем было понятно.
Другой пример. Программист в рамках фичи сделал функционал, перевел тикет в тестирование, и вроде все понятно. Тестировщик смотрит, видит, что затрагиваются конфиги, прогресс игрока на сервере, но как — непонятно, а в код залезть может не каждый. Тогда нужно поговорить с разработчиком, постараться узнать, что он делал, попросить прописать сценарии, которые он считает важными и которые могут пострадать от его нового кода. Это сокращает время и снижает риски появления критических багов.
— Правда ли, что тестировщик просто целый день играет?
Самый популярный стереотип. Конечно, это не так. Хотя первую неделю джуны играют 100% времени, некоторые даже бросают в этот момент.
Когда работа уже на потоке, то процентов 70% времени занимает тестирование, коммуникация внутри отдела, написание чек-листов, работа с фичами. Остальное — поиски сценариев от игроков и коммуникация с другими отделами.
Кроме того, через какое-то время рабочий проект уже перестает восприниматься как игра. Это может вызвать проблемы, так как нужно не разучиться оценивать проект с точки зрения пользовательского опыта. Поэтому я люблю джунов — у них это получается, свежим взглядом они видят то, что могут не заметить профессионалы.
— Останется ли у меня желание играть после работы?
Мне говорили, что я не смогу играть, когда шел в тестировщики, но все хорошо. Играю, как и раньше. Иногда морально трудно после работы, но это было в основном в период адаптации.
Единственное — стал много обращать внимание на баги в других играх, оказывается в AAA-проектах их очень много (и я не про Cyberpunk 2077).
— Нужно ли знать английский язык?
Я бы назвал это желательным, но необязательным требованием, хотя все зависит от компании. Нужно хотя бы уметь читать и понимать англоязычные форумы, тот же Reddit. Также мы сидим на форумах читеров, чтобы отслеживать уязвимости, так как разрабатываем мобильный PvP-шутер.Был случай, когда каким-то способом игроки массово стали доставать много предметов из клановых сундуков, не тратя валюту. Мы это видели по аналитике, но не могли понять, как они это делают. Тогда я зашел на Reddit во вкладку игры и в одном треде увидел описание способа. Нужно было открыть сундук и быстро переключиться на второго персонажа. В момент перехода есть временной фрейм, когда кристаллик загрузки подвисает — сервер переключает прогресс. В этот момент нужно выключить приложение, потом включить, перейти обратно на первого персонажа и сундук снова станет доступен. При этом все предметы с предыдущего оставались.Еще время от времени читаем тематические форумы и сайты, на которых выкладывают моды для Pixel Gun 3D. Такой ресерч является постоянной задачей — раз в неделю один человек проверяет, есть ли новые моды. Если есть — проверяет их на работоспособность.
— А можно ли обойтись совсем без QA-отдела?
На большом проекте точно нет. Тот, кто пишет код, — смотрит на него субъективно с той стороны, с которой написал. Например, видит, что вкладка работает, но может не проверить ее взаимодействие с остальными вкладками, фичами, переходами и так далее.
Даже в самый отполированный релиз пролазят баги. Причем они часто не связаны с тем функционалом, который разрабатывали — и всплывают параллельно, в тех местах, на которые повлияли новые фичи. За предыдущий месяц мы нашли более 150 только таких багов.
Инструменты тестировщика
Перейдем к практике.
Как я и говорил, на начальном этапе для тестировщика самое главное — это умение общаться и грамотно излагать мысли. Но с инструментами все равно придется знакомиться. Сначала меня самого пугали слова, вроде Git, коммит, смоук-тестирование, но к этому быстро привыкаешь.
Один из основных инструментов тестировщиков — это Jira, там ведутся все фичи, баги, процессы.
Также используем движок, на котором написана игра — Unity (хотя в некоторых компаниях тестировщиков не пускают к движку, просто дают готовый билд и задачу).
Потом идут система контроля версий (у нас это Git), ADB Tools (входит в Android Studio) — пакет драйверов для взаимодействия с приложениям на Android и Xcode для работы с iOS. Еще используем 3uTools, инструмент, по функционалу похожий на iTunes — позволяет устанавливать приложения, удалять, делать бэкапы, восстанавливать из них данные, джейлбрейкать устройства.
Лайфхак для джунов: перед собеседованием можно посмотреть стек технологий, который использует компания (например, часто его указывают в тексте вакансий) и пару обучающих роликов на YouTube по этим инструментам. Так вы на собеседовании уже будете выгодно выделяться на фоне многих других, поверьте.
Если в игре есть читеры, желательно уметь работать с программами для взлома игр — Game Guardian, Titanium Backup, джейлбрейками для iOS, через которые можно ставить твики. Как минимум, нужно повторить то, что делают читеры, чтобы потом закрыть уязвимость.
Также есть вещи, уникальные для каждого проекта/компании. У нас, например, это собственный менеджер конфигов — в нем редактируются и проливаются все конфиги для фич.
Отдельно стоит навык работы с чек-листами. Очень часто люди относятся к ним несерьезно, а в результате критические баги уходят в прод. Сами мы давно убедились, что чек-листы реально помогают не пропускать важные вещи, на которые смотришь уже в 30-й раз. Одно время, когда было много задач, некоторые тестировщики забывали вести чек-листы и раз за разом пропускали критические баги. Но когда мы стали вместе пристальнее обращать внимание на прохождение чек-листов, то за несколько месяцев не было пропущено ничего критического.
Первый месяц новичка
Все понимают, что с новичков нельзя много требовать. Нередко они даже не играли в проекты компании, куда приходят устраиваться (еще один лайфхак для джунов, как выделиться). Поэтому первая неделя для них начинается с ежедневной игры, без консоли разработчика, прямо по восемь часов в день. И бывает, что люди не справляются.
Затем прошу выписывать все, что показалось странным. В конце дня смотрим этот список и обсуждаем, что является багом, а что нет.
Через неделю рассказываю про ADB, сервера, версию игры с консолью разработчика и ставим эту версию на устройство. Затем еще 3-5 дней человек знакомится с консолью, изучает функции, например, добавляет валюту, отключает серверное время, переходит на тестовый сервер, накручивает уровень, пропускает тренировку, включает бессмертие, спидхак и так далее. Нужно знать, что каждая функция из себя представляет, и задавать как можно больше вопросов.В итоге первые две недели уходят на то, чтобы будущий тестировщик разобрался, где что находится.
На третьей неделе начинаем проходить чек-листы — каждый чек-лист, каждый пункт, что как работает. Это важно и для компании, так как помогает актуализировать чек-листы и проверяет внимательность новичка. Вечером снова встреча 1-1.С четвертой недели добавляем новичка третьим в пару к опытным ребятам (у нас тестировщики исторически работают в парах над каждой фичей). Он изучает, как работать с задачами, я рассказываю про Jira, Git, Unity и так далее. Через полтора месяца получается компетентный специалист.
Что нужно тестировать
У нас есть большой список чек-листов (около сотни) по всем фичам, которые были созданы за все время. В этом списке бывают неактуальные чек-листы — но это проверка на внимательность для новичков в первый месяц.
Если брать правила создания чек-листа, то я сделал универсальный шаблон с проверками, которые работают для любой фичи. Это, например, проверка локализации, аппаратного бэка (кнопка раньше была физическая, теперь на Android всплывающая) — все об этом знают, но разработчики иногда забывают добавить.
Также, если того требует фича, нужна проверка взаимодействия клиента и сервера, отправки и получения пакетов запросов и ответов. С недавних пор добавилось шифрование.
Еще есть внутрипроектные проверки. В игре есть офлайн-режим, в нем доступны мини-игры, кампания, арсенал. Но нет возможности покупки и сохранения прогресса. Купленная в офлайне пушка не учитывается в онлайне. Отключение и восстановление прогресса иногда вызывает проблемы, поэтому проверяется каждая фича.Отправку и получение аналитики, миграции и накаты тоже нужно проверять. Мы используем Photon (про него уже была статья) — регулирует поведение игровых комнат и ловит аномальные значения (например, скорость передвижения) — то есть читеров. Но часто бывает, что при создании новых режимов и пушек про это забывают. В консоли разработчика есть галка «не детектить читы», и она включена по умолчанию. Поэтому в чек-листе есть универсальный пункт — нужно отключить ее и проверить, что тебя не кикает.
Другие проверки касаются, например, логики работы фичи. Как работают таймеры, конфиг и так далее. И другая часть — визуальное отображение фич.
Виды тестирования
Расскажу еще про несколько терминов, которые часто пугают новичков.
Функциональное тестирование — это проверка приложения на правильность работы всех функций. Проводим его прямо перед релизом апдейтов в магазин. Есть большой чек-лист, в котором затрагивается абсолютно весь функционал и то, как он должен работать. Весь отдел садится и идет по этому списку, в том числе смотрит и старые фичи.
Тестирование совместимости — проверяем правильность работы приложения в разных окружениях. Отличаются версии Android, iOS, соотношение сторон, возможность/невозможность включения полноэкранного режима (Android), архитектура ARM64 или Armeabi-v7a. Внешний вид и функциональность везде должны совпадать.
Регрессионное тестирование — это тоже тестирование уже существующих функционалов игры. Так мы можем выяснить, не появились ли ошибки в работе старых фич после добавления всех новых в одной ветке. Естественно, регрессионные тесты проводятся также и при функциональном тестировании новых фич. Но нам крайне важно убедиться, что ничего не сломалось в тот момент, когда все новое «встретилось» в одной ветке. Регрессионное тестирование у нас начинается, как правило, в предрелизную неделю.
Плейтест — используется, в основном совместно с геймдизайнерами для поиска и устранения проблем, в симуляции обычных игроков, с максимально реалистичными сценариями и настройками.Смоук-тестирование — проводим, когда знаем, что завершили полное функциональное тестирование, билд был стабилен, но по какой-либо причине (реджект Google Play или App Store, не пролили локаль) пришлось пересобрать. В таком случае, вместо того, чтобы повторно проводить полное функциональное тестирование (а оно занимает 3-4 часа), достаточно убедиться, что все основные функции игры работают — покупки, вход в матч, матчмейкинг, реклама, установка/переустановка приложения, накат. Все перепроверяем и релизим.
Есть и другие виды тестирования, но у нас они не прижились — оставим их для более глубокого погружения в тему.
Как заводить баги
Есть золотое правило — «что, где и когда». Создаешь тикет в Jira, пишешь лейбл и нужно максимально лаконично написать, что, где и при каких обстоятельствах сломалось. Так можно сэкономить время при починке и проверке, поэтому не стоит это игнорировать. Например, состоялся релиз режима импостер на Android, провели функциональное тестирование и обнаружили, что он сломался. Что нужно делать:
1. Написать лейбл: «Режим предатель (что) ломает геймплей (где)». Все понятно.
2. В описании рассказать, как воспроизвести баг. Есть шаги воспроизведения — ожидаемое и наблюдаемое поведение. Все это обязательно заполняется.
3. Указать критичность, приоритет, ветку исполнителя, версию фикса, регулярность бага и платформу. Это нужно обязательно для экономии времени. Гораздо проще сразу указать все исходные данные, правильный сценарий воспроизведения со скриншотами, пояснениями, как должно и не должно быть.
4. Назначить исполнителя, то есть разработчика, который будет фиксить баг.
Но есть один момент: мы придерживаемся правила, что если что-то получилось воспроизвести только один раз — то это пока еще не баг, и его рано заводить в Jira.
Например, игрок пожаловался в саппорт-сервере Discord на сломанную скролл-сетку в арсенале. Факт бага есть, но непонятно, как воспроизвести. Если это критичный баг перед релизом, то смотрим всем отделом. Если не критичный, то на будущее заводим сами себе билет на поиск сценария. Выставляется версия, до релиза которой нужно сценарий найти. Когда появляется время — тестировщик возвращается к поиску.
Рабочий день на примере появления нового оружия
У каждой пары тестировщиков есть свой чат в Slack и определенная область ответственности. Есть те, кто проверяют монетизацию и коммерцию, есть проверяющие новый контент, батл пассы, новые режимы и так далее.
Утром я выстраиваю им в Slack очередность списка задач по приоритету. Они открывают Jira, сверяются с тем, что я им скинул, меняют статус на «На тестировании», переходят на ветку, начинают проверять.
Допустим, в игре появилось новое оружие. Кидаю задачу, тестировщик переходит на ветку и ставит собираться билд с фичей, чтобы через три часа она собралась и можно было ее проверить на устройстве. У нас есть билд-сервер — это локальная машина, на которой есть интерфейс, два билдера Android и iOS. Тестировщик заходит и ставит на Android и iOS нужную сборку.
Кидает номера этих сборок в комментарии к эпику фичи в Jira, чтобы, например, геймдизайнер тоже мог скачать этот билд. Открывает чек-листы (если фича новая, то сначала составляет) и по ним проверяет пушку.
Находит проблемы, маркирует непройденные пункты. Затем в Jira заводит отладку, что вот там, например, неправильная анимация по сети. Потом берет следующую пушку, так как в релизе у нас их в среднем 15 штук. Ждет фиксы.
В оружии большая часть проблем обычно связана с визуалом — их решают художники. Они часто просят помочь воспроизвести, потому что редко контактируют с геймплейной частью. Тестировщик вместе с художником воспроизводит баг и после фикса снова проверяет по чек-листам. Потом закрывает задачу, ставит статус «готово».
Когда статус «готово» стоит у всех задач — собираем сборку, которую можно показать продакт-овнеру и фиче-овнеру. Они смотрят пушки, если все хорошо — фича сливается в основную ветку.Правда, у Git есть интересная особенность — после слития что-то может перестать работать (из-за конфликтов) так, как было нужно. Поэтому после слития нужно всегда проверять фичу по чек-листам заново.
Советы для новичков и полезные ссылки
- Из книг могу посоветую то же, что и все — «Тестирование dot com» Романа Савина. Пригодится для понимания процессов и определения желания этим заниматься.
- Также регулярно читаю Хабр и смотрю сайты вроде 4pda, потому что важно следить за новыми девайсами и ОС. Недавно был кейс с iOS 15, когда игра крашилась в 100% случаев. Хорошо, что проверили еще за пару месяцев.
- Ну, и главное — не бояться. Помню себя — было страшно, ничего не понимаешь, а вокруг все сыпят непонятными терминами. При этом спросить неудобно, потому что все говорят спокойно. Но в геймдеве и IT не существует глупых вопросов. Бывает, что человек долго чего-то не понимает, но маскируется, а потом в критический момент возникают проблемы. Поэтому стесняться точно не надо, иногда софт-скиллы стоят на первом месте.
Автор статьи: Андрей Пчельников