Live data from Hacker News

Unreal vs. Unity Opinion

gist.github.com

131–140 of 319 posts

Re: Unreal vs. Unity Opinion

#131
post #52

Earlier quoted context omitted.

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…

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

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.

Re: Unreal vs. Unity Opinion

#132

One of the most infuriating things about Unity is they tend to deprecate/stop maintaining working things even though the replacement is still in preview and/or not ready. It puts you in this awkward situation of, ok, do I develop against this stable thing only to have to replace it in 6 months, or do I do Unity's beta testing for them and waste a ton of my time dealing with their bugs? The other thing I really dislik…

> One of the most infuriating things about Unity is they tend to deprecate/stop maintaining working things even though the replacement is still in preview and/or not ready.

A.k.a. life as a software engineer at Google.

I've found that this is just such a common experience, not just with Unity, but everywhere. I think the real problem with Unity is that it's hard to get good guidance about whether to choose the new/experimental path or the old/deprecated path. There are random packages (ProGrids? New input system?) that are marked experimental but ready for production use except the documentation is not as good as it should be. Then there's stuff like DOTS, which is much harder to use in production.

> Also, while I'm generally a fan of C#, I think it was somewhat of a poor choice for games.

This is more of an implementation quality issue than a language design problem. Unity was stuck on an old version of Mono for a long time, for a licensing reason or something like that. I'm aware that newer C# versions have much better GC performance, but it's not something I have personal experience with.

Re: Unreal vs. Unity Opinion

#133
post #99

Earlier quoted context omitted.

Not really. You can do it, but it's definitely got issues and LFS is a must.

Used Git with Unity for over 10 years. What problems have you run into? LFS is of course a must. No one should be diffing audio files via text haha!

Git handles binary files just fine without LFS. The point of LFS is to reduce the size of repository clones, by not cloning the full history of large files.

Re: Unreal vs. Unity Opinion

#134
post #35

As a hobbyist I found Unreal to be far better than Unity. The technical debt that Unity has continued to accrue starts impacting you even as a casual user. It's a bit of a mess to be honest. Unreal on the other hand has a very solid architecture and goes out of its way to be reliable and maintainable. Plus you have the full source available in your project to search through if you want to dig into the code. The code…

Can you expand on the networking bit?

Unreal engine has native support for networking. You add some configuration to your objects to determine how they should be replicated over the net and flip a switch in the settings, and now you have a multiplayer game.

Re: Unreal vs. Unity Opinion

#135
post #74

Not to tone police that much but I really don't get people like Casey. Like his whole thing is spending a billion years writing his game engine, and then whining about all these "bloated" tools. Just completely dismissive of everything that doesn't align directly with his values (which don't include actually shipping game!) I like people who write their own engines and make bespoke things for fun. Just really dislike…

> Like his whole thing is spending a billion years writing his game engine, [..]Just completely dismissive of everything that doesn't align directly with his values (which don't include actually shipping game!)

I think Casey has been vocal enough (at least in his HMH streams) that he is not a game designer, but a game engine programmer. He is trying his hand at making full games, but I wouldn't expect him to skip over the part he is proficient at to the one at which he isn't.

As long as the "why" of making his games is not "getting rich", I think it's uncharitable to sneer at his choices.

Re: Unreal vs. Unity Opinion

#136
post #75
post #30

Having worked in Unity as a hobbyist for about a decade and considering the switch to Unreal due to obvious issues Unity is currently facing (3 rendering pipelines being the main one), I'd like to hear more input from the programmer experience in both engines. I think C# in Unity hits a really nice sweet spot: You have a powerful and expressive type system, can use nice high level features like async/await, you get (…

C# remains a plus for a lot of game code, but not as much as you might imagine. C++ usage in Unreal is really a small restricted subset of C++. For typical gameplay code, you play within their rules for uclasses/ustructs/etc and it feels pretty much like any other managed GC language. Meanwhile, for places where it matters, "raw" C++ is of course always available. Re: iteration time, Live++ [1] integration has mature…

> Re: iteration time, Live++ [1] integration has matured a lot in UE5. That means compiling most code changes without having to restart the editor (or even in-editor game session). Again, not much different than Unity here, though both can break and require editor restarts for certain types of changes.

A week of doing things in unreal engine 5 C++ has resulted in more editor restarts than years of doing things in unity. They are not really comparable. And this is from someone who have written a a few hundred thousand lines of C++ at Google and no professional experience with C#, getting to a productive state in unreal engine C++ as a solo developer is a huge slog compared to unity.

If you do most things in blueprints then unreal might be fine, but for an experienced programmers blueprints feels extremely slow and clunky to work with. I want to write code.

Re: Unreal vs. Unity Opinion

#137
post #74

Not to tone police that much but I really don't get people like Casey. Like his whole thing is spending a billion years writing his game engine, and then whining about all these "bloated" tools. Just completely dismissive of everything that doesn't align directly with his values (which don't include actually shipping game!) I like people who write their own engines and make bespoke things for fun. Just really dislike…

You clearly have no idea what's he is all about.

His message is very clear: Modern software is crap. It's orders of magnitude slower than it should be, it's buggy, and,yes, bloated.

And if you ever used any piece of software today I don't see how you can you not agree with it...

He is never advocating NOT using engines, but rather that one can be much better and more efficient developer with just a little bit knowledge of inner workings of an engine.

Him "spending a billion years" is nonsense. Handmade Hero is his side-side project which he does once a week for couple hours. You can think of HH as a teaching tool (and not even a good one which he would admit himself im sure) and not 'here is definite guide on how you make an engine yourself'. HH inspired and showed ropes to so many developers, its value is immeasurable.

Re: Unreal vs. Unity Opinion

#138
Somebody wrote this comment. It was spot on.

"UE5 is very pretty because Sweeny is a rendering god. But its hell to do any real programming with. A project that took me two weeks or so in C# is taking months to reproduce in C++ and Blueprints.

UE5 is a very pretty FPS engine with a low-level plugin interface and a scripting language. The further you get from an FPS the more unwieldly it becomes.

Unity is a programmable physics simulator that happens to have a render pipeline bolted onto it. It is much more flexible, though sadly not as pretty,"

Am also asking myself. Did the company behind Unity going public last year or so not help with the situation? I mean extra money and public scrutiny usually do.

Re: Unreal vs. Unity Opinion

#139
post #138

Somebody wrote this comment. It was spot on. "UE5 is very pretty because Sweeny is a rendering god. But its hell to do any real programming with. A project that took me two weeks or so in C# is taking months to reproduce in C++ and Blueprints. UE5 is a very pretty FPS engine with a low-level plugin interface and a scripting language. The further you get from an FPS the more unwieldly it becomes. Unity is a programmab…

In my personal opinion, it's the opposite:

Unity is a black-box machinery with a C# interface bolted on. But as soon as you touch the limits of the black box, your sand castle breaks.

UE4 is the full but raw deal. If you stay within Blueprints, things are easy and predictable. But if you need to exceed its limits, then you have the C++ needed to recompile everything, but things are messy and ugly down in the basement.

As for Unity going public, my impression is that now they are spending much more resources on shiny things to show off instead of fixing bugs that actually affect their paid customers - who mostly do mobile games. Also, it appears that they improved their profitability by massively increasing prices and simultaneously reducing support.

Re: Unreal vs. Unity Opinion

#140
post #74

Not to tone police that much but I really don't get people like Casey. Like his whole thing is spending a billion years writing his game engine, and then whining about all these "bloated" tools. Just completely dismissive of everything that doesn't align directly with his values (which don't include actually shipping game!) I like people who write their own engines and make bespoke things for fun. Just really dislike…

Roughly 600 episodes translates to roughly 600 work hours. That's 15 weeks. And now it's a full 3D game engine. Because he's not doing it contiguously and instead doing it once a week or so (there are breaks sometimes), it's continued over many years. So by episode 40, he's done about 1 normal work-weeks worth of work (and in truth, constantly starting and stopping affects the productivity, as does doing it live and explaining yourself. Imagine your productivity hit while doing pair programming, basically).

In that time, he's already got a hot reloading 2D engine https://www.youtube.com/watch?v=YBCOijN2fNA . And he's not exactly implementing it for speed of getting something done, but for educational purposes, by doing things like explicitly not using libraries, implementing PNG decompression, math functions, and doing software rendering first, and then switching to hardware acceleration even though he knew he would eventually do hardware acceleration anyway.

His point stands up completely. You can follow handmade hero and have your own 2D game engine up and running in roughly 1 week's time.

Furthermore, it's pretty disgusting to call an educational project that's had hundreds of hours poured into it "spending a billion years writing his game engine, and then whining about all these 'bloated' tools." Do you know how many people his educational videos have helped? The amount of patience and dedication it takes to answer all of these beginner questions and explain things way below his level of experience in terms of difficulty qualifies him for sainthood in my opinion.

Post reply on HN