Цитата:
Сообщение от Appleman
что кстати поднимает отдельный вопрос трудозатрат на перенос схемы под новые проекты, но сейчас не об этом.
|
Переносится механика: предметы дамажут, надеваются, используются. Если требуется
новое поведение, то тогда да, добавляются таблицы, описывающие его, а код игры/движка обновляется.
Цитата:
Сообщение от Appleman
Значит, в рамках программы должна быть какая-то СУБД
|
Да, субд есть, очень простая: получение записи по id, кеширование данных при загрузке игры, этого хватает. Что и откуда тянуть - знает обрабатывающий код/функция, выполняющая какое-то действие. Если это надевание предмета, она запросит данные этого предмета по его id, запросит данные экипируемого слота. Проверит что-то и либо выполнит действие, либо отвалится с сообщением об ошибке. (Такого предмета не существует, был передан не экипируемый предмет, слот уже экипирован, или такого слота не существует) То-есть, в саму субд я не закладываю такого функционала, что-бы она сама подтягивала дополнительные данные из других таблиц. У меня таблица - это просто список записей, которые можно запросить по id или пройтись по всему списку целиком.
Цитата:
Сообщение от Appleman
Каким образом ты "говоришь", что эффект - это не просто запись, а именно ссылка на другую таблицу данных?
|
Мы изначально так проектируем нашу бд. У нас есть Item, у него есть поле effect. Это поле содержит id записи из таблицы Effects. На какую-то другую таблицу оно ссылаться не может. Вообще это вопрос о том, как проектировать базу данных, как выделять сущности. Можно почитать что-то на эту тему.