Яка користь від продуктивності збереження всіх зареєстрованих символів у MMO через регулярні інтервали?


26

Більшість MMORPGS мають систему Worldsave, яка зберігатиме всіх персонажів кожні X години. Я гадаю, що причина - продуктивність. Так чому це краще, ефективніше, ніж збереження персонажа при відключенні?


34
Це не для продуктивності; це жертвувати трохи продуктивності для правильності , що важливіше.
Мейсон Уілер

Чи справді час тут відіграє якусь роль? AFAIK, кожна дія в mmo врятована негайно. Ви отримуєте товар, і цей елемент додається на сервер без затримки до вашого акаунта, інакше сервер повинен пам’ятати, що ви це зробили, а потім зробити це через 5 хвилин, що не має ніякої користі. Або клієнту доведеться запам'ятати і надіслати його через 5 хвилин, що тепер відкриває вас для злому, тому що за ці 5 хвилин кожен може змінити / додати дані для надсилання.
СподіваюсьДопомога

4
@HopefullyHelpful Ні, це неправда. Кожна дія в MMO негайно запам'ятовується , але це тимчасово. Збереження всього безпосередньо на постійному сховищі все ще занадто дороге, навіть із SSD. Навіть в іграх, які зберігають безпосередньо в базі даних, сама база даних не зберігає ці дані на диску відразу (або принаймні зберігає лише журнал транзакцій, а не послідовні дані - це потрібно відновити при збої, і це займе досить трохи часу). Але заощадження на відключенні є поганою ідеєю з іншої причини - послідовності.
Луань

1
Я подумав, що це питання буде більше узгоджуватись із перевагою продуктивності в збереженні символів в інтервалах і в режимі реального часу.
Ентоні

2
@Luaan: Цілком можливо зберегти всі зміни стану на постійному сховищі, навіть на механічних жорстких дисках. (Можливо, вам знадобиться кілька на зайнятих серверах). Хитрість полягає в тому, щоб не оновлювати окремі об’єкти. Натомість ви зберігаєте журнал транзакцій "Player (A). Inventory + = Object (B)". Періодично ви стираєте повний стан. Щоб відновитись, ви перезавантажуєте останнє повне збереження та застосовуєте найновіші транзакції з журналу транзакцій. 'Виписуєте один файл послідовно, ви досягаєте пікової продуктивності механічного жорсткого диска. Але, щоб журнал транзакцій був розміром розумним, вам потрібно періодичне повне збереження.
MSalters

Відповіді:


66

Це не для продуктивності. Це невдача. Якщо світ економить кожні кілька хвилин, то, якщо щось трапиться із сервером, і він вимикається, всі втратять лише кілька хвилин прогресу.

Заощаджуючи при відключенні, якщо сервер має проблему, всі втратять усе, що вони зробили з моменту входу. Для тих, хто на особливо тривалих ігрових сесіях (як це прийнято в MMO), вони втратять значну кількість даних.

Вони жертвують невеликою продуктивністю, щоб зняти ризик масових втрат даних.

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


EDIT: Як зазначав @Philipp , це також знімає можливість копіювання елементів. Якщо система збереження-відключення працює, якщо трансакція проводиться перед збоєм на сервері, а одна людина виходить із системи перед збоєм, обидва гравці відкочуються в останній раз, коли вийшли з системи, або видаляючи елементи, або дублюючи їх.


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

5

Ранні системи, які зберігалися лише при відключенні, мали тенденцію також періодично економити під час програвання. У цих системах, як правило, MUD (Multi-User Dungeons), символ зберігався в пам'яті до періодичного скидання у файл.

Це означало, що якщо користувач відключився без «кемпінгу», вони зазвичай опинялися в декількох кімнатах і пропускали купу бабло, XP тощо. У цьому відношенні він поводився дуже схоже на те, як сьогодні грають консольні RPG (вам потрібно зберегти гру, не вимикаючи консоль, або ви втрачаєте все з останнього разу, коли ви зберегли).

Система працювала за призначенням, оскільки персонажі не могли взаємодіяти один з одним, за винятком, можливо, через систему "пошти", де вони могли надсилати повідомлення та предмети один одному. Шанс втратити предмети та прогресувати, як правило, був досить значним, але в більшості випадків впливав лише на одного персонажа.

Функція worldsave з'явилася через те, що герої зрештою змогли безпосередньо взаємодіяти один з одним, тому всі персонажі, що грають, повинні були знаходитись у послідовному стані, або можливе дублювання та видалення елементів. Це не було проблемою в сценарії MUD, оскільки важко було зловживати системою таким чином, що призвело до дублювання предметів або валюти, але це було надзвичайно просто зробити на ранніх MUD MUD. Гравець A дає гравцеві B предмет, гравець B зберігає, а гравець A відключається без збереження. Миттєве дублювання.

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 все ще є оригінальні предмети, тоді як після фіксації торг завершується. Немає можливості для дублювання, оскільки символи зберігаються одночасно, як це гарантує база даних.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.