Пятница, 22 Ноября 2024, 09:10

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 1
  • 1
Здания на локациях - организация бд
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, Действительно, сумбурно я всё написал. В целом вы всё поняли верно, кроме последнего пункта "один и тот же тип может иметь разную функциональность", тут не совсем так. Вот к примеру есть тип здания банк - банков может быть много и они могут иметь разные названия и описания, а механика одна и та же. Открытие счета, переводы, снятие и тд. Другой тип здания допустим завод, там вообще совсем другая механика.

Во всём остальном всё верно и я попробую сделать так как вы сказали. Я собственно изначально думал сделать примерно так, но что то отошел в сторону :D Опыта в этом смысле маловато


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
  • Страница 1 из 1
  • 1
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг