Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unreal vs. Unity Opinion

gist.github.com

Post reply on HN
Print view View original

181–190 of 319 posts

Re: Unreal vs. Unity Opinion

#181

Post by tuvan »

fxtentacle wrote: post #174
Jensson wrote: post #142

Earlier quoted context omitted.

Unity is primarily the renderer and physics engine, everything else is really easy to just write yourself as c#, and unity in no way hinders your ability to write everything else in c#. If you want to change the renderer or physics engine then you have a problem, yes, but unity isn't for people who wants to customize the renderer or physics engine.

In our case, we jumped ship because Unity had bugs and were unwilling to fix them for years. I believe it still is effectively unusable for anything requiring realtime multiplayer.

Seriously, how can the most used game engine not add proper multiplayer support in 20 years. They announced Netcode for game objects this year which seems OK but even that has "Clientside prediction" in "under consideration" category, any proper realtime multiplayer game on the market has this feature and rollback netcode isn't even under consideration. So if they achieve their goals, they will have a system that is good for at most indie games after 20 years.

Re: Unreal vs. Unity Opinion

#182

Post by torginus »

kensai wrote: 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…

Well, if you want to explore the depths of human despair and misery, just search the Unity forums for 'Scriptable Render Pipeline'

Re: Unreal vs. Unity Opinion

#183

Post by pelorat »

dogles wrote: post #98

One thing that wasn't mentioned: (realtime) multiplayer. What's the story here for Unity these days? There's still a lot required in Unreal to implement things like bullet or projectile latency-correction unfortunately, but the base infrastructure they provide here is huge. Last I used Unity, there was essentially nothing. There were some third-party things but nothing you'd ever want to use in a shipping multiplayer…

The networking in Unity is still terrible. Unreal is of course better but still not good enough out of the box. When Riot developed Valorant they had to rewrite the networking code to be more like Quake and Source.

Re: Unreal vs. Unity Opinion

#184

Post by doikor »

kensai wrote: 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…

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

Sweeney is the CEO of a company with over 1000 employees. I highly doubt he has had much (if any) time to write any rendering code for a long time now.

Re: Unreal vs. Unity Opinion

#185

Post by torginus »

markus_zhang wrote: post #81
georgeecollins wrote: post #71

Earlier quoted context omitted.

C++ can be used instead of Blueprints.

Thanks I understand that, just that the whole engine seems to be a huge blob that is difficult to approach. Maybe I should just focus on one part.

This advice is a bit generic - but look at either the official examples or tons of github projects that have C++ in them and try to understand how they work - that's the thing that worked for me.

Re: Unreal vs. Unity Opinion

#187

Post by ratww »

bluescrn wrote: post #171
ashkankiani wrote: post #140

Earlier quoted context omitted.

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…

These days, if you're making a game, even a fairly small indie game, you usually want it to run on as many platforms as possible. Even for a 2D game, there's big advantages to using a ready-made engine that natively supports many platforms, from mobile to high-end consoles (across OpenGL, D3D, Metal, and proprietary console rendering APIs). If you're building a game engine as a fun/learning project, that's cool. But…

You're repeating advice for people with zero experience in making games, which is fine. But it doesn't have much to do with this discussion.

Casey Muratori is not teaching people how to make an indie game or an AAA. He's teaching how to make almost everything in a video game from scratch. He speaks constantly of how he's not a game-code programmer, let alone a game designer. Pretty much everyone watching it knows what they're in for, because he talks about it all the time.

Those ready-made engines you're talking about have to be made by someone. Not to mention that anything beyond "basic indie game" requires someone who knows deeply how a game works. And those people are who Casey is currently educating.

Someone doing Unity/Unreal for several years won't learn those things Casey is teaching unless they really dive into deeper material, and Casey is providing exactly this kind of material.

This industry doesn't need more people with Junior-level experience even though they've been working at it for 20 years.

Maybe this kind of education not you, and that's fine, but just because something is being taught on the internet, doesn't automatically mean you and everyone have to learn it. You gotta learn to live with it.

Re: Unreal vs. Unity Opinion

#188

Post by torginus »

A magical property of Unreal is it's open-source-ish nature. Industry leading people constantly contributing features at high quality that become integrated into the engine. I contrast, for Unity, you have to shop around in the Asset Store for that does the thing.

An example for it is procedural shattering - some guy needed it in their game and now it's standard in Unreal. For Unity, you have to buy it from the store, and I guarantee it, it won't be even nearly as good.

I think the Asset Store is a poisoned apple for Unity - for developers it makes very little financial sense, since you are looking at what, 1000s of sales for $50, of which Unity makes some significant commission? That's why people put a ton of half-baked stuff in there, which they abandon, and due to the constant shift of Unity, becomes unusable in like 3 releases.

They also can't integrate their stuff at the same quality in the engine as if they had source access.

Additionally this creates another headache for Unity as well - now if they wanted to 'properly' support this feature, they'd be competing with people who wrote the asset store version - sending the signal to them, that if you do really well, your feature will be stolen by your masters.

What does also happen is Unity buys a particularly high-quality plugin (TextMesh Pro, ProBuilder) and they just give it away and don't bother to integrate it, which means it will stick out like a sore thumb.

Re: Unreal vs. Unity Opinion

#189

Post by bick_nyers »

maccard wrote: post #176
kensai wrote: 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…

I'm not really sure where this came from, but it's pretty much nonsense. Tim Sweeney hasn't written rendering code (or engine code) in years, the Unreal rendering team is enormous these days. > 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. How much of that is familiarity with C# vs unfamiliarity with C++? I find it prett…

Even in Blueprint you can push out code fairly quickly if you are familiar.

Re: Unreal vs. Unity Opinion

#190

Post by jstimpfle »

bluescrn wrote: post #171
ashkankiani wrote: post #140

Earlier quoted context omitted.

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…

These days, if you're making a game, even a fairly small indie game, you usually want it to run on as many platforms as possible. Even for a 2D game, there's big advantages to using a ready-made engine that natively supports many platforms, from mobile to high-end consoles (across OpenGL, D3D, Metal, and proprietary console rendering APIs). If you're building a game engine as a fun/learning project, that's cool. But…

On the other hand, porting to other platforms is probably never a no-op even when building on big 3rd party tech stacks. Many of the platform specifics will shine through to the high-level code.

And personally I find it rewarding to learn how to properly layer the code in order to factor out platform concerns. Many of the differences between platforms will seem kind of dull and the different platform implementations will seem kind of repetitive, but it's not terrible either if you develop on one main platform and routinely port to a handful of other platforms.

I suppose that graphics APIs are the biggest annoyance here because there is comparatively a lot of setup boilerplate required, and depending on your game, considerable math code will have to be in implementation-specific shader code. There are standalone 3D graphics libraries with backends for OpenGL/Direct3D/Vulkan/Metal, not sure how well they work.

Post reply on HN