We do often include affiliate links to earn us some pennies. See more here.

Unreal Engine 5 editor quietly gets a proper Linux version

By - | Views: 44,635

I'm not entirely sure when this went live but it appears that Epic Games have finally released a full proper download of Unreal Engine for Linux developers. Seems a lot of people noticed only today, although the page mentions the build was released Jul 12 - 2022, with GOL getting messages about it everywhere so it seems like a fair few find this quite exciting.

Previously, to use Unreal Engine on Linux you would need to compile it yourself from the source but now that's no longer the case. To get it you need to have accepted their EULA and be logged in with an Epic Account, once done it will offer up the ~20GB download to get you going but it mentions needing ~60GB for the full thing. Additionally, it seems their main supported Linux distribution is Ubuntu 22.04 although it appears to run just fine on Fedora 36:

You can see more of the Linux requirements here.

Considering all the issues with Unity lately from joining with ironSource, their CEO calling some game developers "fucking idiots" and when that made the news that same CEO said on Twitter it was "Clickbait" only to then later apologise, this might be a good time for Epic Games to push their way through to pull in even more developers into their ecosystem.

So much great news for Linux gaming and even Linux game development lately, it's nice to see so many moving parts.

Article taken from GamingOnLinux.com.
35 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
34 comments
Page: «4/4
  Go to:

soulsource 28 Jul
Quoting: mborse
Quoting: soulsource
Quoting: Dribbleondo
Quoting: soulsource
Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build
Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

Fun Fact; Spyro Reignited's ability codebase is done entirely through blueprints.
Yep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell.
What some other "Blueprint only" projects do is that they create the low-level building blocks in C++ and expose them as Blueprint nodes, so that only the high level logic is done in Blueprint. That has the advantage of having a small (-> readable) visual representation of the high-level flow, while all the low-level details, that would be hard to read in visual form, are implemented as text - and in addition, performance critical code paths tend to be in C++ then too.
(We used this approach for the mission setup in two of our games - the low level stuff was done by coders in C++, the high-level logic in Blueprint by designers, the bugs by a lack of communication between those two groups.)

Oh wow... i wish i could unsee some of those blueprints.
So in general terms do you prototype things in the editor blueprints and if worth it, you re-implement it as a building block? What criteria do you use mostly for this? Encapsulation factor for neatness, reusability, or both?
I agree about the lack of communication as well, specially when designers most of the times lack lower level knowledge that is useful, even if superficial.

Our general workflow has changed in the last few years. Initially we did prototype a lot of things in Blueprint with the goal to move the whole logic to C++ later for performance (nativising Blueprints was not supported back then), but found out that more often than not those "prototype" blueprints remain in the project until release for time reasons. This was an actual problem in Bus Simulator 18, when we added gamepad support later, because that required understanding very complex UI blueprints... Also, everyone who tried to make a bus mod for Bus Simulator 18 knows that the bus blueprint setup was - let's just say I'm surprised nobody posted our bus base blueprint on Blueprints From Hell.

Since Bus Simulator 21 we try to do almost everything in C++, including prototypes. The main reason is readability and modularity, with performance being an added benefit. Emphasis on "try", because in BS21 some logic still happens in blueprints, and there are exceptions like the mission system. For the UI we added our own "framework" of sorts, where we back up most UI blueprints with a ViewModel on the C++ side, so that the view blueprint only needs to display the data computed by the view model and update itself when the respective event is triggered on the C++ side. For the missions the main reason to use blueprint was iteration times for designers when setting them up in-editor, but we also offer the option to create missions for map mods in BS21, and all our modding support runs through blueprint.
What made prototyping in C++ viable was the addition of Live++ to Unreal. Though still some limitations apply on what can be done without an editor restart, this tool made iteration times for C++ changes nearly comparable to iteration times for blueprint changes.

The criteria when we moved code in BS18 from Blueprint to C++ were usually one of these two: Either we happened to have to modify some blueprint and it had already "grown organically" until it was utterly unreadable (so moving it over to C++ was synonymous with understanding what it does), or we found out during profiling that some code path in a blueprint was causing performance issues.

In Bus Sim 21 the first reason basically did not happen, because of the goal to also prototype in C++, but the second reason, performance, was still encountered quite often in late-game missions. (The Mission Helpers blueprint function library one can see in the mod kit is the result of that.)

Long story short: Both, neatness and reusability play a role for our decisions what to do in C++, with nowadays nearly all development happening in C++.


Last edited by soulsource on 28 July 2022 at 6:14 am UTC
mborse 28 Jul
Quoting: soulsource
Quoting: mborse
Quoting: soulsource
Quoting: Dribbleondo
Quoting: soulsource
Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build
Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

Fun Fact; Spyro Reignited's ability codebase is done entirely through blueprints.
Yep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell.
What some other "Blueprint only" projects do is that they create the low-level building blocks in C++ and expose them as Blueprint nodes, so that only the high level logic is done in Blueprint. That has the advantage of having a small (-> readable) visual representation of the high-level flow, while all the low-level details, that would be hard to read in visual form, are implemented as text - and in addition, performance critical code paths tend to be in C++ then too.
(We used this approach for the mission setup in two of our games - the low level stuff was done by coders in C++, the high-level logic in Blueprint by designers, the bugs by a lack of communication between those two groups.)

Oh wow... i wish i could unsee some of those blueprints.
So in general terms do you prototype things in the editor blueprints and if worth it, you re-implement it as a building block? What criteria do you use mostly for this? Encapsulation factor for neatness, reusability, or both?
I agree about the lack of communication as well, specially when designers most of the times lack lower level knowledge that is useful, even if superficial.

Our general workflow has changed in the last few years. Initially we did prototype a lot of things in Blueprint with the goal to move the whole logic to C++ later for performance (nativising Blueprints was not supported back then), but found out that more often than not those "prototype" blueprints remain in the project until release for time reasons. This was an actual problem in Bus Simulator 18, when we added gamepad support later, because that required understanding very complex UI blueprints... Also, everyone who tried to make a bus mod for Bus Simulator 18 knows that the bus blueprint setup was - let's just say I'm surprised nobody posted our bus base blueprint on Blueprints From Hell.

Since Bus Simulator 21 we try to do almost everything in C++, including prototypes. The main reason is readability and modularity, with performance being an added benefit. Emphasis on "try", because in BS21 some logic still happens in blueprints, and there are exceptions like the mission system. For the UI we added our own "framework" of sorts, where we back up most UI blueprints with a ViewModel on the C++ side, so that the view blueprint only needs to display the data computed by the view model and update itself when the respective event is triggered on the C++ side. For the missions the main reason to use blueprint was iteration times for designers when setting them up in-editor, but we also offer the option to create missions for map mods in BS21, and all our modding support runs through blueprint.
What made prototyping in C++ viable was the addition of Live++ to Unreal. Though still some limitations apply on what can be done without an editor restart, this tool made iteration times for C++ changes nearly comparable to iteration times for blueprint changes.

The criteria when we moved code in BS18 from Blueprint to C++ were usually one of these two: Either we happened to have to modify some blueprint and it had already "grown organically" until it was utterly unreadable (so moving it over to C++ was synonymous with understanding what it does), or we found out during profiling that some code path in a blueprint was causing performance issues.

In Bus Sim 21 the first reason basically did not happen, because of the goal to also prototype in C++, but the second reason, performance, was still encountered quite often in late-game missions. (The Mission Helpers blueprint function library one can see in the mod kit is the result of that.)

Long story short: Both, neatness and reusability play a role for our decisions what to do in C++, with nowadays nearly all development happening in C++.

Thank you, it makes sense. I was kind of thinking if there was a point in having a (deep) technical artist develop a library of blueprints for prototyping purposes, to iterate fast, and then invest in implementing the most useful ones in C++ - at least to remove some of the excessive granularity of some of those blueprints from hell. I suppose it still makes sense, but all in all this hypotetical process would be much more tied to the C++ development team than to the technical artists, or designers from the get go, so we're back at the points you made. Thank you for your feedback and answers.
soulsource 28 Jul
Quoting: mborse
Quoting: soulsource
Quoting: mborse
Quoting: soulsource
Quoting: Dribbleondo
Quoting: soulsource
Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build
Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

Fun Fact; Spyro Reignited's ability codebase is done entirely through blueprints.
Yep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell.
What some other "Blueprint only" projects do is that they create the low-level building blocks in C++ and expose them as Blueprint nodes, so that only the high level logic is done in Blueprint. That has the advantage of having a small (-> readable) visual representation of the high-level flow, while all the low-level details, that would be hard to read in visual form, are implemented as text - and in addition, performance critical code paths tend to be in C++ then too.
(We used this approach for the mission setup in two of our games - the low level stuff was done by coders in C++, the high-level logic in Blueprint by designers, the bugs by a lack of communication between those two groups.)

Oh wow... i wish i could unsee some of those blueprints.
So in general terms do you prototype things in the editor blueprints and if worth it, you re-implement it as a building block? What criteria do you use mostly for this? Encapsulation factor for neatness, reusability, or both?
I agree about the lack of communication as well, specially when designers most of the times lack lower level knowledge that is useful, even if superficial.

Our general workflow has changed in the last few years. Initially we did prototype a lot of things in Blueprint with the goal to move the whole logic to C++ later for performance (nativising Blueprints was not supported back then), but found out that more often than not those "prototype" blueprints remain in the project until release for time reasons. This was an actual problem in Bus Simulator 18, when we added gamepad support later, because that required understanding very complex UI blueprints... Also, everyone who tried to make a bus mod for Bus Simulator 18 knows that the bus blueprint setup was - let's just say I'm surprised nobody posted our bus base blueprint on Blueprints From Hell.

Since Bus Simulator 21 we try to do almost everything in C++, including prototypes. The main reason is readability and modularity, with performance being an added benefit. Emphasis on "try", because in BS21 some logic still happens in blueprints, and there are exceptions like the mission system. For the UI we added our own "framework" of sorts, where we back up most UI blueprints with a ViewModel on the C++ side, so that the view blueprint only needs to display the data computed by the view model and update itself when the respective event is triggered on the C++ side. For the missions the main reason to use blueprint was iteration times for designers when setting them up in-editor, but we also offer the option to create missions for map mods in BS21, and all our modding support runs through blueprint.
What made prototyping in C++ viable was the addition of Live++ to Unreal. Though still some limitations apply on what can be done without an editor restart, this tool made iteration times for C++ changes nearly comparable to iteration times for blueprint changes.

The criteria when we moved code in BS18 from Blueprint to C++ were usually one of these two: Either we happened to have to modify some blueprint and it had already "grown organically" until it was utterly unreadable (so moving it over to C++ was synonymous with understanding what it does), or we found out during profiling that some code path in a blueprint was causing performance issues.

In Bus Sim 21 the first reason basically did not happen, because of the goal to also prototype in C++, but the second reason, performance, was still encountered quite often in late-game missions. (The Mission Helpers blueprint function library one can see in the mod kit is the result of that.)

Long story short: Both, neatness and reusability play a role for our decisions what to do in C++, with nowadays nearly all development happening in C++.

Thank you, it makes sense. I was kind of thinking if there was a point in having a (deep) technical artist develop a library of blueprints for prototyping purposes, to iterate fast, and then invest in implementing the most useful ones in C++ - at least to remove some of the excessive granularity of some of those blueprints from hell. I suppose it still makes sense, but all in all this hypotetical process would be much more tied to the C++ development team than to the technical artists, or designers from the get go, so we're back at the points you made. Thank you for your feedback and answers.
You're welcome - please also don't take my experience as the single truth out there. It's just the experience we gathered after doing two Bus Simulator games in Unreal, and might not apply to games with different design.

And about tech artists setting up Blueprint Function Libraries: The Mission Helpers in BS21 are actually two types. A Blueprint that has been made by tech art, and a C++ class that is used for those computations where the Blueprint VM performance is a problem (or where a faster way to compute the results is available by using non-blueprint interfaces).
Zerocool128 10 Aug
Iv been working with the engine on windows and would love to work on this with linux, how in the world do i get it working with build game? ue5 runs fine but cant get it to build even a sample project. i have installed every c++ compliler i can find on the pop shop with no luck in packaging a game. heeeeeeeelp.....
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.