UEngine.Ru

Доброго времени суток.
Новичок. Требуется пинок в верном направлении.

Есть класс Hero, который содержит имя, живучесть и силу героя.
Есть два экземпляра этого класса с различными параметрами.
Они рождаются вначале игры и умирают с её завершением.

Имея крайне смутные представления об организации взаимодействия внутри движка, я пришёл к подобной архитектуре:
Класс Hero (наследуется от Actor).
Класс Heroes (наследуется от Actor). Включает две переменные с именами героев, содержит функцию для их первичного создания.
Класс Game (наследуется от GameMode). Включает одну переменную Heroes. Сохраняет и загружает данные между сеансами.

Вопросы:
1) Верна ли архитектура?
2) Допустимо ли наследоваться от Actor в случае с Heroes? По факту, мне нужна просто коллекция объектов. Она не имеет визуального представления и не взаимодействует с игровым миром. Она не располагается на сцене, а существует исключительно внутри GameMode. Но в ней должна быть возможность задать значения по-умолчанию для объявленных переменных - в Blueprint Structure такой возможности нет. Можно вынести инициализацию в другой класс - опять же - в какой? В сторону С++ на данный момент стараюсь не смотреть, так как задача тривиальная, и хочется выжать максимум из инструментов предоставляемых UE.

Ещё архитектурный вопрос:
Как правильно инициализировать синьку Heroes?
Сейчас я для каждого героя вызову функцию:


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

Я вижу несколько вариантов:
1) Синьки-фабрики, в событии Begin Play, конструирующие всё множество необходимых объектов. (Текущий)
2) Массивы или синьки-контейнеры, содержащие редактируемые, но не инициализированные переменные, настраиваемые через окно Details. (Громоздко для больших коллекций)
3) Массив объектов, создаваемый на основе внешних данных, н.п. CSV-таблиц (не существует с точки зрения UE).
4) Синька с предустановленными параметрами для каждого объекта (огромное количество модельных синек без какой-либо логики).

Подскажите верный путь развития.
Я бы хотел иметь всего один класс Hero и отдельный редактор, который позволит редактировать список героев, создавая для каждого из них именованную переменную, задавая начальные параметры, коллекция которого доступна из глобального контекста Game Mode.

(Далее сложно!) Совсем замечательно было бы разделить его выхлоп на три уровня абстракции:
1. Неизменяемые в игре шаблоны предустановок, создаваемые редактором, хранящиеся на диске в CSV.
2. Их экземпляры в глобальном контексте, создаваемые на основе шаблонов в оперативной памяти.
3. Их клоны в локальном контексте уровня, с ручной синхронизацией между уровнями.

В этом случае, все параметры, задаваемые в редакторе определяются в отдельной структуре HeroData. Массив таких структур сохраняется / загружается с диска во время работы редактора. GameMode инициализирует по требованию структуру на основе существующего шаблона (опять же HeroData). А уже на сцене создаётся Actor, которому задаётся копия этой структуры, с возможностью сохранить изменения в глобальный контекст.

Если кто-нибудь что-нибудь понял из последнего описания, то было бы здорово услышать ваше мнение:
1) Правильный ли это подход?
2) Есть ли смысл разделять п.2 и 3 или вместо копирования стоит передавать ссылку на структуру, а вместо синхронизации "полезных" изменений, откатывать "вредные" посредством Game Save/Load?
3) Как организовать такой вот встроенный в UE редактор коллекции объектов? От Blueprint Structure он должен отличаться возможностью в удобном виде задать значения по умолчанию. В идеале - таблица со скроллами. Уметь работать не только с .assests, но и с .csv.

Только что заметил, что редактор и вовсе отказывается инициализировать самописные синьки:


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

1. архитектура допустима.
2. допустимо но нецелесообразно
если мне нужен свой класс то я делаю его сам



получаю например такой класс

class GAME_API Heroes
{
private:
UStaticMesh* MeshObj;
FVector location;
FRotator rotation;
public:
Heroes();
~Heroes();
};

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

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

О, безусловно, каждый инструмент нужно использовать по назначению. Именно поэтому мне не нравится наследование контейнера от Actor.
Вопрос - а останутся ли совместимы синьки с такими вот классами? То есть могу ли я часть кода описать в плюсах, а часть в синьке, используя EventGraph? Или, по крайней мере, возможна ли коммуникация между синькой и экземпляром С++ класса? Может ли она содержать переменные с типом этого класса? (К примеру, я не видел в списке доступных типов переменных TMap, вероятно есть какой-то базовый класс, от которого наследуются синьки?).

У вас герои отличаются только именами?
UPD: заходите в чат http://uengine.ru/chat

На данный момент - да.
Потом обрастут мордочками, способностями, характеристиками, отношением с окружающими, и т.д.