|
Здания на локациях - организация бд
| |
| JanCarlo | Дата: Четверг, 31 Марта 2022, 21:16 | Сообщение # 1 |
|
был не раз
Сейчас нет на сайте
| Добрый вечер!
Подсобите советом как организовать грамотно структуру базы которая отвечает за установку зданий на локации.
Игра браузерная, текстовая, на ларке. Решаю вопрос связи зданий с локациями по бд. Большинство локаций не имеют отношения к игровой механике, только бои и монстры на локациях. Но некоторые локации ключевые.
Допустим банк на локации, госпиталь лечебный, магазин и прочее. Игрок приходит на локацию, название, описание и координаты подгружаются из таблицы rooms.
1) Сейчас есть база локаций (таблица rooms, поля x/y/z/name/description/room_type_id/zone_id).
Допустим: id475/5/5/5/Вход в пещеру/Севернее виднеется проход в пещеру/1/1
2) Есть таблица room_types (room_id / name / type) - Общая таблица типов зданий (под каждый тип зданий своя отдельная таблица)
Допустим: id1- 475 / Банк / bank
id2 - 476 / Магазин / shop
3) Есть таблица конкретно банков room_type_banks (room_id / name / description и будут добавляться еще поля отвечающие за логику банка)
Допустим: 475 / СверхВыгодный банк / Здесь вы можете сохранить свои честно награбленные деньги!
Суть в том, что структура самих локаций меняться не будет, если только дополняться.
А вот зданий будет много и логика их работы будет очень разная. Магазинов как и банков как и других зданий будет много.
Я подумал так, что перед отрисовкой локации, где я из бд дергаю данные от самой локации, я буду дополнительно идти в общую таблицу зданий, и выяснять тип здания на локации по её ИД.
Далее из модели общих зданий я свичом распределяю запросы, типа если тип локации bank, то идем в подТаблицу room_type_banks и по ид локации находим запись банка который принадлежит к этой локации.
Всё бы ничего, вроде более менее универсально получается. Таким образом я собрал все данные о банке находящемся на этой локации и таким образом я могу собирать и все остальные данные о других зданиях.
Но, вопрос!
К примеру банк имеет возможность открыть счет игроку (разово) если счета нет, если счет есть то отрисовывается форма управления своим счетом, кнопка историй переводов и так далее, история переводов идет в отделный component во вью. Допустим открытие нового счета идет по маршруту /createBankAccount - по этому пути в контроллер передаются данные о юзере и в контроллере есть метод create который откроет юзеру счет. Ну и другие методы управления счетом.
Каким образом мне собирать данные о других типах зданий и так же универсально отправлять во вью? Не могу же я во вью писать логику под каждый тип здания. В целом не совсем понятно, как после сбора сведений о типе зданий выбрать необходимый blade шаблон для отрисовки здания. У каждого типа здания может быть несколько маршрутов и всё это будет сильно отличаться от других типов зданий. Допустим у банка маршрут на создание счета, на переводы/пополнение, маршрут на историю транзакций. А у здания госпиталя один маршрут - отхилить игрока и всё.
Возможно просто на каждый типа зданий заготовить заранее все необходимые шаблоны, которые будут содержать все необходимые маршруты, останется додумать как выбрать шаблоны в зависимости от типа здания.
Да и в целом, хороша ли такая концепция? Я такое первый раз пишу.
VK группа игры (Разработка c 22 года): https://vk.com/browsermud
Сообщение отредактировал JanCarlo - Четверг, 31 Марта 2022, 21:23 |
|
|
| |
| lvovand | Дата: Пятница, 01 Апреля 2022, 09:31 | Сообщение # 2 |
|
старожил
Сейчас нет на сайте
| как видится наброском:
есть какой-то общий класс для зданий, а каждый конкретный тип здания уже наследует общие правила и добавляет свои методы. Вью раздельные то наверно не самая большая сложность, вот с хранением данных - либо разные таблицы, либо объекты сохранять надо будет в полях таблицы, либо часть данных хранить в noSQL
Разработка и продвижение сайтов. Дизайн
|
|
|
| |
| TLT | Дата: Пятница, 01 Апреля 2022, 09:39 | Сообщение # 3 |
Сейчас нет на сайте
| Цитата JanCarlo (  ) Возможно просто на каждый типа зданий заготовить заранее все необходимые шаблоны, которые будут содержать все необходимые маршруты, останется додумать как выбрать шаблоны в зависимости от типа здания.
Если отличия кардинальные, то лучше для каждого типа делать отдельный шаблон, я думаю. Я бы вообще делал как в "Героях" - со своим фоном, звуком, индивидуальными фичами. А вообще, я бы посмотрел, как это выполнено в похожей игре - найди на GitHub открытый аналог, шаблон похожей игры с БД зданий и перенимай опыт.
Дао, выраженное словами, не есть истинное Дао.
|
|
|
| |
| maker-rus | Дата: Суббота, 02 Апреля 2022, 22:54 | Сообщение # 4 |
Гений
Сейчас нет на сайте
| JanCarlo, первое, что необходимо для проектировки базы данных - умение формулировать мысли, что в топике практически отсутствует и читается он, как:
Цитата у меня есть три рубля и однажды, когда я читал историю на форуме, то пошел в магазин и короче мы кушали конфетки, когда смотрели телевизор
Слишком сумбурно. Из того, что мне удалось понять:
- Нужен совет, по поводу организации хранения типов зданий в базе данных
- Используется Laravel (PHP)
- Есть три таблицы: rooms (x / y / z / name / description / room_type_id /zone_id), room_types (room_id / name / type) и room_type_banks (room_id / name / description)
- Можно создавать локации
- Созданные локации не будут меняться
- Есть возможность создавать различные игровые объекты, в виде зданий
- Один и тот же тип может иметь разную функциональность, в различных условиях
Изначально остановлюсь на формулировке таблиц, есть три таблицы, где одна из них расширяет другую. Я считаю такой подход максимально неудачным. Так как при создании других зданий, придется создавать новую таблицу и так до бесконечности. Расширение у такого подхода - максимально больное. Что делать? Отказаться от таблиц типа room_type_названиездания.
Какая замена? Замена достаточно простая. Создать таблицу, которая хранит в себе все возможные виды зданий.
Пример таблицы build_list:
- id [PK]
- type_name [VARCHAR] - наименования типа постройки, например: bank, tavern, shop, arena
- title [VARCHAR] - название постройки, например: магазин сладостей, арена смерти, банк TLT Ltd.
- action [VARCHAR] - наименование класса отвечающего за этот объект, например CandyShop.
В итоге, каждый класс отвечающий за то или иное здание работает со своим зданием так, как считает нужным. А в отображении или как говорил автор топика "вью" указывается ссылка на "маршрут", по типу /build/102, или /build?id=102. Внутри контроллера, который обрабатывает маршрут вызывать нужный класс для обработки.
Пример, у нас есть здание: Магазинчик сладостей, алгоритм будет такой:
- Переход по условной ссылке: www.mysupergame.ru/build/653
- Вызывается метод контроллера BuildController, например index. То есть вызов будет таким BuildController::index(id).
- В методе index мы получаем по id = 653 из таблицы build_list нужное нам здание, допустим, что по этому id там находится запись: id = 653, type_name=shop, title=Магазинчик сладостей, action=CandyShop.
- Получив запись, получаем из нее значение action = CandyShop. Теперь мы знаем какой класс нужно вызвать.
- Создаем объект класса CandyShop и передаем в него все нужные значения через конструктор, либо с использованием шаблона "строитель".
- Что-то делаем, используя этот класс, например: загружаем все доступные для персонажа сладости.
- Вызываем метод класса, который возвращает название шаблона, например: шаблон с названием shop/candy_shop.blade
- Вызываем через встроенную функцию отображение шаблона и туда передаем данные, что были получены в результате работы класса CandyShop, например: вызвав метод, который возвращает полученные из базы данных все доступные для игрока сладости, по типу CandyShop->getCandies(): array, который возвращает массив из сладостей.
- В отображенном шаблоне выводим доступные сладости, используя функциональность шаблонизатора
- Профит
|
|
|
| |
| JanCarlo | Дата: Понедельник, 04 Апреля 2022, 09:56 | Сообщение # 5 |
|
был не раз
Сейчас нет на сайте
| Господа, всем спасибо.
maker-rus, Действительно, сумбурно я всё написал. В целом вы всё поняли верно, кроме последнего пункта "один и тот же тип может иметь разную функциональность", тут не совсем так. Вот к примеру есть тип здания банк - банков может быть много и они могут иметь разные названия и описания, а механика одна и та же. Открытие счета, переводы, снятие и тд. Другой тип здания допустим завод, там вообще совсем другая механика.
Во всём остальном всё верно и я попробую сделать так как вы сказали. Я собственно изначально думал сделать примерно так, но что то отошел в сторону  Опыта в этом смысле маловато
VK группа игры (Разработка c 22 года): https://vk.com/browsermud
|
|
|
| |
| Эргалон | Дата: Понедельник, 04 Апреля 2022, 16:26 | Сообщение # 6 |
Вездесущий
Сейчас нет на сайте
| JanCarlo, применяй наследование. BaseBank - функционал, в котором вся логика и одинаковые данные для всех банков, дальше уже NewBank extends BaseBank. Если надо здания, то соответствено NewBank extends BaseBank extends BuildingBase. В твоем случае что-то вроде NewFactory extends BuildingBase. В базе данных примерно такая же организация. Должен быть стартовый шаблон для любого здания, в данном случае BuildingBase. Его наследуют все прочие здания, собственно из базы ты также должен вытягивать инфу о шаблоне, к которому привязаны другие сущности/здания
Кубариум
Rise of the dark lords
Сообщение отредактировал Эргалон - Понедельник, 04 Апреля 2022, 16:33 |
|
|
| |
|
