A big review of the Verse UI and UI problems

General Feedback & Requests
, ,
1

This is going to be a big review for my last two months of working with Verse UI, and since I spent almost two months working with it specifically, I found a huge number of flaws and bugs. At the end of the post you can see what I’ve done and make sure I’ve really spent a lot of time with the UI.

I will immediately ask you to vote in the reports on these bugs, links:

1. Sufficient potential:

UI has enough potential to work with it and write less simple systems, without a lot of graphics. It’s quite enough to make engaging gameplay, but at the same time, we have to come up with a huge amount of “bad” stuff to make it work. We would like to see more attention paid to the verse UI, and UI in general, because appearance is extremely important for players and creating a good gaming experience and a good game cannot be without UI. At the moment, I know a lot of authors who give up on big projects for the following reasons, which will be discussed here.

  1. Stability issue:

    The biggest problem I’ve encountered during my time with Verse UI is stability on controllers. Thinking through the UI takes a lot of effort in itself, but controllers interact very poorly with Verse UI. They require special conditions:

    • Controller focus: this is the biggest problem that creators have and the one I hear about the most. It has been around since the beginning of UEFN and the first report about it was on March 25, 2023 (three day after UEFN was released). Link: Major - Verse UI: Controller issues

      When the UI opens the controller buttons sometimes lose focus automatically and controllers can’t click and do anything, they are left with 2 choices: quit the game in the menu (which completely collapses the play time of the island), or grab a mouse and fix it with the mouse (few controllers have a mouse for such cases and it’s easier for them to quit the game.

      This completely negatively affects the user experience and good islands being worked on can be completely abandoned due to such issues, since we can’t fix it ourselves. It’s much easier for a creator to go make a simple game than to wait for this fix. Just today I researched this bug for about 8 hours and it’s what prompted me to spend a large amount of time writing this review, in hopes that I, as a creator, would be heard.

      However, this problem was not solved and I had to track the player’s click on the UI to understand if this error happened to him or not. In case of error, I just hide the UI, but it takes time to track and it spoils the user experience of the game.

      The same problem occurs due to the carelessness of the creators, as the controller loses focus for several reasons:

      1. If a button is hidden and shown, the controller gets soft-locked.
      2. If the button will be disabled and enabled, the focus will also be lost.
      3. If the button was removed and added to widget, the focus will be lost. In such cases only quit the game or use the mouse.

      You can see examples here: Verse UI's huge un focus problems with controllers - #2 by 2GHSamburskoy

    • UI straightness: buttons that will not be in the same straight line vertically or horizontally cannot be selected on the controller, or rather the controller cannot switch between them. This kills a lot of UI variability, because we have to figure out a way for the controller to get to that button.

      In the screenshot below, I have to position the button so that the controller can reach the character’s stat toggle buttons. Diagonally, he can’t interact with them in any way.

      photo_2024-02-13_23-05-22
      photo_2024-02-13_23-05-221280×720 193 KB

      image
      image1920×960 118 KB

      It’s quite difficult to talk about a nice UI with such limitations, even if I spend a week researching the UI and draw a minimal layout, I’ll hardly be able to implement it without “bad” solutions.

3. Dependence on the Fortnite UI.

We are completely dependent on the implementation of the Fortnite UI and there have already been several precedents when buttons changed and our interfaces broke.

One of these cases was when changing from square buttons to rounded ones, and the second case was when the text was changed to HUGE, which increased the size of the buttons automatically.

For example, I still have artifacts associated with these sizes:

image
image1917×1078 110 KB

We have a solution in the form of custom buttons that can be implemented using the button{} class, but it has one huge drawback: it does not work with controllers. Controllers simply cannot target a button{}.

Fonts and sizes: We are also completely dependent on a single font and the most problematic thing is the size of this font. We cannot change it to a smaller or larger one, which does not allow us to create small interface details that are very necessary. For example, I solve this problem by creating a custom font, but this is extremely inconvenient to do. My skill leveling system is implemented exactly like this:

image
image1264×961 109 KB

And I would not like that in the next update, when the Fortnite UI is changed, that I would completely rewrite the sizes and buttons, I think you understand that this is a huge problem.

  1. Lack of functionality

  • The biggest drawback is the lack of a page scrolling widget, since large lists of UIs and items are based on this. Long dialogues also have to be limited or a huge UI for them must be built, which does not always coincide with several texts in them.
    The inner window scrolling issue can be solved with pages, it’s not that hard to write logic and add pages via stack_box. But this presents an inconvenience to use, since the limitation in round buttons and the size of the button text forces them to be literally HUGE.

  • We cannot control the transparency of the widget, so when we override the transparency of texture_block, we are forced to unload the image, use another program, lower the transparency there, and only then load it back. This causes a lot of inconvenience and, for example, I personally use only color block because of this.

  • Overlaying UI is not possible on top of the standard Fortnite interface unless they are made as input_mode.All. This is also quite critical, because if I want to show an image to the user with a tooltip in the corner of the screen, and there is a Fortnite UI element there, then this cannot be done. It would seem that you could simply remove this element from the game, but it is necessary.

  • As a matter of fact, we cannot hide individual elements for an individual player. Exactly fortnite ui. To hide a separate element, we are forced to add a hd_controller_device, configure it to a team or class with a separate element, transfer the player to a class or team for the duration of display. But this is acceptable if there are not many such elements and you don’t need to combine them, otherwise you simply won’t have enough memory.

2

Things I’ve done with Verse UI, In case anyone has any doubts I’ve done a lot of work with it.


6 Likes
3

Thanks for talking about that, you’re completely right, I’d just like to add those tiny issues if you don’t mind :

  • We can’t make the widget “non hit-testable”, we only have 3 visibility options whereas in the blueprint interface you have 5 options. It causes issues when trying to add an image on top of a button for example.

  • It’s a hassle to animate (and it’s 30fps limited)

  • Calling player_ui.RemoveWidget() should hide the widget directly without having to call widget.SetVisibility(widget_visibility.Hidden) before

  • player_ui.AddWidget() is extremely slow sometimes (up to 5s at game starts for some UIs), can we have a way to cache those ? what are the best practices here ?

  • We need to generate and draw shared widgets on each players individually because 1 widget = 1 player. Shouldn’t we be able to generate the widget a single time and replicate it to all players for better performances ?

2 Likes
4

Of course, I’m just glad you’re describing additional problems.

I completely agree about the animation, although we still use it at some points, but plan to remove it as it is really slow.

Unfortunately setting widget.SetVisibility(widget_visibility.Hidden) on the ui_input_mode.All setting doesn’t return control to the player immediately, so we stopped using it, but it is really slow sometimes.

Have you tried caching using maps rather than building the UI from scratch?

I’ll describe an interesting case I encountered and had to update the maps:

A class has buttons declared.

ui_class := class:
    Buttons : []button_loud = array:
        button_loud{}

The second class uses it in the constructor:
main_class := class:
    UI : ui_class


When the second class is created, the buttons will be the same between all players who will use it.

NewUI := ui_class{}
NewMain := main_class:
    UI := NewUI
2 Likes
5

Oh didn’t know about the visibility thing for interactable widgets, that’s sad…

No I didn’t try this, but I’m not sure generating the UI in a constructor vs in a function does impact performance that much ?

6

The speed will be the same, I to use this option because of my architecture. My point is that you can share the same element between players. I haven’t checked with the same color_blocks for backgrouds, but if you go deep, they use the same reference, so maybe it will be a more performant code.

7

Hey! How did you create a custom font? Trying to do this but apparently ins’t possible to do it even with widget blueprints, as UEFN doesn’t support .ttf or .otf files

8

It’s a per-letter and stack_box job

9

Is this issue with focus still relevant? Any workarounds exists or better to avoid using verse UI with input now?