A Talk about the current state and implementation decisions of Scene Graph Items

[Sprintermax]

I am a little sad about the custom inventory and items that was presented to us, and how it was done/implemented.
In short, what was released was basically just a “bridge” so they can make old systems (existing items, game systems and actor-based stuff) compatible with scene graph tech, and also making the custom SG items compatible with old systems for backward compatibility.
While I understand the reasons why they choose this approach, I believe that it can be evasive and limiting long term if we want to use the provided itemization API (Besides in the future we being able to create this from scratch ourselves).

---

To be honest, I was already aware of how custom items were supposed to work already on lots of updates ago (I keep track of internal digest changes on each game update), so how the implementation was intended to work was not a mystery at all and I even had written example pseudo-codes with friends many months before its actual experimental release.

That being said, since some time was past after the experimental release, I think it should be time for me to comment about the topic:

The Problem:

Fortnite has lots of “blueprint items” that was carried for the entire game lifetime. These items are not compatible with Scene Graph, and recreating all these thousands of items with new APIs and functionality from scratch would take much time (developing new tech needed, interactions, functionality, time spent, interfaces, keybinds and so on). This is absurdly unpractical to do, at least on short term.

What they did:

To “address” that problem, and keep support of old non-SG item/inventory systems, they choosed to create the “Itemization” module for SG (part of UE and Fortnite modules).
But all the utility provided by this module is nothing more to provide the “bridge” between old blueprint/hardcoded tech and the new Scene Graph, so creators could keep using old items “without issues”.

Some examples of this are:

• fort_item_pickup_component => This is to “bridge” old items tech actor on world (as the name says, the pickup logic, including the interface, interaction, animation and so on)

• item_component => Don’t need to exist at all (at least I could not find a obvious reason for), but needing to exist just to be able to interact with the custom inventory_component they made on the Itemization module

• item_details_component and item_icon_component => To “bridge” with old items tech providing data-driven details, such as having a hardcoded place where the internal systems can “look” the icon and text data to display on interfaces

• item_category => Also only needed to exist to provide existing old hardcoded sytems the rules (such as pickaxe slot, traps, ammo, and even creative phone during edit mode)

• inventory_component => Only needed to exist to be able to use as bridge to hardcoded data definitions and internal old systems/logic, such as attaching to non exposed game rules, input mappings and so on…

• fort_inventory_component and fort_inventory_XXXX_component => Subclasses of base inventory, specifically made for fortnite internal systems, also with the reason of providing hardcoded data driven and/or compatibility with old systems and logic (such as the base game config and container data)

• Itemization Configuration Asset => This is the “root” itemization configuration on the experience, when the island is set to use one, it will replace the old items config (quickbar/inv screens and keybinds) with the custom data-driven configuration defined inside the asset.
  While I believe that we will be able to make our own variants of this asset on the future, this is still just another way they made to bridge old tech to the new itemization system in a hardcoded way (also explaining the need of other components above to link on internal systems).

These same rules also applies to unreleased/internal components:

• item_ability_component, item_attributes_component, item_rarity_component, item_type_component => All these just exist to provide bridges to non-SG tech, such as data-driven “where to look for this data” on non existing systems (for example to display item info on UI).

---

­Basically all this were already possible before. The current provided Itemization API is just wacky workarounds with basically no new features.
Inventories are basically just container classes that holds data and interactions written in logic directly on code, other components that are also data-only we can make it all from scratch. The same with item definitions itself (both inside inventories or dropped on the world), we could do that from scratch by using other provided components, such as interactable_component for example.
­
While I understand the needs of this design choice on short term, I still think that the showcased state of custom items were made as an excuse like “implement items as fast as possible” while other proper scene graph tech and editor utility is not finished, or not ready for the public yet to make itemization in a better way.

---

The real utility to make custom items that were not possible before was not given at all, this include already planned unreleased features and future components tech, some examples are:

• screen_space_ui_display_component => Used to render a UI on player screen, but anchored to a world position (to recreate the fort_item_pickup_component interface)

• presentation_component and replication_component => Used to define custom replication and visibility rules (ex. make item visible or interactive to only certain players)

• item_attachment_component => Used to attach entities in a specific way (such as to bones or sockets of a skeletal mesh, like to make player “hold” the item). This is also not even something that is item exclusive functionality, for example, the component could have been named just attachment_component and being part of the core tech instead of itemization tech.

• item_owner_pose_modifier_component => Used to provide modifiers to the player current pose while holding or having the item. This is also not needed to be related to itemization, should be part of core functionality to assign custom poses to the player regardless of being items or not. This is one of the most important tech needed to make new gameplay (together with other future planned tech such as skeletal mesh components and animation sequences)

• Property Interfaces => Data Assets to provide data-driven functionality between UMG Widgets and Verse, allowing more complex, detailed and powerful interfaces being made (since widgets in verse don’t have all properties and functionality that the same widgets in UMG has). This is used for everything needed, from the in-world pickup UI, to the Quickbar, Specific Item Details (such as durability and cooldown), Entire Inventories and other HUD screens as the developer need and/or want.

• Input Mapping Contexts and Input Actions => This is to manage player input (such as keybinds, values, priority and per-platform rules), providing the interaction that can be used in verse to make anything wanted (user interface shortcut for buttons, ability keybinds for items and so on). Currently we have some VERY limited epic-curated actions and mappings, without possibility of modifying, disabling, making new ones or even configuring priority. This is also one of the most important tech to make custom items and abilities possible.

• Any data-only component (such as item icon, item details, rarity, type, attributes) can already be made by just making our own simple component to hold it, or even attaching the data somewhere else outside a component! The same for other functional behaviors such as attaching input mappings for example.

Again, basically all of the current Itemization API is just to provide internal bridges with old tech in a unflexible hardcoded way.

With the combination of the components and tech listed above (all mentioned already exist but is internal or unfinished), we could basically recreate the entire Itemization modules from scratch! And even better: we would not be limited by the current problems of itemization, such as relying on epic adding fields and customization for properties or functionality (One example is: we can’t change how the pickup popup ui looks, gravity and anims).

---

With the current state and how it was implemented, we will always be relying on epic providing the functionality or exposing more things to interact with the internal/hardcoded API…
Sure, Epic can improve the itemization module over time, adding more flexibility and features, but it would still be on Epic hands, instead of being on creators hand (which is totally possible), where epic could have provided only the necessary hardcoded data on their part (such as existing items and native fortnite inventories), instead of making the entire itemization tech relying on their own “core module” for all creator implementations of it even when not needed.

Don’t get me wrong, I am not talking that epic providing templates or a guide on how to make custom items are useless, but it could be done completely differently while also being more flexible. I understand the needs to keep support to old existing items/weapons, but making the entire scene graph itemization as a bridge for the old stuff was not a good thing for flexibility, and some details seems to even go against what scene graph promises…
Would be much better to just finish these mentioned internal components, and giving examples using them to build the custom items and inventories with it, instead of doing all the wacky workaround for backwards compatibility that could have been done in other less intrusive ways.

---

Obviously, in the future we could also do our own itemization module from scratch if we wanted (like using the components mentioned), but that would lead to more and more problems due to incompatibility with the epic given itemization, fragmentation of the functionality and more side effects of that decision later on.

If we compare with Creative 1.0 Devices, we have not received entities/components with the hardcoded devices functionality, as epic plans to deprecate the current actor devices over time and port the functionality to their own core engine components in the future so we can make it from scratch (While epic also can provide templates and examples of devices if wanted). Why they have done it differently with items, in a even more intrusive way?
They also removed the bridge_component which was available before (A component that allowed us to attach blueprint actors as child of scene graph entities), with the exact same excuse that bridging actors and blueprint functionality was not in fit with scene graph design desicions on long term and they did not wanted to push that usage.

---

The same can be thought about backwards compatibility of items: Instead of making hardcoded api to bridge them, why not doing the inverse? Such as working on new necessary tech/components mentioned to make the core functionality. And, to add support for old blueprint items while not ported to scene graph, we could have other alternatives such as making all fort items classes in verse holding interfaces with the item details on it (such as icon, name, category, durability and so on).

This way we could read the item data from the old system if we want to make it work with new systems made by ourselves, not needing any of the “bridge” related tech on core SG functionality, and only having the exposed items and its data, even being able to be something like /Fortnite.com//Temporary/Itemization to be deprecated on the future if wanted…
This would be fine to epic having the hardcoded functionality related to backwards compatibility to blueprint items, while still providing the flexibility of allowing creators decide how they want to design their items, inventories and which features/usability these can have.
The existing “core tech” of item_component, inventory_component and related utility could have just been a example/template project with the implementation in raw “user written” verse to be reused across projects.

---

Conclusion: While I understand most of the reasons behind lots of these decisions, I think that the current implementation can cause a chain-reaction as time goes on, due to the core tech being ruled by internal epic-driven functionality instead of relying on non internal implementations (such as only bridging the items itself). The current state has lots of room to improve, limitations to address, and I think that if epic communicated better with what developers expect before deciding the priority or design of some features, it would be much better for the future of the platform.

For example, if someone asked me if I prefered “itemization template module” sg tech, or the unfinished components that I listed above, I would have answered that I prefered the components mentioned, since they were providing more powerful usage cases, and would also cover custom raw implementation of basically all needed custom items (and even weapons) functionality.

[Sprintermax]

I started this talk so we can discuss and talk about the implementation, suggestions and use cases to give feedback to epic.

I know this topic about the design choices is a double edge sword: Some creators want easy-to-use preset APIs/Templates.
While this is good for most people, it would be the opposite and very bad for the experienced or more technical users. And I also think that with different implementations would be possible to make it better for both general and technical creators (such as letting the developer of a team making the easy-use of their own itemization design, community sharing it online as snippets, or even epic making project templates like they did with other feature examples).

So, feel free to anyone who want to discuss about this topic, to give more details or feedback to my texts above, I would love to see what other people may think about what I said and possible new ideas related to the current scene graph itemization in general.

[Sprintermax]

We will be able to make our own itemization from scrach in the near future based on some extra components (some of it is even already possible for a while).

BUT, that would add more problems like I mentioned: we would need to do the communication between two different itemization modules (our own and epic provided), migrating data, usability, inventory management, keybinds and so on… This will lead to much more work, prone to more bugs, and at the end would not be needed at all if the Epic implementation were a little different…

---

I don’t know what exactly would be the best alternative, but when I saw how it was currently done, I thought about something like a fort_item_component, where on that component having all the data related to the items (such as icon, stats, name), even being able to be on interfaces if wanted (has_icon, has_description)… This would allow access to old blueprint items data while they have not been migrated to scene graph yet (functionality rewritten as components and behaviors).

That’s why I said it could even be a Temporary module, if they want to deprecate or update in the future… This way the “bridge” stays only on the old blueprint items, and not on the core scene graph api, and much less on user made implementations and design choices of inventories/items.

For example, if epic wanted to make a itemization module, nothing would prevent them of doing it as a snippet template with the same inventories and items setup, posting on forums or example projects, like they did before… Would be much more flexible, and at the end, still optional (the developer can chosoe if want to follow epic template or make one by its own)

---

The itemization core module (base item and inventory related stuff) are part of the /UnrealEngine.com/ module, and only some stuff are part of the /Fortnite.com/ module… This means that they planned to use that same itemization on the entire Unreal Engine, and not only in Fortnite to cover these old blueprint item bridges…

In normal UE is not even a much big problem. Since a game developer will make its own game from scracth, nothing would prevent him from ignoring the unreal engine itemization entirely, and making and using his own itemization from scratch… That would not cause problems since his game would not need to even touch the itemization provided by the engine at all if he don’t want.

The same thing does not happen with Fortnite: since they are forcing that module and that specific implementation with existing/old items, we UEFN creators will be always forced to use that module (regardless of we making our own or not). Unless we completely ignore all thousands of existing fortnite items on our projects, there is no much flexibility at all on the current implementation.

This is why I said that the implementation may have been planned a little different, It was also added as a non Temporary module, which means that this is the final/end product design they planned, instead of just a temp workaround while fortnite items are still blueprint based…

---

The accessibility and prebuild tools are a huge discussion topic (not only about items but anything on the ecossystem). But, for custom items and inventories, like I said, nothing would prevent the same modules they made from being published as templates and snippets instead of hardcoded core functionality, giving freedom to experienced users while also covering default implementations and starting-points for beginners to use.

This is specifically due to most itemization functionality (the already released part) being data-only containers and interactions/functions on the code, (not needing core functionality on the engine part). And even some of the “core” functionality, it is already planned in their own components or future SG designs that is more flexible than the current usage, so the itemization could have been just a /Fortnite.com/Temporary/Itemization/ to bridge old fortnite item data, instead of a full implementation on the engine module level…

---

Some stuff also seems off, for example, they implemented a failure_reason class but it is submodule of itemization, that is a thing that should be core unreal or even core verse, since it can be used for non item implementations if we want (as the class name implies, it defines a generic failure reason data/container)…

[Sprintermax]

If I was tasked to make the api design with backsupport, I would have done some stuff very differently (even if it means waiting a bit more time, specifically for stuff like other components I mentioned that need to be released)

What I would do would be something like:

• Remove /UnrealEngine.com/Itemization module entirely (Most stuff here would be moved to /Fortnite.com/Temporary/Itemization or written as template code later)

• Add all bridging functionality on Fortnite module, as temporary (if we want to deprecate in the future, ex. when converting item behaviors/functionality to scene graph) (Something like the example attached as file):

• Make Snippets on Epic Forums, or a Project Template with example implementation of custom items and inventories. These snippets/project would have itemization logic written from scratch in verse (since all interactions are data-only on the code, basically making here the base inventory_component and item_component with its other interactions/functionality).
  ­
  If made on a project template, could also give more examples such as reading existing Fortnite items data to display and how to manage it. And in the future this could add examples of managing input actions to open inventory screens, change quickbars, item powerups/cooldowns, in-world interact popups, inventory blueprint widgets with property interface examples and so on… All being much more flexible for customization and adaptability since all would be non-hardcoded modifiable code.

• Rethink lots of the internal (currently unreleased) itemization related components. As explained, lots of things are just data only for bridging, that could be placed on its own fortnite exclusive module instead of core unreal engine module, or even avoid them entirely

---

On Island Settings, an option “Initial Inventory Configuration”, with being able to select between:

• “NativeOnly” → Keep existing Creative/UEFN configs (Inv/Quickbar UIs, Input Mappings, Keybinds), with limited functionality (would not be able to handle custom user made items)

• “Blank” → Completely empty (no Input Keybinds, no Default UIs at all), the user would need to make everything from scratch if wanted. (Most of it is already possible, but some such as input mappings and property interfaces are still unreleased)

• “Custom” → A configuration where you can map your custom itemization module data to existing native fortnite UIs, could also expose some data driven config for inventory UI with view models and keybinds, but the core functionality being already implemented. (Part of this is already done by the Inventory Configuration Asset, just is not fully exposed to us)

Notes:

• Currently, if we left the Inventory Configuration ‘blank’ on slot settings (no asset set at all), it acts as the “NativeOnly” mentioned above (Native Inv Widgets, sg custom items don’t work/show up, native UIs are shown, only old fort items work).
• If we set it to the “Empty Preset” asset, player will not have any inventories, but still has the input mappings to navigate quickbar and open inv (Itemization Inv Widgets, no default inventory, both fortnite old items and scene graph custom items work after adding inventories ourselves).
• If we set to the “BRStyle” Preset, is the same as Empty preset, but with default inventories already applied (we don’t need to apply manually)

---

This is an example of what I was thinking about scoping the “bridge” functionality to the fortnite module only:

# Fortnite.digest.verse
Temporary<public> := module:
    Itemization<public> := module:
        fort_item_component<native><public> := class<epic_internal><final_super>(component):
        
        fort_item_details_component<native><public> := class<epic_internal><final_super>(component, has_description):
        fort_item_icon_component<native><public> := class<final_super>(component, has_icon):
        ... # Other Fort Item Data Bridge Components so we can read the values if we want
    
        FortniteItemCategories<public> := module:
            fort_item_category<native><public> := class<castable><concrete><unique><final>:

            WorldItem<public>:fort_item_category
            Ammo<public>:fort_item_category
            Trap<public>:fort_item_category
            ... # Other hardcoded categories
        
        AbsoluteDoomItems<public> := module:
            fort_item_chainsaw<public> := class<final>(entity):
            fort_item_modular_sovereign_shotgun_legendary<public> := class<final>(entity):
            ... # Other Items from this season
        ... # Other Modules With Other Seasons Items


    NativeInventory<public> := module:
        fort_inventory_component<native><public> := class<epic_internal><final_super>(component):
            # Adds items to the inventory. Fails if items don't have `fort_item_component`.
            AddItem<native><final><public>(Item:entity, ?AllowMergeItems:logic = external {}, ?AllowPartialItemMove:logic = external {})<transacts><decides>:void
            ... # Rest of Native Inventory API (Find, Get Items, Rules and so on...)

        fort_inventory_weapon_hotbar_component<native><public> := class<epic_internal><final_super>(fort_inventory_component):
        fort_inventory_trap_component<native><public> := class<epic_internal><final_super>(fort_inventory_component):
        ... # Other Hardcoded Inventories

        ... # Rest of Native Inventory API (Classes, Events, so on...)

[Sprintermax]

This is one example of the side effects due to bridging blueprint items under the hood:

Lunalotl

[Sprintermax]

When item entities gets “picked up”, they get removed from world (level_entity that is on round_lifetime_simulation_entity), and added to inventory_root_entity (that is on game_lifetime_simulation_entity)

This leads to weird behaviors that we can’t control, such as:

• The entities cycle their lifecycles (of all components) even if we don’t want that happening (Stop and Start simulation again)
• Item.GetSimulationEntity[] returns different simulation entities while on world or inventory (round and game sim entities)
• Wacky interactions related to the attachment changes
• Modifies the scene tree without giving us a way to control or even customize it
• Expose access to the game_lifetime_simulation_entity, that I believe is not intendeed at all (we have filters on the engine to prevent getting it from the normal level_entity and round_lifetime_simulation_entity, but seems that this filter does not exist or are not working with inventory_root entity since it is already outside the round lifetime entity)

---

This is some parts of the scene tree from my testing project:

Note how the inventory root is structured on a running game (I was alone in the session, but I believe when other players joins, other inventory roots get generated)

Also, we need to rely on lots of undocummented behavior, basically needing to do “reverse engineering” to know how the implementation works in details, both to understand its concepts, to use it properly, or even just avoid possible bugs related to the design and/or usage…

This is the type of things that should be documented, even if not finished or subject to change, so creators don’t get lost while using the experimental features (and consequently leading to wrong bug reports, invalid feedbacks, or even just difficulting usage and learning). Don’t need to be in deep details, just simple notes are already enough, such as “item entities also simulate while inside inventories”, “they get removed from world but they don’t get removed from the scene”

(extra note: I may have explained wrong the functionality of screen_space_ui_display_component on my first post, sorry! The functionality of it is a bit different from what I said. But there is other ui related components internally with different purposes)

[Sprintermax]

I made the following test setup:

These are the results of the 3 tests made:

---

It leaded to inconsistent behaviors (outside and inside the scene), data loss when splitting stacks, wrong descriptions on the digest, and lack of flexibility or customization.

Due to this, would not be better to let us create the new stack instances and data ourselves, like we already always need to do? mesh_components, materials, entities itself and any other class, we always needed to create new instances of it ourselves, then copying the data manually field by field. The ItemComponent.Take[] seems redundant related to that

---

All this, chained with more non documented scene tree implementation details, is only accumulating more and more questions over time, at the point of us verse devs spending more time trying to undestand how it works than actually developing systems and new content…

[AlexThomProd (Epic_Alex)]

Hiya Sprintermax

That is a comprehensive thread! Perhaps we can chat more about the specifics later, but first I can hopefully provide some high-level context.

The purpose of the Custom Items and Inventories feature (the Itemization module) is to provide a foundation for items and inventories inside any Verse platform, not just Fortnite. It does that by defining a new set of components, such as inventory components and the various item components. These are foundational parts we are building underneath Fortnite, not bridges across to it.

Many existing systems have been updated to use these components, and even existing items provide access via them. The important part is that we are now building on those new components, not the old.

Over time, the functionality in the new components will supplant the current system. This cannot be done just in the Fortnite parts of the code, as we don’t want to limit these features solely to Fortnite.

We are still developing and testing components beyond those publicly available, with an aim to provide all the pieces need to easily make a typical item. It’s also important to us to provide enough power in the API so that anyone could write similar components, without requiring special Epic powers. We know we’re not there yet in the first experimental release. Also bear in mind that some of the things you have seen in the digest might not ever be made public.

The aim of the experimental features program is to give better visibility to the direction of our APIs to you sooner. We are really grateful for the feedback on the early view of this.

Lastly, additional documentation and examples should begin to appear over the next few days. We completely understand the value of these!

[JDV (Jean-David)]

Just wanted to post to echo Alex’s thoughts and say thanks! Really appreciate the detailed feedback as we continue to develop Itemization!