Збереження ігрового стану гри?

Я працюю над базовим негідником, використовуючи HTML5 та jQuery, і я зіткнувся з проблемою.

Оскільки в грі зараз стоїть система, система лише зберігає ігровий стан щоразу, коли користувач пересувається між поверхами - щоб мінімізувати накладні витрати. Небезпека цього полягає в тому, що якщо користувач потрапить у біду, він може просто закрити вікно та повернутися до своєї гри на початку поточного поверху. Це різко зменшує складність гри (і майже перемагає мета шахрайства), але зберігати ігровий стан при кожному русі чи атаці гравця нерозумно.

Я досліджував способи збереження стану гри на вікні браузера, але я не задоволений ними. Моє запитання таке: якщо припустити, що "збереження ігрового стану" означає помірно важкий запит на ajax / post, як я можу порушити цю поведінку на обман? Чи існує відома методологія кількісного визначення поступових / процедурних змін 2d-карти на відміну від збереження всього стану карти? Зауважте, я не прошу "найефективнішого способу" - я шукаю існуючі методології, щоб виправити мою недосвідченість.

Очевидним рішенням є відправлення кожної команди гравця на сервер так, як це зроблено, і сервер їх записувати; таким чином, якщо гра перервана з будь-якої причини, записані команди можуть бути відтворені, щоб відновити гру до тієї точки, де вона припинилася.

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

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

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

Дивіться /programming/3888902/javascript-detect-browser-close-tab-close-browser для більш загальної задачі того ж питання.

Також розгляньте можливість збереження повної гри на змінах підлоги та поступових дельтах на кожному кроці. Потім ви можете відтворити гру до моменту останнього руху.

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

Підходи до заощаджень, які не збільшуються, але знаходять час для повного збереження:

• onunload, як було зазначено раніше Я вважав, що це надійно (але використання localStorageмережі, яка не може змінити ситуацію).
• Збережіть, коли ваше вікно втратить фокус.
• Зберігати періодично: коли останнього збереження не було за n хвилин, а користувач не зробив жодного вводу за м секунди.