Спектр Доверия: Сравнительное Тестирование

Это последняя часть текста, который я неспешно перевожу по частям больше года. Я знаю, что есть люди, которым далеко не всё из рассуждений Рафа Костера казалось понятным и подходящим к MMO. Мне же кажется, что в предыдущих частях были даны настолько чёткие рецепты работы с доверием между игроками, насколько это вообще возможно при рассмотрении широкого спектра игр. В последней части Раф демонстрирует, скорее, прикладную задачу — тестирование готовых моделей.

В наши дни мы привыкли использовать живые данные. Все то, что вы читали выше, выглядит очень… теоретическим. Поэтому возникает естественный вопрос: есть ли возможность измерить все эти поведенческие модели в играх? Мы легко научились фиксировать такие показатели, как конверсия, удержание, количество внутриигровых связей или даже проведённое вместе время для конкретной пары игроков. Но эту информацию сложно превратить в новые методы, которые можно было бы использовать в геймдизайне. Как видно из предыдущих выкладок, существует масса факторов, которые могут повлиять на то, какое место в Спектре Доверия будет занимать конкретная игра. Что для нас по-настоящему важно — найти объективные показатели, которые смогут нам подсказать не только причины происходящего, но и способы того, как нам достичь желаемого.

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

Вот пример того, как можно механистически замерять какие-то показатели, связанные с доверием, в уже работающей игре. Сначала приведу список, а затем объясню каждый пункт.

• Помощь: когда один игрок помогает другому (фиксируются индентификаторы обоих игроков, тип помощи — лечение, подарок и так далее — а также время события).


• Обмен: когда один игрок предлагает другому нечто за вознаграждение (фиксируются идентификаторы игроков, предмет сделки, время события).


• Попытка координации действий: когда игроки пытаются синхронизировать свои действия друг с другом (фиксируются идентификаторы игроков, тип координации — пас, название комбо и так далее, время события, а также идентификатор события, для возникновения которого предпринималась попытка).


• Успешная координация действий: когда попытка координации действий между игроками оказалась успешной (фиксируется идентификатор события, для возникновения которого предпринимались действия, а также время, понадобившееся для вызова этого события).


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


• Избыточное действие: когда член команды выполняет действие, которое могли бы выполнить и некоторые другие игроки (фиксируется идентификатор игрока и тэг действия).


• Эксклюзивное действие: когда член команды выполняет действие, доступное только ему (фиксируется идентификатор игрока и тэг действия).


• Предательство: когда игрок делает что-то против своей команды (фиксируется идентификатор «предателя», идентификаторы жертв «предательства» (например, жертвы дружественного огня), идентификаторы всех членов «преданной» команды, тэг действия).


• Совместная игра: фиксируется ситуация, когда один игрок в многопользовательской игре действует совместно с другим (фиксируется идентификаторы партнёров и длительность совместной игры).


• Командная неудача: фиксируются события, такие как подсчёт очков, которые воспринимаются, как общий проигрыш для команды (фиксируются идентификаторы всех членов команды и тэг события).

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

Как только вы получите эти простые данные, вы сможете начать собирать более сложный пласт информации, основываясь на массиве простой. К примеру:

• Если Баффи предала Билли, а затем Билли предал Баффи, вы можете зафиксировать эту последовательность как метрику «месть».


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


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


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


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

Здесь важно остановиться на ключевых терминах.

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

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

Другие действия легко идентифицировать в любой игровой модели. Тот же «удар по мячу».

Роль можно определить, как набор действий, доступных игроку. Здесь есть два принципиальных подхода. Первый — игроки наделяются определённым одинаковым набором конкретных команд, которые могут использовать в зависимости от ситуации. Вторая: у каждого игрока свой набор команд.

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

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

И противоположный пример. Только голкипер может при этом перехватить мяч руками. Это эксклюзивное действие. Больше никто в команде не может коснуться мяча руками во время игры.

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

Есть ещё один тип действий — это действия, которые игрок может предпринять, независимо от ситуации и своего положения. Эти действия не имеет смысла отслеживать для работы со Спектром Доверия, но вы можете захотеть собирать их хотя бы для того, чтобы сравнить такие действия с важными для доверия.

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

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


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


• Попытка координации действий, в отличие от предыдущих двух пунктов, не основывается на обмене статистикой. Это именно попытка произвести скоординированные действия. Если один игрок выполняет действие, успех которого зависит от действий другого игрока, как передача паса, мы фиксируем попытку координации действий.


• Успешная координация действий — простой замер того, был ли тот же пас действительно принят. Во многих играх система отслеживает связь между, казалось бы, автономными действиями игроков. Самый простой пример — «комбо» для двух и более игроков, которые выстраиваются из определённой последовательности действий и определённым временем между ними. Явные последовательности действий достаточно легко предсказывать и отслеживать.


• Неэксклюзивное действие — любое действие члена команды, которое может быть выполнено любым другим членом этой команды в определённых обстоятельствах.


• Избыточное действие доступно только конкретной категории игроков, но в команде несколько представителей этой категории. В RPG-группе, где есть клерик и паладин, оба они могут лечить сопартийцев, но лечение — действие, которое доступно далеко не всем игрокам. Поэтому если в группе два лекаря, стоит эти действия идентифицировать как избыточные.


• Эксклюзивное действие может быть выполнено только конкретным игроком, потому что так диктует механика игры, запрещая кому-то ещё из команды делать это. Если в другой RPG-группе есть только один персонаж, способный лечить, или, скажем, некромант, как единственный, кто способен вернуть напарника к жизни, мы фиксируем эти действия как эксклюзивные.


• Предательство — действие, которое играет на руку команде противника. Оно может быть сделано нечаянно. К примеру, гол в свои ворота, пас не тому игроку, дружественный огонь в командном шутере и тому подобное.


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


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

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

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

Заключение

Разрабатывая игры, основанные на доверии, мы одновременно создаём пространство, в котором люди стремятся к самореализации. Эти игры разрабатываются для того, чтобы люди ощутили себя счастливыми. Такие игры создаются для того, чтобы люди получали удовольствие от человеческих связей. Игра — это проявление любви. Мы надеемся, что наши исследования помогут привнести больше всего этого в наш мир.