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

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

Этот компонент содержит в себе TArray, элементы которого хранят минимум необходимой информации:

1. Идентификатор объекта, в виде GameplayTag. Как я уже говорил ранее, GameplayTag удобнее, чем, скажем, FName, так как существенно снижает риск ошибки.
2. Количество объектов в слоте, заданное переменной int.
3. Категория объекта, чтобы понять как его можно применять. Для этой цели вместо Enum можно использовать GameplayTagsContainer, что позволит нам отнести объект сразу ко множеству типов в случае необходимости.
4. Уникальные свойства объекта, которые храняться в виде структуры из связки GameplayTag и float. Здесь можно хранить как параметры, так и модификаторы.

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

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

Структура взаимодействия инвентаря и базы данных выглядит следующим образом

Уникальные свойства объекта, такие как дополнительные components, и логика без проблем настраиваются средствами С++ и/или Blueprint.

В следующем разделе я покажу как можно подключать созданный компонент к Character или любому другому объекту.

Любая конструктивная критика приветствуется. Желательно подкрепленная предложениями.

P.S. В первые две статьи добавлены поясняющие изображения.