Войти
Unreal EngineФорумОбщее

Немного о логике инвентаря

#0
13:31, 5 дек. 2020

Приветствую всех!
В своё время - довольно давно - смотрел уроки от разных авторов по созданию инвентаря на UE4, логика была для меня странновата, но понятна. Нужный предмет не удалялся со сцены (иначе испортилась бы ссылка на него), а делался невидимым. Ну а при выкладывании спавнился заново, причём в логике мира просто игнорировались коллижены со скрытыми объектами инвентаря.

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

Конечно, я сторонник содержания объектов где-нибудь в самой игре, в этом случае ссылка на объект будет всегда рабочей. То есть не скрывать объект инвентаря, а перемещать в любое недоступное пользователю место, а потом менять actor location.

Но это тоже, хотя умозрительно ясно, мешает перфекционизму.
И я подумал, а вдруг есть ещё способы работы с инвентарём, ну вот прямо включённые в новые версии UE4 (или 5, уж не знаю, на что ориентироваться). Спасибо!

#1
13:48, 5 дек. 2020

Любопытно. А что в UE мешает удалить ненужный объект со сцены держа в памяти характеристики, а потом при надобности снова создать его?

#2
14:21, 5 дек. 2020

Мне видится что простых готовых решений нет. Точнее для простых инвентарей есть, но требования к функционалу сильно разные от проекта к проекту, если инвентарь предполагается тяжелым и сетевым (рандомные по статам вещи при генерации, одевание характеристик с предмета на персонажа, снятие их, использование типа бутылок, свитков, крафт, апгрейд, стаканье по ходу дела и т.д. и т.п.) , то без сложных реализацией не обойтись. В случае с детерминированными вещами, когда они не меняются, кроме как в количестве, то лучше создавать spawn actor и удалять destroy, самого носителя, а вещь лишь цепляется к носителю, т.е. у тебя носитель либо вывалившийся предмет который на земле лежит либо носитель это тот кто поднял. Соответственно если выпавший предмет имеет life span то у тебя удалиться носитель и сам предмет, точно так же и по destroy носителя ты убьешь их обоих. Мусорщик в UE4 хороший, в отличии от Unity.

#3
(Правка: 17:09) 16:51, 5 дек. 2020

Давай по порядку..
> логика была для меня странновата, но понятна
Объясню. Каждый раз когда ты спавнишь Actor идёт микрофриз. Если он один, ты не особо сильно его замечаешь. Почему? Потому что Actor может иметь блупринит. Потому что каждый Actor может иметь AnimBlueprint, сам является прородителем APawn (пешка, в простонорадье, которая передаёт ещё и пакеты по сети). А так как это и APawn, то также каждый Actor может иметь AI_Controller. А он в свою очередь BehaviorTree. Короче, это прям.. универсальный объект. Это я ещё промолчал про skeletal mesh и physics asset..

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

Итак, подведём итог. Плюсы данного метода в том, что нет фризов при спавне старого предмета, даже если его стало больше чем было. И ты видишь его сразу перед собой. Минусы, излишняя перегромождение сцены (но вообще, не будь там иерархии объектов на сцене, ты бы никогда о них и не узнал). А объекты нужны. Для этого пишутся Pool Manager (Objects Pool), которые хранят у себя готовые объекты, пока ты их не попросишь. А всё что (якобы) удаляется, попадает обратно в него со сбросом в дефолтные значения. То есть, в нормальных играх так и устроено, даже в Unity.

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

чего не видно, того и нет

> восстанавливать десятки скрытых дубликатов, выложенных пользователем
а это скорее плюс, чем минус. Ещё и сохранение (загрузка) на халяву работает как надо.

Ты спрашивай.. )

Как доберешься до с++, будет примерно точно такое же решение, с разницей лишь в том, что придётся ещё где то хранить выброшенные объекты, ведь если ты сменишь уровень ониж потеряются, вещи то..

#4
19:15, 5 дек. 2020

Игрок держит оружие и убирает его в инвентарь. Нужен нам сам объект? It depends (к примеру, если на нём висит временный бафф), для простоты считаем что не нужен. Достаточно взять менеджер инвентаря, внести в него запись:

Класс объекта: "меч великой вони"
Урон: 10
Тип урона: природный

А сам объект удалить. Когда игрок в следующий раз решит взять меч, мы можем, например, заспавнить актор меча (который и сам прекрасно знает свои постоянные характеристики, вроде меша, коллайдера и материалов) и выставить соответствующие переменные. Остаётся вопрос с тем, как архивировать-разархивировать данные, но это уже зависит от конкретной игры. В качестве топорного решения, я бы сделал structure, в которой первым полем был бы enumeration, задающий, через какую логику на это смотреть (оружие / броня / ресурсы), а дальше штук десять полей string, в которые и забивались бы сведения.

Также полезными могут оказаться soft reference
Короткая версия:
https://vimeo.com/408603845

Полный стрим (с 18 минуты):

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

Unreal EngineФорумОбщее