[Tails]

Сообщение от Appleman

1. Я правильно понимаю, что если предмет должен "жить своей жизнью" внутри программы, то "чистый" реляционный подход уже не сработает? Например, если каждое использование аптечки снижает её ресурс на 20%, то остаток по-любому придётся хранить в самом экземпляре. В таком раскладе использовать внутри программы одни только ID точно не выйдет. Верно? Как такие вопросы ты решаешь?

У меня есть таблица, которая описывает текущие предметы: (Инвентарь)
id,player,item,quantity
id - ID Записи.
player - ID Игрока.
item - ID Предмета.
quantity - Количество предмета у игрока.

Есть таблица, которая содержит текущие кулдавны предметов у игроков:
id,player,item,cooldown
id - ID Записи.
player - ID Игрока.
item - ID Предмета.
cooldown - Оставшееся время перезарядки предмета.

И т.д. для всех игровых аспектов. Всё что есть в игре, всё разложено по таблицам, "сам по себе" никто не живёт.

Сообщение от Appleman

2. Рассматриваю вариант, как мне скрестить ежа и ужа (реляционную модель хранения статических данных с наследуемой ООП-архитектурой внутри программы). Что если указывать прямо в таблице имя присваиваемого предмету класса, чтобы в момент создания вытягивать его по ID и присваивать через getDefinitionByName? А дальше при заполнении свойств проверять на наличие такого свойства у данного класса. Если есть - заполняем, если нет - не заполняем (и выдаём предупреждение).

На твой страх и риск Лучше делай как уже начал, как тебе самому понятнее. Просто будешь знать, что есть и альтернативный способ.

Сообщение от Appleman

3. В качестве альтернативы вижу ещё один подход. ВСЕ свойства прописать в классе Item, тем самым решив раз и навсегда проблему наличия/отсутствия свойств, а наследников оставить как маркеры.

Тут только надо понимать, где заканчивается одна сущность и начинается другая. Например, может показаться, что использование предмета - относится к самому предмету. Но, использование, как таковое, может быть и самостоятельной, отдельной сущностью, на которую предмет будет ссылаться. Вообщем, это уже зависит от самого проекта. Или вот ещё пример: приложение по знакомству. Парень и девушка познакомились. Знакомство может быть выделено как отдельная сущность, которая будет включать в себя свойства:
id, id парня, id девушки, дата знакомства, уровень взаимной симпатий.
То есть, связь между парнем и девушкой - это тоже отдельная сущность, отдельная таблица.

Сообщение от Appleman

4. Скажи, пожалуйста, я правильно понимаю, что если нет комплексной СУБД, "знающей", что откуда нужно подтягивать, то получается, что для каждой таблицы нам придётся делать свой персональный класс-парсер, который как раз и будет "знать", что и как мы из неё вытаскиваем?

Вытаскиваем куда? Вообще, да, есть отдельный парсер, который читает JSON и заполняет все таблицы. Может быть, он ещё будет уметь записывать таблицы обратно в JSON. (Например, для сохранения игры) Но это ввод/вывод данных из игры. Если ты имеешь ввиду работу логики самой игры, то, функция выполняющая конкретное действие сама получает нужные ей данные из таблиц. Я это организовываю в виде апи игровой модели, где у главной модели есть все необходимые методы для работы с данными:

playerItemEquip(playerID, itemID):Void;
playerItemUnequip(playerID, itemID):Void;
playerItemUse(playerID, itemID):Void;
playerItemBuy(playerID, itemID):Void;
playerItemSell(playerID, itemID):Void;
...

Сами игроки и предметы - это просто записи в таблицах, у них нет функционала. (Почти, кроме там диспетчеризации событий и может ещё за редким исключением)