Unreal Engine 5 editor quietly gets a proper Linux version

Quoting: gradyvuckovic

Quoting: elmapul

Quoting: gradyvuckovicI think sometimes the more technically skilled developers (or Linux users for that matter) forget that even among developers, there are those who are certainly capable of writing a bit of code and running a python script or clicking compile in an IDE, but struggle with something like compiling a complex piece of software through a build system like cmake, resolving dependency issues, etc.

worse, they forget that there is a magic thing called "learning curve"

Too right!

Even for the technically proficient, it takes an investment of time to learn how to use something, and the more complex / less documented / less user friendly that thing is, the bigger the time investment required.

In the case of porting some UE games from Windows to Linux, for some indie devs only really looking at the prospect of perhaps 10,000 sales total across all platforms, that time investment required to figure out how to obtain, compile and correctly configure UE, on top of all the 'first time user' learning required just to correctly setup and use Linux, wouldn't be worth it, for what would amount to possibly only a few hundred potential customers.

So anything that reduces the barrier for entry, is definitely a good thing.

There's a build script and a README with all the steps. It really isn't hard. It's even easier if you have a more or less "standard" distribution (by this i mean a Ubuntu LTS such as 20.04 for example), nothing too modern or too old. Configure and compile UE is trivial, or should be even to the most rookie of developers. If you have your own forks and game code upon it, writing portable standard code is a matter of good practice, and there are plenty of tools to assist you with that that even rookies can use (thinking about some static analysis tools, code conformance, etc). Note, i'm not advocating using UE or anything, but there are some (mis?)conceptions here that intrigued me, that's all.


Last edited by mborse on 22 July 2022 at 4:51 am UTC

Quoting: mborse

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.)

I was thinking about the same, but have a bit of frustrations with (custom) forks since UE development occurs so fast that i was bitten more than once by breaking changes in the APIs, even with what were supposed to be small point releases. Lighting and shading, BxDFs in particular come to mind. But back to the discussion, the lack of binary releases for UE is a non-issue since the target users are developers anyway.

Yeah, I've just yesterday had a similar experience with some custom optimizations in decal rendering, that we (for the moment) decided not to merge into our UE5 projects, because it would require non-trivial manual merging...

In general we are trying to stay as close to upstream as possible in our project-specific engine forks. Most of our changes are backporting some fixes from newer engine versions, or fixing some issue inside a function. We try not to change any public APIs if possible. If something can easily be fixed or worked around on the project side, we strongly prefer that approach, going as far as duplicating engine classes in-project if it makes sense (for instance we have our own modified copy of TOctree2).
The one area inside the engine that we do modify heavily per-project are the online subsystems. Our multiplayer use cases are significantly different from what Epic needs for their games, therefore we usually have to add some features to multiplayer session handling functions (just as an example, we need to update session metadata while the session is running and forward that change to all players in the session, what is not fully supported out of the box by some online subsystems)...


Last edited by soulsource on 22 July 2022 at 6:53 am UTC

Quoting: t3gAnother reason to get the HP Dev One laptop since it runs the Ubuntu 22.04 based Pop!_OS. 😎

While I used to be a huge fan of Unreal Engine, Epic done burnt this bridge down with me a long time ago. I'm sticking with Godot engine for the forseeable future.

I can play sims 5 on Linux ?

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.

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.)

Quoting: soulsourceYep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell.

Nice, a blueprint for water that itself looks like water. :D




Last edited by Eike on 24 July 2022 at 11:01 am UTC

How do I launch Unreal Engine? I extracted the archive but there aren't any instructions as to how to install the Engine

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.