Summary
Hi Epic team,
We’re developing a UEFN island called StealAnEgg, and our pet collection index has grown into a very large Widget Blueprint (WBP_PetIndex). We’re looking for technical guidance regarding MVVM scalability, performance implications, and recommended architecture before expanding it further.
Current Widget Blueprint statistics:
Approximately 2,800 widgets
Approximately 1,150 Verse fields
Approximately 840 MVVM view bindings
Approximately 490 MVVM view events (button clicks, highlight, and unhighlight events bound to Verse fields)
Asset size: approximately 16 MB (.uasset)
Why we’re using this architecture:
Since ScrollBox functionality is not directly exposed to Verse for dynamically populating Widget Blueprint content, we currently create each pet card manually inside the WBP’s ScrollBox.
Each card requires individual Verse fields and MVVM bindings to manage its data and interactions.
As the collection expands, the number of widgets, bindings, and events continues to grow.
We’ve temporarily stopped adding new collections until we better understand the limitations and potential risks of this approach.
We’re particularly interested in whether this architecture could cause compilation issues, runtime performance degradation, increased memory usage, or problems during cooking and publishing.
We would appreciate guidance on the recommended architecture for large, data-driven UI collections in UEFN.
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
UI/Tools
Steps to Reproduce
Create a Widget Blueprint in UEFN containing a ScrollBox intended to display a large collection of interactive pet cards.
Manually populate the ScrollBox with individual widget elements for each pet entry.
Expose the necessary data and event fields through Verse.
Configure MVVM view bindings to connect Verse fields with the corresponding widget properties.
Configure MVVM view events for button clicks, highlighting, and unhighlighting interactions.
Scale the Widget Blueprint to approximately 2,800 widgets, 1,150 Verse fields, 840 MVVM view bindings, and 490 MVVM view events.
Compile the Widget Blueprint, launch a session, and add the UI to the player’s screen.
Evaluate compilation behavior, UI initialization, memory consumption, and runtime performance.
Expected Result
Large, data-driven UI collections should have a supported and scalable implementation pattern in UEFN.
Ideally, developers should be able to populate scrollable collections dynamically from Verse or through reusable entry widgets and viewmodels, without manually creating hundreds of individual bindings and event connections.
If technical limits exist for Widget Blueprints, MVVM bindings, view events, or Verse fields, we would expect these limitations to be documented or accompanied by clear diagnostics.
We would also like to understand the recommended architecture for maintaining predictable initialization time, memory usage, and runtime performance as collections grow.
Observed Result
Our current implementation requires manually creating and maintaining individual widget elements, Verse fields, and MVVM bindings for each pet entry.
This has resulted in a single Widget Blueprint containing approximately 2,800 widgets, 840 MVVM view bindings, and 490 MVVM view events, with an asset size of approximately 16 MB.
The architecture is becoming increasingly difficult to maintain and expand.
We are not reporting a specific confirmed crash or compilation failure at this stage. However, we do not know whether our current implementation is approaching technical or practical limits within UEFN.
We are concerned about potential performance, compilation, memory, and publishing implications as the number of entries continues to increase.
Platform(s)
Windows PC — Unreal Editor for Fortnite (UEFN), Verse, Widget Blueprints, and MVVM.
Additional Notes
We would particularly appreciate clarification on the following:
- Hard and practical limits
Are there hard or recommended limits for MVVM view bindings, view events, Verse fields, or Field Notify properties within a single Widget Blueprint?
- Runtime performance
What is the runtime cost of hundreds of MVVM bindings and events, particularly regarding widget initialization, memory consumption per instance, and individual field updates?
- Compilation and publishing
Are there known scalability concerns involving Widget Blueprint compilation, generated classes, editor stability, validation, cooking, or island publishing?
- Recommended architecture
What is the recommended way to implement large, data-driven, scrollable collections in UEFN today?
Are approaches such as ListView/TileView with reusable entry widgets, runtime population from Verse, or splitting collections into smaller Widget Blueprints currently supported and recommended?
- Diagnostics and warning signs
Are there any profiling tools, logs, warnings, or metrics we should monitor to identify potential scalability issues before they affect runtime performance or publishing?
Any technical guidance, documentation, or implementation examples would be extremely helpful as we plan our refactor.
Thank you for your support!