Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Удобное — это Excel таблица и ее импорт в юнити. А то что вы описали — это НЕ удобно.
Для локальных каких-то «баз» — например, баз настроек процедурных анимаций, или не знаю чего еще — да. Но геймдизайнеру такое не показывайте. Здесь он не сможет параллельно конфигурации еще и баланс расписать.
Для локальных каких-то «баз» — например, баз настроек процедурных анимаций, или не знаю чего еще — да. Но геймдизайнеру такое не показывайте. Здесь он не сможет параллельно конфигурации еще и баланс расписать.
Таблица не всегда удобно. Например при если есть базовый предмет(Цена, имя, Id) и от него унаследованы оружие, броня, хилки и т.д.
Опять же удобнее перекрещивать таблицы(например если рецепт ссылается на несколько ранее созданных предметов, или лут из монстра)
Для выше описанного редактора можно прикрутить еще и нодовскую систему (для ветвления диалогов например) и это будет визуально понятно.
Баланс да придется отдельно просчитывать хотя некто не мешает чучуть доработать систему.
Кстати эта система создавалась под руководством геймдиза.
Опять же удобнее перекрещивать таблицы(например если рецепт ссылается на несколько ранее созданных предметов, или лут из монстра)
Для выше описанного редактора можно прикрутить еще и нодовскую систему (для ветвления диалогов например) и это будет визуально понятно.
Баланс да придется отдельно просчитывать хотя некто не мешает чучуть доработать систему.
Кстати эта система создавалась под руководством геймдиза.
Зачем хранить все в 4х Dictionary, а не в 1ом?
Потому что в дальнейшем это будет хранится в отдельных таблицах базы данных и у каждой будут свои индексы. В один словарь их не засунуть(ключи будут повторятся)
Если цель хранить их в разных не связанных таблицах БД, согласен.
Но так будет очень неудобно работать со всеми элементами в целом.
Например, мы не сможем получить экземпляр IData только по id, без указания его типа, использовать всю мощь полиморфизма и т.д.
Не лучше ли сделать один Dictionary<int, IData>, а базе данных разнести информацию по таблицам следующим образом:
В «основной» таблице например BaseItems хранить автоинкрементный id и поля общие для всех типов IData.
Для каждого типа IData создать таблицу, которая будет хранить только поля специфичные для данного типа и id. И по id связать все эти таблицы с BaseItems.
Но так будет очень неудобно работать со всеми элементами в целом.
Например, мы не сможем получить экземпляр IData только по id, без указания его типа, использовать всю мощь полиморфизма и т.д.
Не лучше ли сделать один Dictionary<int, IData>, а базе данных разнести информацию по таблицам следующим образом:
В «основной» таблице например BaseItems хранить автоинкрементный id и поля общие для всех типов IData.
Для каждого типа IData создать таблицу, которая будет хранить только поля специфичные для данного типа и id. И по id связать все эти таблицы с BaseItems.
Конечно так тоже можно.
Только тогда в IData надо еще добавить поле с типом данных чтоб вытаскивать весь список.
Возможно даже будет удобнее надо будет попробовать.
Только тогда в IData надо еще добавить поле с типом данных чтоб вытаскивать весь список.
Возможно даже будет удобнее надо будет попробовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удобное решение для игровой базы данных на основе EditorWindow