MAGICON.FB
Правильный способ хранения данных
С самого начала разработки движка, ещё в 2008 году, я столкнулся с необходимостью выбора наиболее удобного способа хранения данных. Этот способ должен был давать большую гибкость, быть достаточно простым, а также обеспечивать лёгкость передачи данных между локациями. Однако, прийти к способу, который соответствовал всем этим условиям, сразу не получилось. Сбивала с толку возможность создавать сколь угодно большое количество переменных с разными именами. Поэтому первая таблица данных была построена на переменных. И хотя для меня она не выглядела, как таблица, всё же она таковой являлась. Для примера возьмём предмет старый нож со следующими свойствами:
вид: старый_нож
название: Старый Нож
класс: штучный
тип: оружие
подтип: одноручное
стоимость: 366
вес: 100
режущий урон: 500
дробящий урон: 100
Как выглядела запись этого предмета в таблице данных, состоящей из переменных:
$vid[0]='старый_нож'
$name[0]='Старый Нож'
$class[0]='штучный'
$type[0]='оружие'
$subtype[0]='одноручное'
costa[0]=366
weight[0]=100
rez_blow[0]=500
drb_blow[0]=100
-приблизительно так. Не берём пока во внимание местоположение предмета, будем считать, что такая запись присуща всем предметам, помещённым в рюкзак героя. Индекс массива (номер элемента массива) соответствует позиции предмета в рюкзаке.
Такая запись хороша тем, что у нас есть наиболее быстрый способ получения данных. Чтобы получить, например, название предмета достаточно вернуть значение переменной $name[#]. Подобная таблица кажется очень удобной и простой. Любое свойство объекта можно описать новой переменной, однако чем больше разнотипных предметов, тем больше переменных нам приходится вводить для описания их свойств. Действительно, если в нашей игре появляется объект нового типа, появляются и новые переменные:
вид: старый_шлем
название: Старый Шлем
класс: штучный
тип: доспех
подтип: шлем
стоимость: 300
вес: 500
защита от режущего урона: 500
защита от дробящего урона: 100
$vid[1]='старый_шлем'
$name[1]='Старый Шлем'
$class[1]='штучный'
$type[1]='доспех'
$subtype[1]='шлем'
costa[1]=300
weight[1]=500
rez_shield[1]=500
drb_shield[1]=100
Чем это чревато. Для каждого типа объектов приходится создавать свой механизм обработки, либо учитывать в одном механизме обработки все создаваемые переменные. Что не совсем удобно, поскольку каждый раз создавая новый тип объекта, приходится переделывать механизм обработки. К тому же накопив пятнадцать типов объектов, окажется очень сложно следить за всеми созданными переменными. Ко всему, такое хранение данных всё-таки является табличным, что означает, что у нас всегда существуют переменные, которые заполнены нулевыми или пустыми значениями. А так как эти значения не используются текущим типом объектов, значит они только зря загромождают память.
| №№ | $vid | $name | $class | $type | $subtype | costa | weight | rez_shield | drb_shield | rez_blow | drb_blow |
| 0 | старый_нож | Старый Нож | штучный | оружие | одноручное | 366 | 100 | не используется | не используется | 500 | 100 |
| 1 | старый_шлем | Старый Шлем | штучный | доспех | шлем | 300 | 500 | 500 | 100 | не используется | не используется |
К идее хранить данные несколько иным способом меня привела необходимость. Если Вы давно используете QSP, Вы знаете, что на локации, работающие, как подпрограммы, можно передавать всего девять аргументов. Согласитесь этого бывает мало. Иногда подпрограмме нужно передать больше девяти аргументов. Даже два разнотипных объекта, которые мы взяли для примера, требуют для передачи всех данных механизму (при условии, что он один для обоих предметов) аж одиннадцать аргументов. Выход из этого положения подсказала структура html-документов. Как Вы, возможно, знаете html-документы размечаются специальными метками - тегами.
<h1>Открывающий и закрывающий теги заголовка</h1>
Используя html-теги для передачи данных мы можем передавать любую информацию. Однако, это не совсем удобно, поскольку плеер уже использует html-теги для чтения разметки в текстах ваших игр. Необходимо предвидеть возможность того, что Вам придётся передавать данные прямо в тексте, выводимом для игрока. А содержимое между тегами не должно быть видимым. Поэтому я придумал собственные теги: набор символов, который реже всего встречается в тексте. В последствии пришлось сделать несколько наборов, чтобы вставлять данные в разные места в игре. Тем не менее основные теги приняли вид:
[tag: :tag]
Записывая данные внутри подобных тегов, мы можем передавать всю информацию об объекте одним аргументом в виде текстового значения:
[:старый_нож:] [name:Старый Нож:name] [number] [np:[оружие] [одноручное] [нож]:np] [stoim:366] [weight:100] [color:006666] [uron: u1:режущий:u1 u2:стрелковый:u2 p1:500 p2:100 :uron]
Приведён пример реального предмета, создаваемого в игре.
Этот способ передачи данных оправдал себя. Подошёл он и для хранения. Теперь все данные стало можно помещать в одну переменную. Так изменилась таблица хранения данных.
