UEFN Development Considerations - authors & Epic alike

Development Getting Started & Setup
, ,
1

It can help to remember a number of considerations while authoring projects in UEFN and to have a bit of a peek of the Epic development process and how we handle bugs and enhancements.

UEFN has a number of constraints that both Epic and UEFN authors have to keep in mind:

  • projects run inside the Fortnite application - on cloud servers - so UEFN projects can only be made up of commands and assets that can be changed dynamically (you can’t compile C++ code such as with a Unreal Engine project for example)

  • some features have client-side aspects which generally must run on all platforms: consoles, mobile, desktop

  • most updates to UEFN require updates to Fortnite (both the Fortnite servers and the Fortnite clients) and often updates to UEFN itself (the editor app for authoring) and sometimes plugins for VS Code such as the Verse extension and often assets used by such updates

  • Security and privacy are critical - fixes or new features in these areas have a lot of additional scrutiny and legal oversight

  • many of the systems and assets in Fortnite were expected to always be on and in memory when they were originally designed - the process of making them optional or dynamic is very tricky and there are often performance costs when doing so

  • UEFN projects are a stepping stone towards a big ecosystem of experiences in a metaverse (all projects living together with shared users, features and content) - which has a bunch of unique considerations that an Unreal project (as an example) might not need to worry about

  • UEFN and its ecosystem is still new - we’ve only scratched the surface of what we hope to provide and everything is still evolving

Many features already exist from Unreal, Fortnite or Blueprints though none of those systems had these constraints and considerations in mind when they were created. Sometimes we can adapt - like programmer archaeologists - though often they need to be reworked for the UEFN ecosystem. This is one of the key reasons that we can’t just use Blueprints within UEFN - it breaks too many of the considerations above.

Growing pains and bugs

There are a crazy number of systems that interact in basically infinite ways - which is cool when authoring, though a nightmare when trying to find if different features negatively interact with each other. We also have different timeframes for testing features - sometimes we test a feature and it is great at the time but conflicts etc. arise over time. This was especially the case with the first few updates of the UEFN Beta - some of the features were written years before and had become stale by the release.

The only way that Epic can get as much out the door as we do is by doing things in parallel. We have many teams with different systems, features and priorities. Many teams and even people on the same teams are spread out across multiple time zones. It is literally impossible for any one person - or team for that matter - to know all the bits of UEFN at once.

We do unit and regression testing, though some things are missed - especially knowing which combination of tests are needed. A, B, X, Y all work fine on their own - A and B are tested together and X and Y are tested together though we don’t realize that A needs to be tested with system Rutabaga and X needs to be tested with system Hyper Intelligent Shade of Blue. We are working hard at creating more tests and more test systems and more combinations of tests for every change. It is a ridiculously complicated problem - though we are chipping away at it and it will continually get better.

Getting bugs fixed

Bug fixes tend to be prioritized over new features - it might just not appear that way. It can be horrible to make features on top of bugs - better to get them fixed as soon as possible - not to mention that users want working and not buggy features.

Features and fixes are usually made long before any update / release is made available to the public. If we are made aware of a bug, fix it, test it, retest it (again and again), then submit it for a future update - the actual update where the public can see it can be a fair time in the future (months). I say tend to be prioritized because some bugs are hard to reproduce, some we just don’t know an easy fix and some are on top of tech that is in the process of being significantly reworked - so it makes sense to fix the bug after the rework sometimes.

Feedback - bug discovery and evolution

The UEFN community letting us know about bugs - and areas of friction, pain and needs too - are critical to making UEFN better. Sometimes a user will just use a feature that hadn’t been used for a while or do some combination that just perfectly sets off an explosion that Epic isn’t aware about. Sometimes we know very well that something is broken though hearing people raise it as an issue helps us know to prioritize fixing or making something better over some other thing that we are doing.

At Epic we do UEFN game jams and have started a few internal projects that are entirely within UEFN as a means to discover friction / pain points and a way to test features and discover bits that are missing. Fortnite and Unreal share ever more aspects and systems with UEFN.

We are often frustrated that some of the features and systems take longer than we would like to get out the door. And similarly as we use the tools and APIs ourselves we also feel the odd bits of friction and pain points. We want awesome tools too.

We are trying to get more and more Epic developers engaging here in the forums - like me. It can be hard since most of us are heads down and working away on this crazy stuff. Likewise we are working on yet more documentation and videos.

The content that the community is making - projects, guides, forum interaction, example content, videos, etc. - is awesome!

Rewards

UEFN authoring can be challenging with these initial growing pains though there are very real benefits even today - here are two key ones:

1920×1080 118 KB

  • Creator Economy 2.0 - 40% of net revenue from Fortnite is spread out amongst projects based on player engagement - https://create.fortnite.com/news/fortnite-engagement-payout-update

  • publishing projects directly and simultaneously to Windows PC, Sony PlayStation 4&5, Microsoft Xbox One / Series X|S, Nintendo Switch, Android and Cloud streaming. Try to do that quickly or easily with Unreal or other game authoring systems.

Epic has a philosophy of empowering people to make their own amazing ideas and I think that philosophy is shared by the people working here. Just speaking for myself - I wanted to make games, saw how terrible the tools were and started to make better tools - and I just never stopped.

If we keep the criticisms constructive and specific we can use that info to make things for UEFN / Creative 2.0 better and better.

We’ve been blown away with the projects that we’ve seen so far!

18 Likes
3

Thank you so much for this insight. Posts like this are so useful to help people understand why the bug they reported 10 seconds ago isn’t immediately fixed.

3 Likes
4

I’m relieved to know that you feel our pain! :joy:

Actually it’s good that you cleared these points out, go Epic!

1 Like
5

Thanks for giving such a clear and detailed background around how features, bugs and updates are tackled! :purple_heart:

To reiterate what @X_TyFighter_X said, I think a lot of gamers expect that when they raise a bug there’s just one person on the receiving end of that bug and who can then ‘just go and solve it’ whereas in reality it’s a complex multi-team multi-process endeavour.

On that note, I do think a confirmation email from a noreply address would go a long way to appease some of those who are frustrated, as I’ve seen many of them essentially comparing the form to shouting into the void.
Raise bug using bug report form > Email auto-response states something like:

"Thank you for raising this bug!

We have received your report and will start the appropriate internal process.
If this is a bug that has already been raised, we will add your report details to it.

Please note that bugs take time to resolve, and go through rigorous internal testing, so their public resolution may be weeks or months after you have submitted them.

Thank you again, please feel free to submit other bugs that you encounter, your feedback is important to us!

Stay Epic,
Epic Games Development Team"

As a fellow dev it’s interesting to hear about the intricate dependencies involved, and I do not envy anyone having to untangle something as massive as UE/UEFN/Fortnite compatibilities and inter-dependencies :smiley_cat:

2 Likes
6

I was excited for UEFN updates but they are an absolute disaster for complex maps. Discovery algorithm is ruthless. Few hours of map being broken makes average playtime drop quickly.

Here’s an example of amount of plays on one map:

lumber
lumber1435×637 36.9 KB

On 06/11, we’ve released an update that increased playtime by 20%. It took a week for the map to recover but then 25.10 came and introduced even more bugs including complete Verse crash when any player joins mid-progress.

There’s no place for complex UEFN maps in this unstable environment. We need:

  • A way to test our maps before FN updates are released
  • An option to make maps completely hidden and inaccessible when updates break them to not hurt their stats (playtime/retention)
    Current “unlisted” function still allows to play them with their map code.
4 Likes
7

Agreed - a confirmations are important. Also note that bug reports come in from many locations: forums, Twitter, internal at Epic, Discord, etc.

Sometimes I’ve seen an issue raised in one place and it seems to have crickets for a response and if I investigate I can find a whole task team of 30 people working on the issue with a dedicated communication hub at Epic. They may have responded to one place that reported the issue and not be aware of others reporting the same issue.

If you find related issues reported in different locations - please cross post to link them together.

1 Like
8

These are good ideas and they’ve also been discussed internally at Epic.

Having an overlapping pre-release may be possible though there are huge logistics to get in place before that occurs. More regression tests will help too. We could regression test internal Epic maps and even user maps.

More user control of maps would definitely be good.

2 Likes
9

The feeling of UEFN for us is: we need to have very meticulous development processes in order to debug efficiently, because when issues arise, they become very stressful pain points due to the novelty of the ecosystem.

As a general rule, we explore new boundaries one at a time, and if we encounter a problem we can’t solve, we try to focus on documenting it and preparing the information as best as we can to help you help us.

It’s important to keep in mind that this is just the beginning, there aren’t years of community experience to draw from (apart of creative 1.0). It’s not as common to find your same error reported by another person on the forum, some of the issues we face in UEFN are “new”, and you might often be the first one to encounter them.

That said, we appreciate the vision, it’s something our team takes into account, thank you for the opportunity and keep up the good work!

2 Likes
10

Thanks for responding. Looking forward to see improvements in these areas.

About:

I’m not sure if you are aware but there’s a big difference between test sessions (Launch Session in UEFN) and private/public servers (accessing a map with a code, can be unpublished). The latter has a lot more bugs and crashes. The only explanation I can think of is that they are less tested so if possible please let everyone know to use them more for internal projects/tests (in UEFN: Project->Upload to Private Version and use code to join the map).

11

Hi Conan,

I think that UEFN is a very interesting opportunity for creatives and I would know a bit more about it:

-What kind of games is possible to make inside it nowadays?

-Do you think, according to Epic´s plan too, that in the next 2-3 years will be possible to create in UEFN an action game from the scratch (ideally a “new” Gears of War) or even completely other genres (such as a Tower Defense game or an RPG…)
Is it likely to happen in the future?

12

Just saw this post now. It’s really helpful to hear all of this we all live inside our own echo chamber so it’s good to hear how things are going from Epic’s side.

I do agree that there should be a way for us to turn off our published maps so when new bugs are introduced we can keep players from playing in them. It’s painful for us to see our map being played in a very unplayable state especially if they happen to make it to discovery.

And even though I understand that many bugs can be extremely hard to fix, for some of the very large ones that have been affecting many maps, some commutation can go a long way. Even a quick reply stating that Epic is aware of this specific issue and is doing its best to resolve it.

I love reading posts like this as it helps everyone better understand the other sides struggles. I hope that all the Epic employees are enjoying their time off and I’m super excited to be apart of this community.