id integereger not null autonumber, /* идентификатор на героя */
user_id integereger not null, /* идентификатор на потребителя, на който принадлеи героя */
name varchar(50) not null, /* име на героя, макс 50 символа */
level integereger default 0, /* ниво на героя */
exp integereger default 0, /* опит */
created timestamp DEFAULT CURRENT_TIMESTAMP, /* дата-час когато е създаден героя */
last_online timestamp DEFAULT null, /* дата-час когато е последно е използван героя */
status varchar(30) not null, /* последен статус */
status_ref_id integereger not null DEFAULT 0, /* указател на последен статус */
map_id integereger default 1 /* карта, на която се намира героят */
map_x integereger not null default 0,
map_y integereger not null default 0,
_data text default '{}' /* Всичко друго в JSON стуктура */
Малко разяснения по (псевдо) схемата. Използваме отделна таблица за потребителите и героите поради няколко причини:
по-чисто е така данните за пароли и e-mail нямат работа при информацията за героя;
по-"сигурно" поради горната причина;
един играч може да има повече от един герой. Неизменно ще се стигне до този момент, в който някой от играчите ще иска да смени героят си. Затова ще го изпреварим и ще му дадем възможност да си прави колкото желае герои. Това ни позволява да организираме и споделяне на ресурси между героите на един играч.
името на героя мисля че не се нуждае от разяснения. Ограничаваме го до 50 символа, което би трябвало да е достатъчно.
ИДЕЯ - играчът може да укаже обща фамилия за всичките си герои. Примерно "Пачикраков" и няколко героя: Мунчо Пачикраков, Пунчо Пачикраков. Така неговата орда ще бъде по-познаваема.
Ниво и опит са си характеристики на героя но са изнесени в таблицата, защото може да се наложи да сортираме героите по тях.
created запазва момента на раждането на героя (винаги е добре да се знае за да почерпи на рожденния си ден:)
last_online ще се обновява при всяка промяна в таблицата с текущите дата-час; Така ще знаем кога последно е използван героят;
status тук нещата стават малко мъгливи. Специфичното при нашата браузърна игра е че на всеки ход от страна на играча трябва да съхраняваме цялото състояние на играта, като не можем да рачитаме на клиента да пази нищо. Реален пример: играчът влиза в битка и в този момент влиза майка му да му се кара защо не си е написал домашните, при което той затваря браузъра. Когато си напише домашните (или майа му затвори вратата) ние трябва да можем да прдължим играта от момента, до който е стигнал (или до последен checkpointeger. Затова ще използваме двете полета status (контролера/метода които ще използваме) и status_ref_id (указател към конкретен елемент ако е нужно)
map_id, map_x, map_y са съответно карта, и координати на които се намира героя. Ще са ни необходими за движението му и при определяне на "съседни" герои.
_data: сигурно сте забелязали че изпускаме сума ти характеристики като HP, MP, TP, атака, блок и.т.н. тъй като промяната на структурата на базата е особено досадно а и някой полета са ни нужни само в контекста на определен герой (т.е. не ги използваме за група или всички герои), всички допълнителни полета ще записваме като JSON сериализиран хеш масив в полето data.
Малко пояснения върху "JSON сериализиран хеш масив";
хеш масив е списък с наредени име => стойност; сериализиран означава че е структурата е превърната в текст, който след това отново може да бъде превърнат в структура на езика (десереализация); JSON принципно е JS стандарт за сериализация на обекти. Имаме и други варианти тук: xml, serialize фунцкията на PHP, собствен формат .. но последният път като проверявах JSON функциите работиха най-бързо а и ще ползваме JSON на доста места в играта, така че той остава най-разумният избор;