RPG – сохранение данных игрока для полукомплексной древовидной структуры

Я создаю веб-RPG в js, используя JON дыни и SQL DB с PHP. Этот вопрос касается того, как хранить завершенные и текущие задачи для персонажа, не являющегося игроком (NPC).

Диалоговое окно NPC и данные задачи: все диалоговые окна хранятся в объекте js в следующей структуре:

var dialog = { quests : { quest1 : { NPCName ("Joe"): { TaskName ("1 - Introductions") : { "english" : [ "Hello, here is some dialog", "More dialog..." (stored in array so I can cycle through it) ],//more items per task }, //more tasks per NPC }, //more NPCs per quest }, //more quests options per "quests" }, //more options in dialog besides "quests" if I want }; 

Я не храню все диалоговые окна карт в том же файле, потому что файл будет слишком забитым … так что вместо этого: когда карта изменяется, я использую js_require для загрузки в новый js файл с новым набором диалоговых окон:

введите описание изображения здесь

 loadNpcDialog : function (dialogNumber) { require(["./dialog/npc_dialog_level_" + dialogNumber + ".js"], function(dialog) { }); }, 

номер задачи: когда создается новый NPC (класс game.NPCEntity ), я создаю локальную переменную для этого экземпляра NPC, называемого taskNum , установленным на 0. Когда они завершают задачу, я просто получаю и увеличиваю номер задачи NPC:

  game.player = me.game.getEntityByName(game.data.currNPC)[0]; game.player.taskNum++; 

Для этой RPG я хочу добиться следующего:

  • Свободная очередь квестов в стиле GTA: уровень прогрессии, прогрессия квеста и задание на ход NPC являются линейными (полный уровень 1 для перехода на уровень 2 и т. Д.), Но для каждого квеста генерируется набор NPC … ( вы могут думать о них как о подзапросах ), каждая из которых содержит от 1 до n задач. Я хочу построить гибкость очереди запросов, которая позволяет игроку общаться с любым из сгенерированных NPC в любом порядке … и выполнять задачи в линейном порядке (задача 1 затем 2, затем 3 …). Это похоже на стиль GTA, потому что общая игра следует за линейной прогрессией, но дает вам возможность начать любой желаемый квест, разговаривая с случайными людьми в мире.

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

введите описание изображения здесь

Мой вопрос

  • Когда игра загружается, она должна помнить те вещи, о которых я упоминал в дереве выше. Я настроил БД на уровень загрузки и информацию о квестах (я просто возвращаю текущий уровень и номер квеста из БД, затем currentAndCompleteLevels структуру NPC dialog показанную выше, сохраняя значения в currentAndCompleteLevels и currentAndCompleteQuests до тех пор, пока цикл не достигнет текущий уровень и номер квеста от БД) … а также координаты и опыт игрока …

Однако, поскольку я разрешаю проигрывателю начать, приостановить, а затем возобновить любой список задач NPC в любое время, я не могу добавить в базу данных npc completed num и tasks completed num . Это связано с тем, что я не могу NPC dialog структуру NPC dialog и загружать то же самое, что и для информации level и quest потому что порядок, в котором вы выполняете задания NPC, не является линейным . Каким-то образом я должен отслеживать завершенную задачу на NPC. Как я могу это сделать?

Я подумывал создать новую таблицу NPCData для хранения всех NPC в игре, а затем сохранить current task num для этого NPC … но тогда мне пришлось бы создать новую запись для любого нового игрока, который вошел в мою игру.

Или, может быть, создать два столбца базы данных в таблице userstats , currNPC и currTask , затем currTask ассоциативный массив, сохраняющий все задачи на NPC? Но тогда мне нужно будет иметь столбец для каждого завершенного NPC и завершенных задач для каждого NPC. Ой, голова крутится.

Текущая схема БД:

введите описание изображения здесь

Я полагаю, что это классическая взаимосвязь между многими пользователями и пользователем, и в этом случае я бы предложил создать таблицу связей отношений. Здесь я буду хранить внешние ключи: id_user , questnum , questnum .

Я также добавлю:

  • npcnum который является идентификатором NPC для этого квеста и
  • tasknum – количество заданий.

Таким образом, «подзапрос» будет на самом деле идентифицирован questnum , questnum и npcnum и мы можем связать это с пользователем с id_user .

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

Вот SQL-таблица предлагаемой таблицы отношений.

http://sqlfiddle.com/#!2/edea9/1

Предполагая, что вам нужны только текущие подзапросы в памяти, мы можем сохранить прогресс с помощью массива чисел с предположением, что questnum и questnum всегда будут «текущими».

 var tasks=[]; function progress_task(npcNum){ tasks[npcNum] = tasks[npcNum] ? tasks[npcNum]+1 : 1; } function get_task(npcNum){ return tasks[npcNum] || 0; } var currNPC=1; progress_task(currNpc); 

Предостережения о наличии usertasks в том, что у вас будут записи для более старых квестов и уровней, и вы в конечном итоге NPCData иметь NPCData типов NPCData с подзапросами * количество пользователей в рядах. Если это кажется бесполезным, то другой вариант, возможно, состоит в том, чтобы просто преобразовать tasks javscript-переменных в JSON и сохранить их, загружая их снова, когда вы загружаете userstats который, возможно, является более простым маршрутом.