UEngine.Ru

Есть общий класс GameObject. От него наследуются Building и NPC. От Building наслудуются Chest, Workbench, Portal, и.т.д. и т.п. Каждый из наследников Building имеет свои собственные поля. При сохранении игры мне необходимо сохранить каждый GameObject на уровне. Как это можно реализовать?

Версия: 4.18.3
Blueprint

...
getallactorofclass(GameObject)
и пакуешь все из них в структуры в структуре хранить все что необходимо чтоб заспавнить обьект в том состоянии в котором нужно.
каждому классу написать логику запаковки в структуры.(обратная логика распаковки тоже должна быть для загрузки)
получится структра общая с массивом структур обьектов.
структуры сохраняем стандартно. как-то так...
В блупринтах(!) по другому как сделать - мне не известно(но справедливости ради я слишком мало изучал этот вопрос)
Поэтому может кто-то раскажет как это можно в принтах "по человечески" все-таки сделать
Можно еще плагины готовые поискать фришные или на маркетплейсе... потому что на ++ все по другому, совсем...
_________________
we need to go deeper

@Snake я в точности так и делал. Остановился только на моменте, когда осознал, что для каждого такого класса мало того что нужно будет создать свой struct, так еще и свой массив внутри SaveGame. По мне так это слишком. Неужели нет способа автоматически запаковать объект в строку/байтовый массив, чтобы потом его просто засунуть в однотипный массив/словарь?

да, для начало создай структуру, всего что нужно хранить. Помни что ты не можешь сохранять ссылки на объекты. Создай энуменатор GameObject, в нем укажи его наследников. Также создай энуменаторы и для других наследников, все правильно рассортируй по папкам.
Размести все енуменаторы в структуре...

а потом я понял, что это не рассказать))

в блупринтах мне такой способ не известен.
_________________
we need to go deeper

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

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

p.s. все переменные(структуры) которые должны быть сохранены, должны быть в SaveGame.

p.p.s. кнопку - "сделать сохранение" разработчики UE4 еще не реализовали, мб в следующих версиях))

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

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

И да, я раньше всегда пользовался только интежером для идентификации объектов, и избегал создавать енуменаторы для этого, сейчас это выглядит
для меня, не менее глупым чем и отказ от структур.

p.s. больше енуменаторов, больше структур.

В общем, я так понял. Создать наперед единый автоматизированный механизм для работы со всеми объектами сразу не выйдет. Да?

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

p.s. например ты добавил возможность ботам гореть, естественно в структуре в разделе для ботов(структура в структуре), нужно будет добавить булевую IsFire, которая будет хранить, горит ли бот, и вторую переменную TimeFire, это для того что бы помнить как долго горит бот. И так со всем, если ты не будешь использовать структуры, тебя ожидают б0льшие трудности.

p.p.s. еще мне трудно мне понять, зачем вы плодите кучу классов, то есть наследников. В твоем бы случае, у меня было бы просто два блюпринта, один типа чарактер - NPC, второй актор - Building, какой конкретно это нпц или буилдинг, определяют энуменаторы(переменные типа байт) внутри класса, то есть меняют меш и другие параметры.
Мне лично при таком раскладе гораздо удобнее, но большинство почему то это не приемлет. Для сохранения, нужно получить текущее значение енуменаторов в классе, ну и трансформ, добавить эти значения в массив структуры и сохранить.

Если интересует дополнительная оптимизация, значение всех булевых, енуменаторов, и т.д., можно поместить в одной переменной типа стринг, заморачиватся так или нет, каждый решает для себя сам.
Вот пример записи переменных в стринг.
http://picua.org/img/2018-01/21/6u6s892 ... lsvtm6.png

вот так извлекаются данные из стринг
http://picua.org/img/2018-01/21/zswdb14 ... l7ipyw.png

делиметр может быть какой угодно, но если будет например пробел, а у нас переменная Name может иметь значение, из двух слов, то будет ошибка так как там будет пробел, тоже и с другими символами, поэтому я выбрал два этих символа, супер маловероятно что такая комбинация может гдето использоваться..
Последний раз редактировалось Prytaleks 21 янв 2018, 04:16, всего редактировалось 1 раз.

Каждый наследник Building имеет свои собственные поля. Например, сундук имеет компонент Inventory. Какая-нибудь печка, например, имеет переменную, отвечающую за степень готовности продукта.