Какое преимущество для производительности заключается в сохранении всех зарегистрированных символов в MMO через равные промежутки времени?

Большинство MMORPGS имеют систему Worldsave, которая будет сохранять всех персонажей один раз каждые X часов. Я думаю, причина в производительности. Так почему же это лучше с точки зрения производительности, чем сохранение персонажа при отключении?

networking mmo databases

— bunden
источник

Это не для производительности; это приносит в жертву немного производительности ради правильности , что более важно.

— Мейсон Уилер

Время действительно играет какую-то роль здесь? AFAIK, каждое действие в мммо сохраняется сразу. Вы получаете элемент, и этот элемент незамедлительно добавляется на сервер в вашу учетную запись, в противном случае сервер должен был бы запомнить, что вы это сделали, а затем сделать это через 5 минут, что не имеет смысла. Или клиент должен был бы запомнить и отправить его через 5 минут, что теперь открывает вам возможность взлома, потому что за эти 5 минут любой может изменить / добавить данные для отправки.

— Надеюсь, что вы

@ Надеюсь, это не правда. Каждое действие в MMO немедленно запоминается , но это временно. Сохранять все напрямую в постоянное хранилище все еще слишком дорого, даже с твердотельными накопителями. Даже с играми, которые сохраняются непосредственно в базе данных, сама база данных не сохраняет эти данные на диск немедленно (или, по крайней мере, сохраняет только журнал транзакций, а не непротиворечивые данные - это необходимо восстановить в случае сбоя, и для этого требуется довольно много времени). немного времени). Но экономия на отключении - плохая идея по другой причине - последовательность.

— Луаан

Я подумал, что этот вопрос будет скорее соответствовать тому, каково преимущество производительности при сохранении символов в промежутках по сравнению с реальным временем.

— Энтони

@Luaan: вполне возможно сохранить каждое изменение состояния в постоянном хранилище, даже на механических жестких дисках. (Вам может понадобиться несколько на занятых серверах). Хитрость заключается в том, чтобы не обновлять отдельные объекты. Вместо этого вы сохраняете журнал транзакций «Player (A). Inventory + = Object (B)». Периодически вы сбрасываете полное состояние. Для восстановления вы загружаете последнее полное сохранение и применяете новейшие транзакции из журнала транзакций. Если вы пишете один файл последовательно, вы достигаете пиковой производительности для механических жестких дисков, но для поддержания разумного размера журнала транзакций требуется периодическое полное сохранение.

— MSalters

Ответы:

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

Сохраняя при отключении, если на сервере возникла проблема, все потеряют все, что они сделали, так как они вошли в систему. Для тех, кто играет особенно долго (как это часто бывает в MMO), они потеряют значительный объем данных.

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

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

РЕДАКТИРОВАТЬ: Как отметил @Philipp , это также устраняет возможность дублирования элементов. В системе с сохранением при отключении, если транзакция выполняется до сбоя сервера, и один человек выходит из системы до сбоя, оба игрока откатываются до последнего выхода из системы, либо удаляя элементы, либо дублируя их.

— Арик
источник

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .

— Джош

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

Это означало, что если пользователь отключался без «кемпинга», он обычно оказывался в нескольких комнатах и пропускал кучу добычи, XP и т. Д. С момента последнего сохранения. В этом отношении он во многом напоминал то, как сегодня играют консольные РПГ (вы должны сохранить свою игру, не выключая консоль, или вы потеряете все с момента последнего сохранения).

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

Функция сохранения мира появилась благодаря тому, что персонажи в конечном итоге могли напрямую взаимодействовать друг с другом, поэтому все играющие персонажи должны были находиться в согласованном состоянии, иначе может произойти дублирование и удаление предметов. Это не было проблемой в сценарии MUD, потому что было трудно злоупотреблять системой таким образом, что это приводило к дублированию предметов или валюты, но это было невероятно легко сделать в ранних MMO MUD. Игрок A дает игроку B предмет, игрок B спасает, а игрок A отключается без сохранения. Мгновенное дублирование.

Worldsave не является преимуществом для производительности, но предназначен для предотвращения мошенничества. Я помню, как играл в системах, где событие worldsave было объявлено буквально заранее, и часто зависало всю систему на минуту, пока сервер обновлял все свои файлы. Хотя это предотвращало мошенничество, это было не очень удобно для пользователей этих систем.

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

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

При разработке современной MMO вы хотели бы создать хранимые процедуры в базе данных и использовать эти процедуры для выполнения транзакций. Например, при торговле между двумя игроками это может выглядеть так:

start transaction;
insert into inventory (playerid, itemid) values (111, 222);
delete from inventory where playerid=111 and itemid=444;
insert into inventory (playerid, itemid) values (333, 444);
delete from inventory where playerid=333 and itemid=222;
commit;

(Примечание: этот SQL не написан на практике и предназначен только для примера).

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

— phyrfox
источник