--------------+------------+---------------------
номер объекта | id локации | описатель объекта
--------------+------------+---------------------
Хранение переменного числа параметров
Код:
Т.е. когда игрок входит в этот режим, то считываются объекты и их описатели в привязке к id локации, в которой игрок и находится.
Дело в том, что объекты могут иметь в принципе разную структуру своего описателя. К примеру, камень нужно добывать опередленное время, на монстра можно только напасть, дерево сломать :). В итоге рабочие данные (данные описателя) для объекта определяются только игровой логикой действий с этим объектом "охоты".
Интересует то, каким образом вообще хранить данные описателей этих объектов, если их структура может быть разной? Сгруппировать описатели по их типам в разные таблицы, а в основную внести их id? Тогда как сделать одновременную выборку описателей объектов, если собственно они лежат в разных таблицах? Может быть, существует иное решение организации подобных структур? Подскажите, пожалуйста. Спасибо.
Цитата: agri
Пытаюсь сделать браузерную игрушку. В игре есть режим "охоты", где возможно собирать ресурсы или нападать на монстров или еще что-нибудь. Есть таблица, где и должны храниться объекты для режима "охоты" текущей локации примерно в таком виде:
Т.е. когда игрок входит в этот режим, то считываются объекты и их описатели в привязке к id локации, в которой игрок и находится.
Дело в том, что объекты могут иметь в принципе разную структуру своего описателя. К примеру, камень нужно добывать опередленное время, на монстра можно только напасть, дерево сломать :). В итоге рабочие данные (данные описателя) для объекта определяются только игровой логикой действий с этим объектом "охоты".
Интересует то, каким образом вообще хранить данные описателей этих объектов, если их структура может быть разной? Сгруппировать описатели по их типам в разные таблицы, а в основную внести их id? Тогда как сделать одновременную выборку описателей объектов, если собственно они лежат в разных таблицах? Может быть, существует иное решение организации подобных структур? Подскажите, пожалуйста. Спасибо.
Код:
--------------+------------+---------------------
номер объекта | id локации | описатель объекта
--------------+------------+---------------------
номер объекта | id локации | описатель объекта
--------------+------------+---------------------
Т.е. когда игрок входит в этот режим, то считываются объекты и их описатели в привязке к id локации, в которой игрок и находится.
Дело в том, что объекты могут иметь в принципе разную структуру своего описателя. К примеру, камень нужно добывать опередленное время, на монстра можно только напасть, дерево сломать :). В итоге рабочие данные (данные описателя) для объекта определяются только игровой логикой действий с этим объектом "охоты".
Интересует то, каким образом вообще хранить данные описателей этих объектов, если их структура может быть разной? Сгруппировать описатели по их типам в разные таблицы, а в основную внести их id? Тогда как сделать одновременную выборку описателей объектов, если собственно они лежат в разных таблицах? Может быть, существует иное решение организации подобных структур? Подскажите, пожалуйста. Спасибо.
Дабы не описывать все досконально - в общем описании это выглядит так:
Код:
1. Таблица локаций (ТЛ)-
ид, ....(нечьто что локацию характеризует),
2. Таблица объектов (ТО)
ид,... нечто общее для всех объектов
3. Таблица параметров (ТП) объектов
ид объекта, итем записи, остальные параметры, тип параметра (например действие, вес и т.п.)
4. Таблица соотношентий (ТС) локаций и объектов
ид итема, ид объекта, ид локации
ид, ....(нечьто что локацию характеризует),
2. Таблица объектов (ТО)
ид,... нечто общее для всех объектов
3. Таблица параметров (ТП) объектов
ид объекта, итем записи, остальные параметры, тип параметра (например действие, вес и т.п.)
4. Таблица соотношентий (ТС) локаций и объектов
ид итема, ид объекта, ид локации
примерно так. В конкретной реализации естественно допустима денормализация либо вариации, но общая схема такова.
В некоторых случаях в ТП можно хранить либо массив параметров в одной записи (как реализовано например в SMC), либо одна запись - один параметр. Может присутсвовать так же таблица типов объектов (не путать со справочником типов объектов). Опять же все зависит от проектирования.