Overview

So you’ve had this great idea for a new feature in Unreal Engine. It makes complete sense, will be useful to so many users (but especially yourself), and shouldn’t be too difficult to get up and running for experienced guys like us. Even your friends on the Forums and AnswerHub like it, and yet there has been absolutely no traction for months. So what is going on?

This is a question I am confronted with almost daily, and I often have to cut the answer short. This article attempts to explain in more detail some of the main factors that affect the decision of whether and when a new feature will be implemented in UE4.

Opportunity Cost

Although we’re continuously growing our team (the company’s size has doubled since I joined four years ago) there will always be a shortage of man power. There are many more ideas for new features than we will be able to address in the upcoming years. Shortly after development on Unreal Engine 4 began, we decided to reset our internal issue and task tracking system and moved several thousand entries for feature requests into the graveyard. We figured that, if they are important, they will surface again.

Every time we decide to implement a particular feature, it means that we won’t be able to work on some other. We are also working on several games internally, we need to prepare conferences, support users and licensees, and have various other projects that each compete for as many resources as possible. Even with many developers around the world, the daily struggle for available time slots is very real.

Impact

Besides the never-ending resource constraints we also have to consider the impact that new features may have on existing code and workflows. Unreal Engine is a complex piece of software that consists of many sub-systems interacting with each other in complicated ways. The Engine has organically grown into a well balanced ecosystem, and new features, especially if they are changing established paradigms, have potential to upset this balance. We have a long list of things that we would like to change after what we have learned from using the Engine ourselves on internal game projects every day, but some of these may require extensive changes in the design or implementation of the underlying architecture, and that is something that doesn’t always fit well into the schedule. Not only does the refactoring of code take time, it also increases the likelihood of introducing new bugs.

Long-time users of Unreal Engine are also accustomed to a consistent user experience. There are many common workflows that run like a thread through the entire tool set, and fitting new features into these schemes is not always easy and may require detailed analysis. We try to be careful about throwing off the muscle memory of our artists and game designers, because doing so can easily put the success of a project in jeopardy.

Quality

We are known for the very high quality bar that we impose on ourselves in order to ensure that we keep having the best tools in the game industry. Getting a prototype up and running quickly is very easy, but completing a project and doing it well can be quite difficult. Initial ideas often only scratch the surface of a wider problem area, and a thorough understanding of what we are actually trying to accomplish is needed. Sometimes we defer this responsibility and mark features as experimental, meaning that they are an exploratory effort not yet ready for prime time and likely to change in future releases. Quality is not only determined by how stable and well integrated, but also on how well rounded and complete a feature is.

Yesterday I quickly put together a plug-in that allows users to store text and personal notes in the Content Browser, and today already voices can be heard that this should be built into the Editor. The temptation to do this is strong, but as a senior developer I must resist the pressure, because too many questions remain to be asked. What problem is this tool solving? How does it coexist, overlap or conflict with existing features in the Engine? What else is required for a good user experience? And most importantly: is there maybe a better way to provide this functionality more generally throughout the Editor? I do not know the answers to these questions today, because I have not thought about them and simply tried to solve an immediate need. That's why this feature is better left as a plug-in on GitHub for now.

Reach

Last year someone in the community passionately made a case for why the Editor needs a vehicle interior editor that would allow users to design and implement automotive dashboards. While this would certainly be a very cool capability, only a small number of games and simulators made with Unreal Engine actually contain usable vehicles, so that adding it would not be the best use of our time right now. A new feature is much more likely to be implemented if it has a positive impact on many, if not the majority of users. We also need to consider the existing features that are already in daily use by a very large number of developers. Polishing and stabilizing these can have a bigger positive impact than introducing new systems.

Maintenance

The design and implementation of a new feature constitute its initial cost, but the bulk of the actual expenses are accumulated after the feature has shipped. Once the code and content has been added to the code base, it needs to be maintained, or otherwise it will quickly start to rot. Unreal Engine is a very rapidly evolving software system, and chances are that a portion of any new code will have to be adjusted within six months or less.

Almost all parts of the Engine are maintained by one, sometimes several developers, the so called system owners. We now have so many systems in place that it is common for one developer to be responsible for multiple systems, and with each new feature we put more burden on someone. The time of experienced employees is often better spent on doing research and development and supporting critical tasks that are on fire. This means that system ownership is often transferred to new hires in order to free up these resources, but that is also a time consuming process.

Support

When you think of adding a new feature to the Engine you may be mostly concerned with its implementation, but that is only half the work. Testing, documenting and supporting it are equally important. For every new capability our QA team is adding new entries into their test matrix, our documentation team is writing technical documents for end users, our development support team is monitoring and responding to questions, and our marketing team has to work out how to announce it to the public. No matter how small it appears, a new feature involves not just a programmer or an artist, but many people from different departments. While it may be implemented in a few hours, it can actually take days to get it released.

Alignment

A business also has to consider its long-term goals, and given all the factors above, it is important that the introduction of new features is well aligned with all ongoing development efforts. These often depend on external factors that are out of our control, such as trends in the game industry, availability of new technologies, and requirements of our licensees. The realistic rendering of large-scale outdoor terrains was one important goal for Epic’s presence at the Game Developers Conference (GDC) this year. Anything that fit into this was being worked on, while other tasks had to be put on the back-burner. It is possible and frequently happens that, what is unimportant today may suddenly become the highest priority tomorrow. It is this flexibility to changing environments that also helps us succeed.

Summary

As you can hopefully see now, there are several factors to be considered before Epic can commit to implementing a new idea in the Engine and its tools. The company has to be conscious of all the consequences that new feature development may have. But even with all these constraints in place, the list of tasks that we do commit to at any given time is considerable, and the number of new features and fixes in every Unreal Engine release is staggering. This is in a large part also because many of our developers go above and beyond the eight hour work day and spend many additional nights and weekends to implement things that they feel passionate about.

So next time you have a great idea and it gets rejected or put on the waiting list, please do not be disappointed. If it is really good, has wide reach, and little impact on our development schedule, then rest assured that it will be implemented rather sooner than later. And since the Engine’s entire code base has been released to the public in 2014 and made freely accessible in 2015, there are many developers in the community who may actually be able to pick up your idea before we can, and likely turn it into a plug-in to be published on the Unreal Engine Marketplace.