Комментарии 8
Отличная статья!
Использовались ли во время разработки настолки инструменты автоматизации? Кажется, что тестирование исключительно руками требует огромного количества времени, по сравнению с тем, чтобы запрограммировать модель и погонять с разными настройки баланса.
Мысль интересная! Автоматизация не использовалась при разработке данной настолки, так как было с кем тестировать из людей, да и время позволяло. И здесь все же огромную роль играет человеческий фактор при выборе действий игроков (майндгейм думаю тяжело закодить) и рандом в игре сведен к минимуму. Плюс игра быстрая, поэтому за вечер отыграть 10-15 партий не составляло труда. Тесты проводились в разных компаниях, и практически у всех процент победы хозяина был чуть выше, чем у енотов, что приемлемо для жанра игры один против всех. Так что, если есть свободное время и люди, с кем можно тестировать игру, автоматизация не потребуется. Наверное автомазиция необходима при разработке каких-то одиночных игр по типу Оскверненного Грааля или игры с большой вариативностью действий, где действительно тяжело воспроизвести все возможные сценарии вручную. Если автоматизация будет участвовать при тестировании настольных игр в дальнейшем, обязательно напишу вторую часть этой статьи :)
Может пропустила в статье, но стало интересно, как и где фиксировали результаты тестов? были ли это какие-то баг-репорты и протоколы тестирования? и какая по количеству работала команда над созданием игры (имеется в виду весь процесс производства)
Привет! Результаты тестов фиксировались в телеграм-чате с моей командой тестировщиков, а результаты тестов и текущие баги со стороны издательства заказчики присылали в другой совместный с ними чат, также в телеграме. За 2-3 дня до тестов я писал тест-план в чат моей команды, что конкретно нужно протестировать, во время тестирования мы фиксировали количество побед за обе стороны, постоянно меняя роли игроков. В процессе игры с помощью совместного брейнштурма отмечали положительные и негативные моменты нововведений, далее рефакторили правила и отправляли новую версию игры на тесты заказчикам. Сотрудники издательства и подключённый к проекту девелопер играли по новым правилам и возвращались с обратной связью в виде отчета, что понравилось, что не понравилось в совместный с ними чат, далее мы приступали к обсуждению текущих багов, в последствии обдумывая, как в теории их можно пофиксить в последующих тестах.
Во время разработки лично я взаимодействовал с менеджером проекта, она же автор сеттинга, девелопером и со своими коллегами, а в целом над игрой работали еще иллюстратор, руководитель проекта, дизайнер-верстальщик, корректор и конечно же фокус группа.
класс, спасибо за развёрнутый ответ :)
насколько удобно было общаться в тг по багам? это был отдельный канал только для багов или нет? не терялась ли информация или как-то хэшировали сообщения?
Тг подошел замечательно). У нас был один канал, где мы обсуждали текущие проблемы. Как правило, со своей стороны мы отправляли обновленные правила, чтобы коллеги могли сыграть в новую версию. Параллельно мы были на связи, и в случае возникновения вопросов, мы оперативно на них отвечали и какие-то мелкие детали не доводили до обсуждений на общих созвонах в конце "спринта", где все понимали, что из себя представляет текущая версия. Тогда у нас оставалось время на обмен мыслями по доработкам и обратную связь от тестов с нововведениями. Спринт за спринтом, спустя сотни тестов, все друг друга уже понимали с полуслова, и тг уже становился не каналом для брейнштурма, а как ветка в гите, где каждое сообщение несет ключевой посыл, например, на тему проработки победных очков или кол-ве миплов в игре при масштабировании кол-ва участников. Ознакомились, протестировали, вернулись с обратной связью и так до тех пор, пока продукт всех не устроит) А для Хэширования отлично подходят закрепы! Плюс в тг очень удобный поиск по сообщениям, воот :)
Тестирование и создание настолок: как я связал две этих сущности в своей жизни