-
The URC check-in dialog occasionally gets stuck behind other windows with no indication until you try to click back into UEFN. The flow goes like this: you press the check-in button, it gathers files to upload, and then nothing appears to happen. In reality, the URC dialog window has opened behind another window. At that point, I’m left waiting for the window to pop up and thinking it’s still gathering files.
(Context: dual-monitor setup) -
Asset editor windows sometimes open in a minimized state. While I know the workaround, a new UEFN user would have no idea what is happening. The flow goes like this: you double-click a material to open it for editing, the window opens in a minimized state, then you have to hover over UEFN in the taskbar, right-click the minimized window, and click maximize. A new user would run into this problem and immediately assume the editor is broken. I personally spent over an hour trying to figure out why this was happening and how to fix it.
(Context: dual-monitor setup) -
Rapid iteration seems almost impossible. Especially with Scene Graph, any value you edit requires a full push before you can see the changes. I understand Scene Graph is still in its early phase, but how long into development are promised features going to remain sidelined? Part of the whole appeal of Fortnite Creative 2.0 was live editing, yet there are very limited cases where UEFN can actually push those changes to Fortnite. This is especially frustrating in larger projects. When editing a single number results in a 15- to 20-minute push, it becomes almost unacceptable. In a space competing with Roblox, S&Box, and even Unity, UEFN ends up at the bottom of the leaderboard for rapid iteration.
-
Learning experience. My learning experience with UEFN was very tedious and largely self-taught. The Verse API documentation is lacking in useful information. If you want to understand what variables a certain class contains or what its methods do, you often have a better chance exploring the digest files and reading the comments there. The API docs seem to present only the bare minimum. If you compare this to the Unity C# API documentation, Unity provides descriptions for each variable, descriptions of what functions do, and sometimes tutorials directly embedded in the webpage, along with copyable usage examples.
-
Asset imports. A change to the asset import window has disrupted workflow. Before the change, you could import FBX files with their materials if everything was set up properly in the 3D editor you exported from. Now, the only option creates material instances off an internal Epic material. This is especially detrimental for models with many material slots. No matter what you do, you have to individually set up each material and replace each material instance if you allowed the importer to create them. On top of this, there is also a crash caused by trying to reimport or reimport with a new file for 3D models. This means you have to import an entirely new model and manually replace references before deleting the original.
-
Skeletal mesh workflow. This has been a very consistent pain point. The main problem I face when importing a skeletal mesh is scaling issues. Almost every time I import a skeletal mesh, it comes in at either 100x scale or 0.01x scale, and only rarely at the correct size. It is especially confusing when you export a static mesh and a skeletal mesh of the same size and scale from your 3D editing software, but they import with different results. Sometimes the skeletal mesh imports at the correct scale, but the animations are at the wrong scale. Sometimes I export a model with dozens of animations, but the import only detects one, with no explanation or debugging method other than repeatedly trying different export and import settings.
-
Fortnite devices. In some cases, functionality can only be delegated to a Fortnite device. One of those cases is cameras. Let’s say I want to make a ball-roller game. I make a script that moves a creative prop to follow a ball I’m controlling. I then use an orbit camera device and have it focus on the creative prop following the ball. So far, so good. Then I want the ball to roll relative to the camera’s local axis. GetViewRotation() returns the player’s camera rotation, not the orbit camera currently added to that player’s camera stack, so it always produces the wrong axis for natural ball movement. There are no good options for getting around this smoothly.
-
Choppiness in positional updating. The best option I have found for smooth transform updates has been using physics tick events and directly setting the GlobalTransform. Even that still has some choppiness. For updating creative_props or devices, the available options of MoveTo and TeleportTo both have unavoidable stutter. I’ve tried many combinations of loop setups, adjusted tick speeds, and experimented with racing and syncing. Everything I’ve tried still has some amount of stutter. Even keyframed movement animations have this choppiness when you attempt to create dynamic animation. I’m not sure whether this is due to gaps in my own knowledge, but it seems to be a consistent problem across many developers, and there are very few examples of truly smooth movement on the platform that do not desync or lag. This is a crucial piece of game creation. Without movement, you barely have a game. Another issue is the need for many moving objects. Currently, if you try to move 100+ objects, performance drops into a slideshow. Some may say that is too much, but what if the player is represented by a moving object and your game needs to support 100 players? In other engines, this is not a problem. Logically, it seems like UEFN should be able to handle it, especially compared to 100 players moving around in BR mode.
-
Inconsistent settings (persistence, movement settings, lighting, etc.). I’ll start with movement settings. Currently, you can set player speed in Island Settings, the Team Settings & Inventory device, the Class Designer device, the Player Movement device, the Movement Modulator device, and the Gameplay Controls devices. With all of these different methods of setting player speed, it is hard to tell what takes priority. Lighting is another example. You can configure lighting in Island Settings, the Day Sequence device, the Time of Day slider in the editor, and the Environment Light Rig device. Again, it is difficult to tell which settings end up taking priority. This sometimes results in the level looking one way in the editor and another way in-game. Another issue is inconsistency across different devices and graphics settings. In some cases, you can have pitch-black darkness on high settings, while mobile looks like daytime. The final inconsistency is persistence. For Verse persistence, testing on private codes and playtest codes sometimes carries over data from the published version, sometimes it uses data from the private code or playtest, and sometimes it has no data at all. This leads to unnecessary panic: did I break persistence on my map? Is this unpublishable now? Then there are all the different devices that can store their state in a separate persistence system that Verse cannot control, and which can only be reset from a button in the pause menu if you have the option enabled in Island Settings to allow players to reset persistence.
-
Lack of per-player control (movement settings, visual desync for per-player options). I’ve run into this problem several times during my experience with UEFN. The basic idea is that you have an achievements display, and you want each player to see their own custom version, where one achievement can be toggled on for one player but off for another. My first attempt used cinematics played per player. From what I remember, that fell apart for join-in-progress players. My next attempt used switches. These had the option to TurnOn() or TurnOff() per agent, but no option for SetState() per player. The problem was that I needed the player to be able to interact and trigger TurnedOnEvent, while also needing to set the switch state on load through Verse. I couldn’t use TurnOn() for a player because it would also fire the tied event. My most recent attempt used Scene Graph and the SetPresentableTo function. This seemed the most promising until I started noticing join-in-progress problems again. A player who joined late would not consistently get the correct entities presented. Another issue is the lack of per-player settings in general. If I want one player to have admin abilities like flying and invincibility, the only way to achieve that is through team or class settings devices. That causes complications if your game requires all players to stay on one team or in one class. Or if you want a player to be able to toggle flight or invincibility, you would need a matrix of teams or classes to account for every on/off combination, then assign the player to the correct team or class based on that matrix. That is ridiculous.