Вопросы
Влад Демин
1048

[Unity] — Как хранить базу предметов?

Лично у меня два варианта: БД или создание json’а для каждого экземпляра ScriptableObject и сбор их в list’ы.
У кого есть опыт, подскажите какой вариант лучше себя показывает, и есть ли какие-то другие.

Белым — то, у чего есть возможность создать json.

Look at my post, My post is amazing!
{ "author_name": "Влад Демин", "author_type": "self", "tags": ["unity"], "comments": 50, "likes": 18, "favorites": 64, "is_advertisement": false, "subsite_label": "ask", "id": 211222, "is_wide": true, "is_ugc": true, "date": "Wed, 16 Sep 2020 08:04:40 +0300", "is_special": false }
Объявление на DTF
0
50 комментариев
Популярные
По порядку
Написать комментарий...

Многолетний кран

9

Всё зависит от количества предметов, их сложности и того, как часто их придётся редактировать.

JSON подойдёт для небольших баз и сложных предметов — с кучей свойств, подсвойств, триггеров, эффектов и прочего.
В JSON можно быстро найти отдельный предмет и его отредактировать, не боясь повредить другие предметы.

Нужно понимать, что в SQL-базе всё это придётся разбивать на отдельные таблицы и делать отдельные таблицы связей.
Зато можно хранить тысячи свойств и эффектов, и десятки тысяч предметов в очень компактном виде. А одним запросом корректировать свойства сотен предметов.  Конечно, тут редактировать что-то — это адище без удобных форм.

Ответить
7

Ананасик бы помог, ананасик бы посоветовал.. @Andrey Apanasik где же ты

Ответить

Религиозный велосипед

Kerokokerko
5

бота настроил и спит

Ответить

Белорусский паркур

Kerokokerko
3
Ответить
3

Настоящий вопрос сколько будет итемов? 1000, миллион, сотни тысячь? Какой способ расстановки их в интерфейсе - по клеточкам или по порядку. Каждая реализация накладывает на себя разные особенности хранения. в простейшем случае - сериализируйте в строку split/join через свои методы, json крайне избыточен зачем вам создавать {} обьект если достаточно записать w1;100;i2;300;i5;500 (w,i класс предмета число количество)

добавлю про БД - она дает выйгрышь так как там заранее реализованна индексация для быстрого поиска по id - если у вас линейный поиск (сотни тысячь) уже не проканает - и загрузить в память чтобы построить Хеш нельзя. Больше ни для каких целей бд вам не нужна. Хотя нафига вам сотни тысячь описнай предметов я не представляю

Ответить

Многолетний кран

Алексей
2

 json крайне избыточен

А когда-то так говорили про XML :)

Ответить
5

xml бескрайне избыточен - все веб технологии созданы для идиотов, тем и перкрасны

Ответить
3

SQLite не подойдёт? Легковесный вариант, для вашей задачи вполне подходит. Хотя никогда не имел дела с играми, не знаю как там лучше.

Ответить
1

Просто перейти на UE и забыть все эти проблемы, как страшный сон. 

Ответить
1

А как это работает на UE? (Всегда, кстати, было интересно, как в играх решается вопрос с хранением сотен характеристик и тд)

Ответить
1

Вопрос конкретной задачи (десять предметов или тысяча, сколько параметров) - но у УЕ есть встроенные, оттестированные и удобные тулзы для широчайшего спектра задач. Как минимум не надо ничего гонять руками в джсоны. В отличие от Юнити, который требует вот так писать код на каждый чих. 

Ответить
6

И ответа на вопрос, что же там в UE, так и нет...
В отличие от Юнити, который требует вот так писать код на каждый чих.

Ни одно решение из коробки никогда не покроет потребностей всех разработчиков.

Ответить
1

Ну да. Потому будем писать свои костыли на все вообще. 

Ответить
2

Так что там в UE за решения для хранения данных?

Ответить
2

Банально контент браузер. 

Можно лезть еще в дата ассет, но там да, возможно придется потрогать руками код - хотя и сильно меньше, чем в Юнити. Но этого не хочется, согласен. 

А если предметов немного, можно вообще сделать отдельные скрипты на блюпринтах. 

Ответить
0

Как минимум не надо ничего гонять руками в джсоны.

А тут где что вручную загонять нужно?

Ответить
2

Лично мне кажется, что писать С# код - это и есть "руками". А в юнити куда ни плюнь, шарп код нужен. Вот как на вашем скриншоте. В Анриале я плюса не видел вообще никогда. :))

Ответить

Южный паркур

Констан…
2

Не понимаю, в чем плюс, когда нет доступа к самостоятельному написанию кода.
Ты попросту лишаешься огромного поля и инструмента для творчества

Ответить
2

А вы попробуйте не 3 в ряд, а большую игру на юнити сделать. Все поймете. 

Если что, не наезд - просто факт из жизни. В крупных конторах идет разделение труда. ГД работает в блюпринтах. Кодеры пишут свои какие-то глубокие вещи. Каждый занят своим делом. Никто и никогда не переписывает потом БП в плюса. Во всяком случае, впервые о таком слышу. 

А когда ГД должны писать код выясняется, что они это делают плохо - потому что это не их работа. И либо у нас появляются отдельные сущности типа "скриптеров", либо еще какие ужасы. Что и приводит к анедкдотам про "игра на юнити работает как говно". Ну еще бы. 

Во всяком случае, вся моя практика об этом говорит. 

Ответить
2

Простите, а ГД прям много что либо делают в блюпринтах? Я знаю, что левел дизы могут таким заниматься, чтобы развешивать всякие триггеры и шлифовать их. А ГД разве что прототипами балуются, а в сам проект не льют. Если конечно речь не про узконаправленных геймдизов, по типу - геймдизайнер боевой системы.

Ответить
2

Не знаю - я делаю. :)))

Но вообще все, кого я знаю, делают. Расставляешь триггеры и монстров, таймишь катсцены, пишешь НПС, пишешь флоу квестов, раскидываешь тайники - да куча всего. "Общим планированием ГД" на моих проектах после постпрода в основном занимались лиды\креативный директор. И даже они какие-то фичи реализовывают сами. Банально - ГДД пишется в первый год, а потом ты еще 3 фигачишь проект. Изменения там бывают, но ручной работы там сильно больше, чем высокоуровневого планирования. И, обычно, логика простая - спринт ты пишешь всякие миро-таблицы с доками, упиваясь творчеством (но сверяясь с ГДД) - а потом еще пару месяцев реализуешь свой крутой креатив, как раз в движке. И полишишь его до релиза. Ну или до фичекатинга - тут как повезет. :))

Ответить
2

Спасибо за ответ.
Не работал, увы, в проектах с описание ГДД (препродакшн?), где потом спокойно 3 года фигачишь фичи. Все проекты 3месяца-15месяцев, хех. С постоянным перепрыгиванием с проекта на проект.
Ожидал, что катсцены, тайминги и прочее больше ЛД занимаются. А геймдизы больше докручивают и проверяют "работу". Хотя предполагал, что зависит от команды и компании, потому что пайплайны и задачи могут разнится. Да и от типа проекта тоже может зависеть многое. Тот же ЛД может полгода делать и настраивать ПвП карту для какого-то шутера. А то и больше.
А насчет ручной работы, понимаю. Даже просто расставлять простую геометрию (блокаут) по уже готовому плану может занимать много часов рутины. Приятной, но рутины

Мобильный геймдев. Здравствуйте. 

Ответить
2

Ну вот да, это особенность больших игр, видимо. Увы, я знаю лишь в теории - я мобильными играми сам никогда не занимался, совсем не моя чашка чая. Ну и да, конечно же, в производстве игр сколько контор - столько и пайплайнов. :)) Но я слышу, в основном, такие рассказы и сам видел плюс-минус такие системы.

Ответить
2

Не могу и сам сказать, что мобильный геймдев это прям уж моя чашка, но пока приходится из нее пить). Надеюсь и работаю над переменами в этом пути.

Ответить
2

Удачи. Поверьте - это куда реальнее, чем вам кажется. Люди нужны везде, а переезд - ну что поделать. В Европе тоже неплохо. :))

Вы, главное, помните, что ваше портфолио в мобильных играх вообще никаких плюсов вам не даст при трудоустройстве. Не хочу обидеть, это грустно, но вот так вот оно в жизни. А вот хотя бы одна игра или даже демка - но законченная, с кусочком сюжета, механиками, музыкой и прочим - вот это да. Это привлекает внимание и такие люди очень нужны.

Собственно вот оно и пригодится, базовое знание блюпринтов и прочих инстурментов анриала. :))

Ответить
2

Спасибо. Правда насколько знаю, больше зависит не от платформы, а от типа игр, которые ты делал/делаешь. С гиперказуалками конечно же нахрен ты не нужен) Как и наоборот.

Сейчас штрудирую Unity более детально, вместе с Unreal Engine, делая разные задачи, делая упор больше на инструментарий. В том же UE4 пока сложно даже блокаут собрать, потому что рука не набита к интерфейсу)
Понемногу записываю всякие идеи и думаю, что же можно сделать самому в плюс-минус адекватное время. Может даже скооперируюсь с кем-то, посмотрим.
Да и над портфолио работаю. Надеюсь за полгода будет какой-то заметный результат.
Еще бы английский вытянуть, особенно речь, но как это все делать одновременно и не выгореть, не знаю)

Эх, жаль в молодости был проблемным юношей. Нет, чтобы учится и о здоровье заботится)

Ответить
2

Все окей, я после 30 пошел в геймдев. :)) Правда, английский был неплохой - играл в оригинале на приставках с молодости. Но остальное да, нарабатывал.

Все будет. По шажкам. Не надрываясь. =^____^=

Ответить
2

Никто и никогда не переписывает потом БП в плюса. Во всяком случае, впервые о таком слышу.

В анриле есть возможность сделать компиояцию Блю принтов в С++ через автомат это ускоряет работу игры , да и занимает пару минут. 
А вот ручками это конвертировать никто не будет , да. 

Ответить
2

все сделанное автоматическими генераторами работает фигово по умолчанию. Шарпы самый мошный инструмент  сечас на рынке - мошнее явы и схх. В юнити есть куча асетов для кодирования визуального и недавно юнити купила один из них, и он лучше чем блупринты.

Унриал мошный движек - его плюс это то что его делают разрабы игр, в отличии от юнити которые разрабы ТОЛЬКО движка. НО разрабы игр не пользуются блупринтами - поэтому это не являтеся сильной стороной. Блупринты это инструмент геймдиза не более чтобы запрототипить то что сделает потом профессиональный программист

Ответить
2

ИИ в The Division например сделан через блу принты.

Ответить
2

В тему: недавно на хабре вот такую вещь нашел, может пригодится
https://habr.com/ru/post/519078/

Ответить
2

Бд использовать не вижу смысла

со ScriptableObject могут возникнуть проблемы(у меня слетали ссылки часто), постоянно в юнити заходить для правок каких то параметров, не подходит для каких то сложных структур(придется писать свои PropertyDrawer)

как по мне лучше json использовать, можно для гугл таблиц или эксель парсер написать и использовать их как редактор

Ответить

Любимый Даниль

1

А выгружать придётся?

Ответить
1

Проект сингловый, всё у клиента. Целиком всю базу вряд ли есть смысл грузить, максимум все предметы какого-то типа, что, как я понимаю, в бд таблицей делается, а тут одним List'ом (хотя, они и ссылочные, но, по идее, они всё равно должны эти предметы в оперативку грузить).

А для генерации случайного лута, проще конструктор сделать какой-нибудь, с кучей перегрузок, наверное.

Ответить

Любимый Даниль

Влад
2

Я бы точно сделал абстракцию. Потом если что сделаешь ее базой.

Но вообще база необязательно строки. есть несколько документных баз с плагинами для unity.

То есть для начала я бы сделал легковесную имплементацию backed by memory, а потом уже посмотрел что по памяти получается (плюс какие интерфейсы доступа мне нужны) и уже оттуда плясал.

Ответить
1

Я конечно ни один проект до релиза не довел, но мне кажется надо оценить количество объектов, факт их будущего добавления и количества взаимодействия с их параметрами. Если эти три пункта зашкаливают - лучше в отдельную базу данных для собственного же удобства. Если нет - оставляй объектами)

Ответить
1

Мне понравилось работать со ScriptableObject, удобно, добавление нового поля хоть и вызывает гемор, но меньший, чем другие способы,  и как я понимаю именно так во многих новых играх и хранятся предметы + намного удобнее хранить изображения в юнити в этом объекте, чем давать ссылки в БД

Ответить
1

Какой, блин, ScriptableObject, сериализация в юнити полный треш, я едва мирюсь с префабами, которые постоянно ломаются просто так, а тут бд запихать в эту дрянь. Ручная сериализация в json/xml и загрузка в словари в рантайме, редактирование в отдельном редакторе. Да, это мрак, в том плане, что надо писать кучу всего, но зато проблем с расширением и поддержкой не будет

Ответить
1

Не очень понятно, тебе надо создавать в рантайме предметы с рандомными характеристиками и сериализовать их или надо загружать заранее настроенные предметы?

Ответить
0

И то и то. Всякие хилки, оружие и прочее - предзаготовленные, особенно в случае каких-нибудь наград, но то же оружие можно бы и рандомно генерировать.

Ответить
1

Тогда начнем с того, что выбор БД или json как контейнера для сериализации в данном случае как бы не очень стоит. Потому что json - это единственный формат, который ты сможешь вменяемо юзать в Unity. Всё остальное либо хуже, либо дикий гемор. Сразу рекомендую отказаться от говённого встроенного сериализатора юнити и использовать Newtonsoft.Json.
Далее, когда ты определился, что будешь сериализовать в json, встаёт вопрос - куда его сохранять. Можно в текстовые файлы, можно в БД, где одним полем будет id какое-то текстовое или еще какое, по котором у ты сможешь искать предметы, а вторым - строка, где будет json, опционально могут быть еще какие-то поля для индексации и фильтрации при запросах, если это необходимо. Тут главное сразу понять, что эти поля должны быть универсальными для всех предметов, или ты потом запаришься менять структуру БД - а это конкретный гемор.
Недостаток сохранения в текстовые файлы может быть в том, что тебе при старте придётся считывать их все, что может занимать время (особенно на мобильных платформах). Так же, если тебе нужна индексация/фильтрация - то с файлами её нормально не реализовать (конечно я рассматриваю вариант, что не всё грузится в память сразу, а только нужное по запросу).

Ответить
1

В любом случае я рекомендую сериализацию в json с сохранением в БД.

Ответить
1

Кстати, по поводу ScriptableObject - не рекомендую использовать.
Во-первых, в рантайме ты их не сохранишь как файлы никак (только в редакторе)
Во-вторых, если на них где-то будут ссылки, то они будут загружаться в память всегда безусловно.
Ну и в третьих, это глючное говно с кучей нюансов, с которыми если столкнешься, придётся париться и писать костыли.
В них хорошо хранить только какие-то редактируемые в редакторе общие конфиги и т.п.

Ответить
1

Я с бд уже давно имел дело и в технических деталях там не силён, но мне кажется, что при использовании какого-нибудь sqlite выигрыша совсем не будет. В памяти оно может занимать места не меньше, чем те же десеарилизованные json'ы или скриптейблы, грузиться тоже не факт что будет быстрее. Если у тебя не будет множества связей между элементами твоей структуры, то от таблиц в итоге в итоге профита может и не быть совсем. Ну, если ты, конечно, не будешь ходить итеративно по всем элементам для поиска (в варианте без таблиц)

Вообще я бы делал для начала то, что проще, а потом уже оптимизировал при необходимости. Тут тебе скорее всего важнее будет удобный редактор сделать

Ответить
1

JSON. Если предметов много и отличаются не сильно, то JSON c наследованием :)

Ответить
1

Не используй ScriptableObject. У меня их всего 20, и уже неудобно.
Не используй SQL, запаришься схемы менять и миграции писать. Да и вообще в играх SQL создаёт больше проблем, чем решает.
Вместо JSON лучше используй CSV - можно будет всё наглядно редактировать в эксельчике, что гораздо удобнее.
В ассет сторе есть бесплатные плагины для интеграции CSV. С локальными файлами хорошо работают. Вероятно, некоторые решения поддерживают и гугл-шитс.

Ответить

Комментарии

{ "jsPath": "/static/build/dtf.ru/specials/DeliveryCheats/js/all.min.js?v=05.02.2020", "cssPath": "/static/build/dtf.ru/specials/DeliveryCheats/styles/all.min.css?v=05.02.2020", "fontsPath": "https://fonts.googleapis.com/css?family=Roboto+Mono:400,700,700i&subset=cyrillic" }