[wokwokwok]

It’s not as bad as you imagine.

Here are some of my experiences regarding swapping to unreal:

- the c++ gameplay framework is very friendly. It’s GC, with good high level wrappers that provide stuff like options, maps, classes (ie. Reflection).

- The unreal discord c++ channel is full of people who will actually answer your questions, it’s brilliant.

- Every high level blueprint function is a c++ function. I cannot express how powerful it is to be able to step into the source of like “MoveToPoint” or “Whatever” and see exactly how it was implemented in c++.

- You should use blueprints. It’s like python glue for machine learning; write in c++, but when you need to twiddle an animation curve, or lay out a state machine, it’s pretty good. If you’re working with an art team, they can actually make gameplay changes. It’s very productive.

- Plug-ins are a first party construct; you should use plugins to build reusable content. They’re not quite as good as the unity package manager, but it’s rock solid foundational stuff.

- The compile times are not often an issue; I use the incremental unity builds (it’s a source file aggregation thing, why they called it unity I have no idea) and it takes like what 15 seconds to build a plug-in? Launching the editor is slow 30 seconds?) though.

It’s not all good; it has bugs. Sometimes the editor just goes into crazy mode and needs a restart. When you mess up, it crashes with a segfault.

C++ is just less productive; but I’m using the unreal for rider EAP and it’s pretty good.

So… I miss c#; but overall I would rate my experience as pretty good, and since my experience with DOTS in unity has been, shall we say, 100% negative…

Give it a try. :)

[dogles]

Just want to +1 that Rider for Unreal [1] is GREAT. It's also totally useable for non-Unreal C++ projects. Things like code inspection (e.g. goto definition/find usage/etc) and refactoring are actually fast, unlike Visual Studio. I've got a few quibbles about low-level (think asm) debugging, but I've pretty much moved exclusively to Rider at this point.

The Unreal-specific stuff is nice as well: being able to see what blueprints override a uproperty or implement an event is a huge time saver for AAA-scale codebases.

(Not affiliated with Rider, just a big fan)

[1] https://www.jetbrains.com/lp/rider-unreal/

[jackosdev]

Rider was damn good compared to Visual Studio, been over a year since I used it and was still in beta then as well

[mycall]

Do you think it is possible to use IL2CPP within Rider for Unreal? Then C# could be used in RFU.

[yAak]

No, IL2CPP is proprietary Unity tech.

[cma]

By unity build I think they mean all cpp files within a module are compiled included into one (so each cpp isn't a separate execution unit, anonymous namespace etc. will bleed over between files unless they are in separate unreal module or plugin).

Similar to SQLite amalgamation.

Turning it off could parralelize the build more, except linkers are often singlethreaded and bottleneck things enough to undo that benefit sometimes.

[maccard]

You really don't want to turn off unity builds in unreal for anything larger than a toy project. The build system is "smart" (albeit itself is slower than say ninja). It breaks the project up into multiple unity "blobs" for you, and they're compiled in parallel. It also integrates with source control to remove files from the "working set" so if you're iterating on a small file it will be removed from the unity blob and compiled on its own for faster iteration.

[mikepurvis]

Running a unity build [1] means the compiler only has to parse and reason about the headers once. So you lose the parallelism of multiple TUs, but you gain on not doing the header crunching over and over again. Whether your codebase will benefit from that is a matter for testing, but many do.

[1]: https://en.wikipedia.org/wiki/Unity_build

[behiri]

also by using unity build you don't need to link object files. I think that is main reason to use unity build, it eliminates need for any build system and compiling source code in a new machine is as simple as compiling a single transition unit.

[maccard]

Unreal is far too big for one unity blob. It still requires a build system for many other reasons.