|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
__________________
Не сломано - не чини! |
|
|||||
Цитата:
Да, субд есть, очень простая: получение записи по id, кеширование данных при загрузке игры, этого хватает. Что и откуда тянуть - знает обрабатывающий код/функция, выполняющая какое-то действие. Если это надевание предмета, она запросит данные этого предмета по его id, запросит данные экипируемого слота. Проверит что-то и либо выполнит действие, либо отвалится с сообщением об ошибке. (Такого предмета не существует, был передан не экипируемый предмет, слот уже экипирован, или такого слота не существует) То-есть, в саму субд я не закладываю такого функционала, что-бы она сама подтягивала дополнительные данные из других таблиц. У меня таблица - это просто список записей, которые можно запросить по id или пройтись по всему списку целиком. Мы изначально так проектируем нашу бд. У нас есть Item, у него есть поле effect. Это поле содержит id записи из таблицы Effects. На какую-то другую таблицу оно ссылаться не может. Вообще это вопрос о том, как проектировать базу данных, как выделять сущности. Можно почитать что-то на эту тему.
__________________
Дети не должны знать о своих родителях |
|
|||||
крутяк
__________________
while(live()) { hope(); } |
|
|||||
Может, напишу как нибудь статейку. Я уже не в первый раз вижу этот вопрос, на этом, на других форумах и всегда у людей одна и та-же проблема: (Как всё увязать вместе и не свихнуться при этом)
Цитата:
На начальных этапах, пока делаешь/тестируешь механику у тебя будет всего по несколько записей в таблицах, можно и в нотпаде редактировать. Вот когда всё будет готово и понадобится наполнять игру контентом, тогда можно будет озаботиться более удобной админкой. Какого-то универсального редактора я не знаю, сам недавно интересовался этим вопросом.
__________________
Дети не должны знать о своих родителях Последний раз редактировалось Tails; 08.06.2018 в 14:14. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
1. Я правильно понимаю, что если предмет должен "жить своей жизнью" внутри программы, то "чистый" реляционный подход уже не сработает? Например, если каждое использование аптечки снижает её ресурс на 20%, то остаток по-любому придётся хранить в самом экземпляре. В таком раскладе использовать внутри программы одни только ID точно не выйдет. Верно? Как такие вопросы ты решаешь? 2. Рассматриваю вариант, как мне скрестить ежа и ужа (реляционную модель хранения статических данных с наследуемой ООП-архитектурой внутри программы). Что если указывать прямо в таблице имя присваиваемого предмету класса, чтобы в момент создания вытягивать его по ID и присваивать через getDefinitionByName? А дальше при заполнении свойств проверять на наличие такого свойства у данного класса. Если есть - заполняем, если нет - не заполняем (и выдаём предупреждение). 3. В качестве альтернативы вижу ещё один подход. ВСЕ свойства прописать в классе Item, тем самым решив раз и навсегда проблему наличия/отсутствия свойств, а наследников оставить как маркеры. Насколько такие "гибридные" подходы применимы и в чём, по твоему мнению, их главные минусы? Плюсы и так понятны. Спасибо. Добавлено через 27 минут ...ещё забыл, хотел уточнить.\ 4. Скажи, пожалуйста, я правильно понимаю, что если нет комплексной СУБД, "знающей", что откуда нужно подтягивать, то получается, что для каждой таблицы нам придётся делать свой персональный класс-парсер, который как раз и будет "знать", что и как мы из неё вытаскиваем?
__________________
Не сломано - не чини! |
|
|||||
Цитата:
id,player,item,quantity id - ID Записи. player - ID Игрока. item - ID Предмета. quantity - Количество предмета у игрока. Есть таблица, которая содержит текущие кулдавны предметов у игроков: id,player,item,cooldown id - ID Записи. player - ID Игрока. item - ID Предмета. cooldown - Оставшееся время перезарядки предмета. И т.д. для всех игровых аспектов. Всё что есть в игре, всё разложено по таблицам, "сам по себе" никто не живёт. Цитата:
Цитата:
id, id парня, id девушки, дата знакомства, уровень взаимной симпатий. То есть, связь между парнем и девушкой - это тоже отдельная сущность, отдельная таблица. Цитата:
Сами игроки и предметы - это просто записи в таблицах, у них нет функционала. (Почти, кроме там диспетчеризации событий и может ещё за редким исключением)
__________________
Дети не должны знать о своих родителях Последний раз редактировалось Tails; 08.06.2018 в 17:19. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
Цитата:
__________________
Не сломано - не чини! |
|
|||||
Цитата:
Цитата:
Но, конечно, мы создаём свой класс обёртку, куда добавляем типизацию, более удобное апи и некоторый функционал, диспатчинг событий, например.
__________________
Дети не должны знать о своих родителях |
Часовой пояс GMT +4, время: 14:49. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|