Реализация систем успеха в современных, сложных играх
Много игр, которые создаются в эти дни, идут со своей собственной системой успеха, которая вознаграждает плееры/пользователей за выполнение определенных задач. Система значков здесь на stackoverflow является точно тем же.
Существуют некоторые проблемы хотя, для которого я не мог выяснить хорошие решения.
Системы успеха должны не упустить определенные события все время, думать об игре, которая предлагает 20 - 30 успехов для, например: бой. Сервер должен был бы проверить на эти события (например: плеер избежал x нападений противника в этом сражении или игрока обойденные x мили), все время.
- Как сервер может обработать этот большой объем операций, не замедляясь и возможно даже отказывая?
Системам успеха обычно нужны данные, которые только используются в базовом механизме игры и не были бы необходимы из там так или иначе, если не было тех противных успехов (думайте, например: как часто плеер перешел во время каждой борьбы, Вы не хотите хранить всю эту информацию в базе данных.). То, что я имею в виду, - то, что в некоторых случаях единственный способ добавить успех добавил бы код, который проверяет на его текущее состояние к игровому ядру, и это обычно - очень плохая идея.
Как системы успеха взаимодействуют с ядром игры, которая содержит более позднюю ненужную информацию? (см. примеры выше),
Как они разделяются от ядра игры?
Мои примеры могут казаться "безопасными", но думать о 1000 + успехи, в настоящее время доступные в World of Warcraft и многих, многие плееры онлайн одновременно, например.
2 ответа
Системы достижений - это просто форма регистрации. Для такой системы хорошим подходом является публикация / подписка . В этом случае игроки публикуют информацию о себе, а заинтересованные программные компоненты (обрабатывающие индивидуальные достижения) могут подписаться. Это позволяет вам просматривать общедоступные значения с помощью специального кода ведения журнала, не влияя на основную игровую логику.
Возьмем ваш пример «Игрок прошел x миль». Я бы реализовал пройденное расстояние как поле в объекте игрока, поскольку это простое значение для увеличения и не требует увеличения пространства с течением времени. Достижение, которым награждаются игроки, которые прошли 10 миль, становится подписчиком этого поля. Если бы игроков было много, было бы целесообразно агрегировать это значение с одним или несколькими промежуточными уровнями брокера. Например, если в игре присутствует 1 миллион игроков, вы можете агрегировать значения с 1000 брокерами, каждый из которых отвечает за отслеживание 1000 отдельных игроков. Затем достижение подписывается на этих брокеров, а не на всех игроков напрямую. Конечно, оптимальная иерархия и количество подписчиков зависят от конкретной реализации.
В случае вашего примера боя, игроки могут публиковать детали своего последнего боя точно так же. Достижение, отслеживающее прыжки в боях, подписывается на эту информацию и проверяет количество прыжков. Поскольку никакого исторического состояния не требуется, оно тоже не растет со временем. Опять же, не нужно изменять основной код; вам нужно только иметь доступ к некоторым значениям.
Обратите внимание, что большинство наград не обязательно должно быть мгновенным.Это дает вам некоторую свободу действий в управлении вашим трафиком. В предыдущем примере вы могли не обновлять опубликованное брокером пройденное расстояние, пока игрок не прошел в общей сложности еще одну милю или не прошел день с момента последнего обновления (до тех пор увеличивается внутренне). На самом деле это просто форма кеширования; точные параметры будут зависеть от вашей проблемы.
Если архитектура вашей игры событийно-управляемая, то вы можете реализовать систему достижений с помощью конечных автоматов.