Live data from Hacker News

Unreal vs. Unity Opinion

gist.github.com

311–319 of 319 posts

Re: Unreal vs. Unity Opinion

#311
post #308

Earlier quoted context omitted.

As far as I know, UE doesn't have crap performance. Some features of Unity might have crap performance, and the solution used by studios shipping games in Unity is to not use those features or use them very carefully. I'm not GP, but I read the thread, and it seems like you think that this guy has severe performance problems with every piece of modern software, and therefor he has severe performance problems with UE…

> and it seems like you think that this guy has severe performance problems with every piece of modern software You didn't read the thread then. The parent of my parent commented that they thought performance was a problem. I was just responding to that inference. That's all.

> The parent of my parent commented that they thought performance was a problem

You are talking about my post. I did not say anything specific to UE5, I was only trying to fix a misrepresentation of someone else. Please read the full thread for context, and also my replies to you if you need clarification.

Re: Unreal vs. Unity Opinion

#312

Earlier quoted context omitted.

>The solution is to git gud. someone unironically espousing this as a "solution" to a struggling creator will never understand why other frameworks become popular when they cater to helping them out instead of throwing a book at them. That's why Unity is more popular among small creators. They don't necessarily want to be an engineer, they want to create art. This mentality spreads outside of programming to other sof…

If not blatantly obvious, I was being flippant. You seem committed to the idea anyone is advocating yac-shaving by a highly constrained developer. I'm not seeing that. Like anything in software projects, the path of least resistance will get you to the quality floor. Trivially actionable advice doesn't exist because it will become part of the quality floor. That's just the evolution of software. That doesn't mean the…

>If not blatantly obvious, I was being flippant.

Poe's law is in effect. I've seen that sentiment elsewhere and even in this post espoused unironically. It happens quite often in these circles unfortunately.

>I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done.

there isn't, but there is something wrong when you question the quality of a developer over it, while not understanding their constraints on knowledge, time, scope, and overall goals. It's just very presumptuous and I've never seen a justified case to shame someone as such.

Promote good practices, educate on bad ones. You can do this without such attitude as "git gud" which targets devs directly (which may not be something you said, but it is said often enough that I feel a need to address it).

Re: Unreal vs. Unity Opinion

#313

Earlier quoted context omitted.

Can you provide an example of that?

you mean this topic in general? The tweet this response came from is Casey's: https://twitter.com/cmuratori/status/1514420516286709760 >Having looked at UE5's promotional content, I'm honestly just wondering: what is the point of Unity, now? Either you don't want to deal with a big unwieldy engine, in which case you roll/mod your own, or you do, and you would just use UE5, right? What am I missing? >It seems like it…

I'm looking for a single example of a "really spicy take that one can not call balanced or objective by any measure".

Re: Unreal vs. Unity Opinion

#314
post #213

Earlier quoted context omitted.

> Except we're talking about video games, where time and time again performance was crucial In that domain speed is pretty important, but even there it's not as crucial as you might assume. I'm not saying discount it altogether, just good gameplay will trump good performance. They aren't completely unrelated, but there are diminishing returns. What are the titles that need to be that much performant? AAA titles are j…

>AAA titles are just rehash/sequels with latest monetization tactics tacked on. On low end you got shitty mobile games that only optimization is user conditioning ehhh. I agree with most of your sentiment, but this is starting to be the gamer version of this topic. Replace "modern software is crap" with "modern AAA games are crap". The industry is too varied to lump it all into one box, especially when several of the…

> starting to be the gamer version of this topic

They are crap and getting worse on a completely different axis (social engineering). It's not all gloom and doom, people can get insensitive to strategies and good games haven't, stopped getting made.

> I'd say optimization is still an important and under aprreciated factor of development

I never said it didn't. I said It's not be all end all, and not optimizing is causing collapse of civilization.

Re: Unreal vs. Unity Opinion

#315
post #284

Earlier quoted context omitted.

> Yep, a gross and incorrect one, invented only to advance an argument that doesn't match reality. Performance and ms-per-frame is still highly critical in AAA-land, I beg to differ it's not an incorrect one. AAA Titles (+ if I did play them): Destiny - Review say perf OK. Elden Ring(+) - Performance Ok on consoles on release it was a slideshow. It ran like garbage. Personally I think it's a clusterfuck GTA V(+) - Ha…

I think you're missing the point about performance in games. More than in other kinds of software, adding new "features" to games tends to slow the game down more (you're trying to do more in the time you have to render a frame). So often performance improvements are needed simply to make room for more "features".

And I'm saying. Sure some games/software goes for careful time budgeting.

Others don't. Because the floor for performance tolerance is low enough you don't need to bother most of the time.

After all premature optimization is the root of all evil.

Re: Unreal vs. Unity Opinion

#316
post #118

Earlier quoted context omitted.

i would imagine it's easier to delve deep into UE since their source is actually available. I dont know if you can step into unity's code at all.

The power of unity is that you don't have to delve deeper, just start it up, make a script and start writing code. The weakness then is that all the components you code against are horribly bad/slow, so for a bigger game this approach wont scale, but if you are a programmer and just want to code a simple game unity can get you there in a weekend. First project I made in unity was a top down shooter with simple random…

> The only exceptions here are physics and the renderer, you can't easily replace those.

While physics is in the engine itself you can definitely replace or modify the render pipeline. Unity comes with a built-in legacy pipeline but nowadays you mainly use either the High Definition Render Pipeline (HDRP) or Unified Render Pipeline (URP) both of which are open source packages. Meaning they are modifiable. They are also both based on a common base class: Scriptable Render Pipeline, which you can extend to make your own render pipeline from scratch.

There's a great tutorial series for doing so here: https://catlikecoding.com/unity/tutorials/custom-srp/

In my own work I generally work with URP and modify it to suit our needs.

Re: Unreal vs. Unity Opinion

#317

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…

You can happily disable the GC for performance-sensitive situations with one line of code: GarbageCollector.GCMode = GarbageCollector.Mode.Disabled; https://docs.unity3d.com/ScriptReference/Scripting.GarbageCo...

Then you can call GC.Collect() to garbage collect e.g. between levels.

LINQ is totally fine as long as you don't do it in e.g. Update() which is called every frame. There are lots of other things you start to learn over time such as .transform internally calls GetComponent() which in itself isn't a problem but calling it in an Update() on e.g. VR where you have 72-144 frames per second might not be wise especially if you have 10x Update() methods doing this. That's why Unity has had the Profiler for many years - to pinpoint what is causing garbage to pile up and what methods are killing performance.

Re: Unreal vs. Unity Opinion

#318
post #315

Earlier quoted context omitted.

I think you're missing the point about performance in games. More than in other kinds of software, adding new "features" to games tends to slow the game down more (you're trying to do more in the time you have to render a frame). So often performance improvements are needed simply to make room for more "features".

And I'm saying. Sure some games/software goes for careful time budgeting. Others don't. Because the floor for performance tolerance is low enough you don't need to bother most of the time. After all premature optimization is the root of all evil.

I suspect that even for the slow games you listed, performance was very important to get the number of features they needed into the game.

> After all premature optimization is the root of all evil.

This quote means not to optimize too early, not that you shouldn't optimize at all.

Re: Unreal vs. Unity Opinion

#319
post #58

Earlier quoted context omitted.

You don't have the source at all, if you're you. If you're a big company (think publicly traded, not just big), you do have near realtime access to both Unity dev teams and the full up-to-date source, and you may even ship builds made with internally customized Unity versions, but it's such bad code that you wish you didn't. And they don't accept patches back for integration in any timeline worth considering, so it's…

What is your source on that? You do not have to be a publicly traded company to get source code Access, the source code is actually pretty well written and maintained. With the new approach of features being delivered in packages you get all the source directly in c#.

Unless things have changed drastically since I was at BigCo (and maintained a branch of Unity 4 for several teams, so was very familiar with the codebase, and their native code was horrific) unless you have serious sway you don't get engine source, and in my experience that's where a ton of the bugs that will screw you lie. In fact I'm dealing with a few right now at a smallCo that definitely doesn't have access (we've asked) to the important pieces of code that are making our lives hell.

I definitely agree that shipping more stuff in C# packages is a good thing, and those are mostly well written, I mostly just hate the actual C++ engine, which is frankly a disaster held together by bubble gum and spit.

Post reply on HN