Сообщество Империал: CK2 Dev Diary №57: Жизнь бага - Crusader Kings II (Крестоносцы II) - Paradox Interactive - Библиотека - Сообщество Империал

Стратегии, Игровые Миры, История, Total War
  • Поиск
  • Законы
  • Сообщество
  • Репутация
  • Экономика
  • Больше
Уважаемый Imperial Гость, анонсирована первая игра серии Total War Saga - Total War Saga: Thrones of Britannia

Информация об авторе

inferno-chan
  • Автор: inferno-chan

Информация по статье

  • Добавлено: 11 Июл 2017, 20:26
  • Просмотры: 351

Дополнительно

Классификация статьи: [Статья]
Раздел Техподдержки: Перейти
Ссылка на сообщение: Перейти
Перевод: Да

Последние Статьи

  Повесть о доме Датэ.

Повесть о доме Датэ.Titus_Maygrem1 · 07 Ноя 2017, 20:20

  EU IV Dev Diary — 7 ноября 2017

EU IV Dev Diary — 7 ноября 2017Tempest · 07 Ноя 2017, 16:54

  HOI4 Dev Diary - Airplanes and Lootboxes

HOI4 Dev Diary - Airplanes and Lootboxesløgan · 06 Ноя 2017, 09:22

  HOI4 Dev Diary - Bag of Tricks #2

HOI4 Dev Diary - Bag of Tricks #2løgan · 01 Ноя 2017, 02:28

CK2 Dev Diary №57: Жизнь бага

Описание: Дневники разработчиков и прочая информация про Crusader Kings 2
Дневник разработчиков №57: Жизнь бага

Всем доброго дня. Я Magne «Meneth» Skjæran, программист CK2. Раньше я писал дневники разработчиков о моддинге, оптимизации и повышении удобства игры, а также дневник на прошлой неделе, рассказывающий о том, за что отвечает каждая роль в команде.

Лето всё ещё продолжается, и значительная часть офиса разъехалась до конца июля, включая большинство команды CK2. Шоу должно продолжаться, поэтому в эти четыре недели я напишу большинство или вообще все дневники разработчиков CK2.

Поскольку нахождение большей части команды в отпуске означает малый прогресс в разработке, поэтому эти четыре дневника будут довольно скупы на информацию о предстоящем дополнении и обновлении, однако несмотря на это я надеюсь рассказать вам о некоторых интересных результатах, информации и забавностях.

Сегодня я расскажу о жизненном цикле бага. По существу, это будет обзор того, как ошибка проходит все стадии, начиная с обнаружения и заканчивая выпуском её исправления, а также того, кто участвует на каждом этапе.

В конце этого дневника я также поделюсь пятью пунктами списка изменений обновления 2.8, выбранных (практически) случайно.


Баг

Чтобы проиллюстрировать этот процесс, я буду использовать следующую ошибку в качестве примера:
  • Исправлена ошибка, из-за которой в некоторых случаях священники религий, в которых им не разрешено вступать в брак, могли жениться или обручиться с кем-либо.

Исправление этой ошибки было включено в обновление 2.7.1. По сути, она была связана с тем, что Папа Римский оказывался в родстве с теми, кто так сильно любит кровнородственные браки1, что они обручались с Папой, хотя ему и не разрешено вступать в брак. Хведода2 – мощная штука, но она всегда заканчивается плачевно: в момент, когда племянница Папы достигала совершеннолетия, помолвка расторгалась.

Оглядываясь назад, в списке изменений должно быть чётко указано: «Починили Папу, любящего хведоду столь сильно, что он обручился, несмотря на то, что ему не разрешено жениться». Век живи, век учись.


Обнаружение

Эта ошибка была обнаружена одним из наших бета-тестеров 12 февраля 2017 года во время игры. Он заметил, что Папа матрилинейно обручён со своей племянницей, и сделал сохранение в момент, после которого это будет происходить постоянно.

Однако обнаружение ошибки бета-тестерами является лишь одним из многих способов. Другие варианты включают:
  • Плейтест: тестеры службы контроля качества проводят часть своего времени, просто играя в игру, хотя обычно с упором на что-то, над чем мы работаем. Например, во время разработки «Монахов и мистиков» основное внимание могло быть уделено какому-то конкретному обществу. Во время тестирования они сообщают о любых ошибках, с которыми сталкиваются, а также отмечают проблемы с балансом, удобством и т.д. В зависимости от стадии разработки они могут быть сообщены даже напрямую. Если система ещё находится в процессе создания, сам ответственный разработчик может столкнуться с проблемой, однако если разработка уже завершена, то обычно делается полноценный отчёт об ошибке.
  • Проверка выполнения: когда задача (например, «добавить систему массовых действий над заключёнными») завершена, служба контроля качества проверяет, работает ли она в соответствии со спецификацией. Если в течение этого времени они обнаружат какие-то проблемы, они либо снова откроют задачу, либо сообщат об ошибках в задаче. Подробнее о проверке вы можете прочитать в разделе «Проверка» этого дневника.
  • Разработчики, не являющиеся тестерами: разработчики, не являющиеся членами команды по контролю качества, тоже играют в игру и сообщают о любых ошибках, с которыми они сталкиваются, хотя поиск ошибок и не является их основной целью в проекте.
  • Мониторинг форума: хотя остальные методы обнаружения ошибок сосредоточены на обнаружении проблем до выпуска обновления, часть их всё же просачивается в релиз. Когда это случается, их часто обнаруживают обычные игроки, часть из которых в конечном итоге создаёт отчеты об ошибках на форумах, на reddit или чём-то подобном. Служба контроля качества проводит некоторое время за мониторингом этих площадок, делая внутренние отчёты об ошибках, когда ошибки могут быть воспроизведены. Если ошибка не может быть воспроизведена на основе предоставленной информации, они обычно запрашивают дополнительную информацию. Внутренний отчёт об ошибке создаётся только в том случае, если проблема может быть воспроизведена или с ней сталкивается большое количество людей. Поэтому если вы хотите, чтобы ваш отчёт об ошибке имел наибольший шанс привести к её исправлению, вы всегда должны описывать шаги по её воспроизведению или предоставить сохранение, если это возможно!

Ошибки обнаруживаются и рядом других способов, но эти четыре варианта, а также бета-тестирование, охватывают большинство случаев.


Отчёт

Об обнаруженной ошибке необходимо сразу составить отчёт. Наша база данных ошибок содержится в веб-приложении по управлению проектами Jira, которое предоставляет множество способов для лёгкого управления задачами, чтобы их можно было планировать надлежащим образом и ничто не ускользало от внимания.

Imperial

Выше вы можете увидеть отчёт о помолвке Папы.

Основные моменты, обязательные для отчёта:
  • Название. Заголовок, кратко излагающий суть проблемы. Предполагается, что он будет соответствовать формату: проект – дополнение – область действия – описание проблемы. В данном случае: «CK2 – МиМ – ИИ – Папа матрилинейно обручается с дочерью своего родственника-короля». В названии должно быть чётко указано, в чём состоит ошибка и где она была обнаружена.
  • Описание. Описание содержит любые детали, которые не могут быть помещены в заголовок. Оно часто содержит описание того, что игрок делал когда столкнулся с ошибкой, предположения о возможных причинах или, в случае ошибок, обнаруженных путём мониторинга форума, источник отчёта об ошибке.
  • Шаги для воспроизведения. В известной мере это наиболее важный раздел, он содержит информацию о том, как ошибка может быть воспроизведена. Без этого большинство ошибок трудно или вообще невозможно исправить, так как информации о том, что нечто может случиться, зачастую недостаточно чтобы понять, как это может произойти. Этот раздел используется как человеком, исправляющим проблему (см. «Исправление»), так и человеком, проверяющим сделанное исправление (см. «Проверка»).
  • Результат. Отчёты всегда содержат как ожидаемый результат, так и фактически полученный, чтобы ещё лучше уяснить, в чём реальная проблема. Часто это довольно очевидно, но для некоторых вещей, например, для проблем с балансом, эти разделы могут сильно помочь. Также они облегчают выяснение, действительно ли проблема была исправлена или же нет (см. «Проверка»).
  • Вложения. Часто прилагается скриншот проблемы. Обычно также предоставляется сохранение, если это облегчает воспроизведение ошибки. Для сбоев и тому подобного также прилагаются записи логов, а также аварийный дамп, который может быть использован программистом для поиска места в коде, где произошел сбой игры.

Кроме этого есть ещё целый ряд полей, но они обычно заполняются позднее в процессе обработки.


Распределение

Как только об ошибке составлен отчёт, необходимо решить, кто будет ответственным за её исправление, насколько на самом деле важно её исправить и когда она должна быть исправлена. Ответственность сначала определяется по дисциплине: ошибка может быть отнесена к проблемам со скриптом, кодом или художественному дизайну в зависимости от того, что её вызывает. Это распределение обычно выполняется тестерами службы контроля качества, если оно уже не было произведено в процессе создания отчёта об ошибке.

Приоритет устанавливается в зависимости от того, насколько важно исправить данную ошибку; его значение находится в диапазоне от 0 (обязательно для немедленного исправления) до 5 (не первостепенно). Например, сбой игры имел бы приоритет 1 – Обязательно для исправления, в то время как ошибка с помолвкой Папы имела бы приоритет 3 – Средний. По вопросу приоритета последнее слово всегда за руководителем проекта, но, как правило, приоритет ошибок определяет служба контроля качества, а руководитель проекта определяет приоритет задач в целом.

Точно так же существует Серьёзность ошибки, которая варьируется от Блокирующей до Отсутствует. Вместо отражения важности её исправления серьёзность ошибки показывает, насколько она значительна. В некоторой степени эти величины коррелируют, но у вас может быть что-то вроде очень заметной орфографической ошибки с высоким приоритетом, но малой серьёзностью. Уровень серьёзности определяется тестерами, а не руководителем проекта.

Затем нужно решить, когда ошибка должна быть исправлена. Это делается путём отнесения к определённому спринту (периоду времени, в течение которого должен быть завершен конкретный набор задач. У команды разработчиков CK2 они длятся четыре недели). Исправление важных ошибок обычно назначается на текущий спринт, в то время как менее важные, как правило, оставляются на дополнительные недели по наведению лоска, а не назначаются на какой-то регулярный спринт. Исключение составляют ошибки, связанные с новыми функциями. Они почти всегда относятся к текущему спринту, даже если не слишком серьёзны. Это связано с тем, что считается более важным не добавлять новых ошибок, чем исправлять ошибки в уже выпущенном продукте. Тем не менее, старые ошибки по-прежнему привязаны к неделям по шлифовке игры, когда основная работа над дополнением уже завершена. Во время спринтов по добавлению новых функций последние четыре недели посвящены исправлению ошибок; в течение первых трёх недель исправляются только те ошибки, которые блокируют другие направления работы.

С началом спринта по исправлению ошибок каждая ошибка закрепляется за конкретным человеком. За это ответственен руководитель проекта, однако он часто делегирует эту обязанность специалистам. Например, разработчики контента, как правило, делят ошибки между собой самостоятельно, не дожидаясь руководителя проекта.


Исправление

Время исправлять ошибки в спринте наступает тогда, когда решены все более важные проблемы. Человек, за которым была закреплена ошибка, ставит ошибке статус «Начата работа», тем самым информируя остальную часть команды о том, над чем он работает.

Затем этот человек будет пытаться воспроизвести ошибку и пытаться выяснить, где что-то пошло не так. В случае помолвки Папы ошибка была присвоена мне и воспроизводилась она безупречно. Приостановка выполнения кода по обручению кого-либо с Папой помогла мне установить «точку останова» в коде логики ИИ по вступлению в брак. Это позволило мне восстановить всю цепочку и обнаружить, где именно в коде находилось теократическое требование к браку. В конце концов оказалось, что функция CanMarry на самом деле никогда не проверяла эти требования, только само дипломатическое действие по заключению брака. Таким образом, помолвки всё ещё могут быть заключены, однако будут расторгнуты, когда вовлеченные персонажи достигнут совершеннолетия и попытаются вступить в брак.

Конечным результатом стала одна новая строчка кода в функции CCharacter::CanMarry:

if ( ( GetGovernment()->IsTheocracy() && !GetReligion()->CanPriestsMarry() ) || ( pCharacter->GetGovernment()->IsTheocracy() && !pCharacter->GetReligion()->CanPriestsMarry() ) )
		return false;


Она просто проверяет, является ли какой-либо персонаж теократом, принадлежащим к религии, которая не позволяет своим священникам вступать в брак.

После перекомпиляции игры я снова повторил шаги по воспроизведению ошибки и увидел, что помолвка больше не происходит.

Как только исправление произведено, делается запись в список изменений. Исправление и запись в списке изменений затем передаётся в наш репозиторий для игры. Наши серверы сборки затем компилируют игру и через несколько часов после полуночи новая версия игры загружается в Steam для наших бета-тестеров.

Затем ошибка помечается как «Исправленная» с сообщением, подводящим итог тому, что было сделано для её решения и для какой версии игры было сделано исправление. В случае помолвки Папы ошибка была отмечена как исправленная 6 дней спустя после подачи отчёта по ней, но этот срок может легко варьироваться от нескольких минут до нескольких месяцев.


Проверка

Далее, тестеры проверяют, действительно ли ошибка была исправлена и что не появилось новых проблем в этой области.

Это делается при помощи выполнения шагов по воспроизведению ошибки, если проблема всё ещё возникает, и, если проблема особенно сложна, попыток воспроизвести её другими способами.

Как упоминалось в разделе «Обнаружение», тестеры проводят плейтест для поиска новых ошибок, в которые часто попадают ошибки, являющиеся непреднамеренными побочными эффектами исправлений других ошибок.

Когда служба контроля качества убеждается в том, что ошибка действительно устранена, они помечают проблему как закрытую и на этом процесс исправления обычно завершается. Если ошибка по-прежнему сохраняется в той или иной форме, проблема снова открывается и мы возвращаемся к шагу «Исправление».

Иногда ошибка может появиться даже после проверки. Это, как правило, приводит к повторному открытию и исправлению проблемы.

В случае помолвки Папы ошибка была проверена через 45 дней после того, как она была помечена как исправленная. Мы стараемся избегать задержек на проверку дольше, чем длительность спринта или около того (один месяц), поскольку, как правило, вернуться и исправить что-то правильно легче, если вы недавно уже работали над этим.


Выпуск обновления

Ошибка исправлена и поэтому настало время для выпуска обновления, однако процесс ещё не завершен.

Хотя конкретная ошибка была проверена как исправленная, проект в целом должен преодолеть один последний шаг, чтобы считаться готовым к выпуску: дымовое тестирование3.

Дымовой тест по существу проверяет отсутствие критических ошибок в трёх операционных системах, которые мы поддерживаем: Windows, Mac и Linux. В отличие от других этапов этого процесса, дымовое тестирование в нашей студии проводится головным отделом по контролю качества, а не командой CK2.

После завершения дымового тестирования обновления никакие другие изменения в обновление не могут быть внесены. Через несколько дней или недель обновление будет выпущено и ошибка будет исправлена у всех игроков.


Итоги

В общем, для обеспечения поиска ошибок, их исправления и закрепления мы имеем целый процесс, состоящий из нескольких этапов. Несмотря на это, ошибки иногда всё же просачиваются, поскольку CK2 – довольно сложный зверь. В каждой версии всегда есть известные ошибки, так как в какой-то момент обновление должно выйти, а исправление одной ошибки может легко вызвать другую. Мы стараемся минимизировать количество известных ошибок, отводя длительный период времени на полировку игры перед каждой версией, а также имея небольшой период, в течение которого никакие изменения не допускаются вообще, кроме исправлений критических ошибок. Ошибки будут всегда, но мы всегда стараемся не вводить новые и уменьшать количество уже существующих.

Надеюсь, этот обзор того, как мы обрабатываем ошибки в CK2, был для вас познавательным.

Теперь, как и было обещано, привожу пять записей из списка изменений предстоящего (в данный момент без известной даты выхода) обновления 2.8:
  • ИИ научен грамотности и больше не ищет заданий «опществ»4, поскольку на самом деле они называются заданиями «обществ». Благодаря этой новоприобретённой грамотности ИИ теперь лучше справляется с определением цели заданий.
  • Исправлено использование рассмотрения законопроектов Советом, позволявшего вам обойти необходимость использования услуги со стороны вашего сюзерена.
  • Манихейцам добавлен священный орден.
  • Воспитатели теперь могут быть назначены прямо с рождения (хотя до шестилетнего возраста подопечного никаких эффектов от них не будет).
  • ИИ больше не сможет заключать матрилинейные браки, если они были отключены в игровых правилах.

На этом всё. На следующей неделе я расскажу об улучшениях моддинга, которые мы внесли в обновлении 2.8.

Оригинал
Источник


1 – Брак между супругами, имеющими общего предка, обычно подразумевается, в ближайших поколениях.
2 – Брак между близкими родственниками (авест. хвайтвадатха): между отцом и дочерью, матерью и сыном или братом и сестрой. Наиболее похвальный брак с религиозной точки зрения, так как этот вид брака в глазах древних персов предохранял чистоту семейной крови и не считался инцестом. Практиковался персидскими царями от Ахеменидов до Сасанидов и восславлялся некоторыми авестийскими книгами и среднеперсидскими постсасанидскими комментаторами.
3 – В тестировании программного обеспечения «дымовой тест» означает минимальный набор тестов на явные ошибки.
4 – В оригинале – "soceities".


Будем благодарны, если Вы поделитесь этой публикацией:


Copyright © «Империал». Копирование информации с этой страницы возможно только при указании прямых ссылок на эту страницу.


    Воспользуйтесь одной из соц-сетей для входа на форум:


    Внимание: Реклама отключена для зарегистрированных посетителей

    Стиль
       18 Ноя 2017, 22:35
    © 2017 «Империал». Условия предоставления. Ответственность сторон. Декларация о Сотрудничестве. Лицензия зарегистрирована на: «Империал». Счётчики