Pull to refresh

Comments 9

Удобное — это Excel таблица и ее импорт в юнити. А то что вы описали — это НЕ удобно.
Для локальных каких-то «баз» — например, баз настроек процедурных анимаций, или не знаю чего еще — да. Но геймдизайнеру такое не показывайте. Здесь он не сможет параллельно конфигурации еще и баланс расписать.
Таблица не всегда удобно. Например при если есть базовый предмет(Цена, имя, Id) и от него унаследованы оружие, броня, хилки и т.д.
Опять же удобнее перекрещивать таблицы(например если рецепт ссылается на несколько ранее созданных предметов, или лут из монстра)
Для выше описанного редактора можно прикрутить еще и нодовскую систему (для ветвления диалогов например) и это будет визуально понятно.
Баланс да придется отдельно просчитывать хотя некто не мешает чучуть доработать систему.
Кстати эта система создавалась под руководством геймдиза.
Потому что в дальнейшем это будет хранится в отдельных таблицах базы данных и у каждой будут свои индексы. В один словарь их не засунуть(ключи будут повторятся)
Если цель хранить их в разных не связанных таблицах БД, согласен.
Но так будет очень неудобно работать со всеми элементами в целом.
Например, мы не сможем получить экземпляр IData только по id, без указания его типа, использовать всю мощь полиморфизма и т.д.
Не лучше ли сделать один Dictionary<int, IData>, а базе данных разнести информацию по таблицам следующим образом:
В «основной» таблице например BaseItems хранить автоинкрементный id и поля общие для всех типов IData.
Для каждого типа IData создать таблицу, которая будет хранить только поля специфичные для данного типа и id. И по id связать все эти таблицы с BaseItems.
Конечно так тоже можно.
Только тогда в IData надо еще добавить поле с типом данных чтоб вытаскивать весь список.
Возможно даже будет удобнее надо будет попробовать.
Поле с типом данных не нужно. Нужно просто наследовать классы описывающие разные типы от абстрактного класса, который наследовать от IData.
Без этого поля будет проблемно получить список данных указанного типа (например все предметы). И нет понимания из какой таблицы потом дергать описания элемента
Проблемы не будет т.к. у них будут разные классы. Описание любого элемента можно будет легко получить только по его id. А при запросе к бд, если нужно получить данные для нескольких (или всех) элементов разных типов нужно будет использовать LEFT JOIN, а для какого-то конкретного типа INNER JOIN.
Only those users with full accounts are able to leave comments. Log in, please.