Hacker News Reader

Comment by fidotron | Hacker News Reader

Unity is a tragedy. They have managed to fumble the technical aspects so much it drove people away, to the point they become more valuable as part of an ad business than an engine one. Their efforts outside the games industry don't appear to have as much traction as they deserve either.

The question has already been "Why aren't you using Unreal?" and that's just going to get harder.

Given the current VC taste for eliminating all things which count against gross margins now might be a good time to be an engine developer again.

View on HN

The question is "Why aren't you using Godot?"

Unreal is just another vendor with a hand in your revenues.

Godot is a little behind Unity in terms of technical features. It's way behind Unreal.

I do a fair amount of Godot development - for casual mobile games, limited PC games, or games where you're planning on a publisher to fund your port, I think Godot is a good choice.

Do you have an example of a 3d godot game that you have played? Searching returns no games I've heard of, even including 2d.[0] Cf. unity and unreal. I've never played any godot games as I don't like 2d games. With the exception of 2d rpgs for which rpgmaker seems to be better.

>Unreal is just another vendor with a hand in your revenues.

* after 1M in revenue, IIRC

[0]https://google.com/search?q=popular+godot+games

My last comment there is a hint that might happen, as this shifts the calculus enough that for big casual players hiring devs to work on godot makes more sense. However, those players will also get preferential treatment anyway.

But everyone will be waiting for Godot to have the first widespread hit before jumping in like that.

Sonic Colors: Ultimate was recently released, and it's a Godot game.

Godot is not really optimized for thousands of entities but they're getting there. Also, the tooling for consoles isn't there. I use Godot almost exclusively and its impressive what they've built.

> Why aren't you using Unreal?

C++. Sure, we can talk about Verse or even Skookum, but C# is much easier. Still, if any big game engine would have something like JS it would be even better for indie or small studios.

Unreal C++ is so heavily modded that it often doesn't really feel like C++. Like I feel kind of odd the rare times I use std:: anything. And Unreal C++ tends to be garbage controlled, support reflection, and so on. The only real big downsides are you have C++ compile times and generally poor intellisense - though IDEs that specialize in Unreal, like Rider, have seen exponential improvements on that front. And for teams that are genuinely averse to C++, going 100% Blueprint is also a completely viable option.

For people scared off by C++ and who want faster recompile times, check out the Nim bindings [0]. Check out his Twitter/X account [1] for plenty of cool things it brings to the table.

[0]: https://github.com/jmgomez/NimForUE

[1]: https://twitter.com/_jmgomez_

Blueprints Blueprints Blueprints

The name of the game is iteration speed. (I always think of Paul Grahams story about beating out the competition using Lisp.)

I've been working with UE since 2014, originally started in UE4 C++ and avoided blueprints and kept everything in C++. Was great 'for performance' and code diffs but now 10 years later I'm 99% blueprint and only go down to C++ if the performance requires it for the 1% of hot paths. My iteration time in UE using blueprints makes me shutter to think of all the time I spent waiting for C++ to compile.

I just started using Unreal 5 to prototype a VR game (lots of quirks but this engine is amazing). I’ve been writing C++ for 5ish years now and am pretty comfortable with it. I’ve also been slowly converting all the blueprints in the VR template provided by Unreal to C++ for a few reasons and was curious if these effect you.

I tried using blueprints for awhile, but it just feels so cumbersome and time consuming. I can bang out 10 lines of code basically as fast as I can think, but converting those same 10 lines of code to blueprints often involves much more time. You have to click around a bunch, rearrange the routing wires, make it look readable, abstract a lot of stuff into functions that usually don’t need it just because it helps condense the blueprints. Then the blueprints end up sprawling a large area and are very difficult to keep in my head at once (whereas it would normally take less than a page of C++ code to write it out and you can easily hold that in your head).

Basically, I was wondering if these downsides to blueprints effect you much or if you’ve developed suitable workarounds? I want to like blueprints, but the time it takes to click around and make it readable is painful, in my opinion, more painful than compile times for the C++.

Yea its unfair to taught Blueprints as the answer when they have a serious learning curve.

It took me a while to build up enough experience where I could become more expressive with Blueprints than C++. The Lyra example has some good Blueprint hygiene worth reviewing where they organize all variables underneath a function call.. but until you have serious experience with Blueprints they are going to feel like a cumbersome mess.

My advice is to do what you feel most expressive with, doing the thing you enjoy more will lead to more hours of experience. Start with C++ and build up a good understanding/mental model of the engine and then eventually give Blueprints a try in a few more years and you will see them in a new light.

I’ll have to check out the Lyra example! But yea, C++ definitely feels more comfortable for me at the moment. I’ll try blueprints again in a few years :)

Blueprints allow you to tinker with the architecture a couple of times before locking in and moving. In C++ you are much less inclined to do so.

Blueprints are fun to work with, but the amount of time it takes to drag and drop nodes around to make the equivalent of a for loop feels incredibly unproductive. The result does look visually pleasing though!

Visually pleasing indeed. https://blueprintsfromhell.tumblr.com/

I really hate BP and wish we get something better. The thing is, technically you are supposed to do gameplay in BP and push the core ones to C++, but BP is so messy after a short while.

How big is your team? How do you code review? How do you unit test? How are you maintaining 3 year old blueprints?

This will work just fine for small indie games and teams where the code is thrown out after a year, but there's no scaling this. I've worked with enough 10 year old Max/MSP patches to know that you will have an unmaintainable mess of wires that is as good as garbage after a while.

Larger teams typically use Blueprints to prototype but then rewrite in C++. This is a perfectly fine use case, but ultimately you still need it "written down" for the maintainability.

tl;dr Blueprints are a tool in the process to writing C++, they aren't a replacement.

Unity used to support JS but nobody used it. Why would I ever pick such a weakly typed mess over C# for this use case?

Because it was not JS, it was UnityScript which is what happens when someone read "JavaScript: The Good Parts", and thought the title was "... The Bad Parts" and threw all those away and kept only the actual bad parts.

It was just about fine if you were doing very small projects but quickly got very hairy, and their compiler was full of bugs.

And to contrast, Godot's GDScript has been great for me so far. I've been hacking at a personal project for a couple of days now and I feel right at home in the language, which feels right at home in the engine.

I've actually been writing an engine in JS (with the exception of physics in WASM) partly to understand the implications of doing it.

You do need to be disciplined, however, being able to simply start extending random instances of other types proves remarkably useful when developing.

I'm not sure such a thing would work well on a team.

Probably not very good on a team, yeah. I actually have a bit of a toy game engine for the browser/ThreeJS targeted at making games similar to the Windows 95 screensaver. Learned some good things like GLSL and shaders but working in JS was definitely a bit of a slowdown when I'd hit classes of bugs that wouldn't be possible in C#, even with annotations helping me. But other times it was convenient being able to pass stuff around without writing up classes or structs for them as you alluded to.

Has a brief overview in its README if anyone wants to check it out: https://github.com/ldyeax/MazeEngine

I have more expansive ideas for it but for now the main demo is this silly museum. https://jimm.horse/maremuseum

It's a fun experiment in seeing what JS can do, it's cool having it run natively on the web, and annotations get you a lot of the way there, but in a context like Unity I'd never pick it over C#. Typescript might be alright but at that point why bother? C# has anonymous types, tuples, and such today too.

> The question has already been "Why aren't you using Unreal?" and that's just going to get harder.

Lack of Web and Mobile support

It really isn't the lack of mobile support, as Fortnite shows, it is the fact Unity devs are cheaper and iteration speed from code changes is faster, which in hypercasual type stuff proves to be essential.

I tend to think the dev iteration speed is the core Unreal weakness.

The problem Unity have created is if something can be made with Unity it will get crowded out with clones in five minutes.

I did an evaluation earlier this year between the two. We needed the 3d engine but also needed native phone features. Meaning some screens of the app would be Unreal/Unity and some would be native iOS.

We couldn't even get Unreal to build as an embeddable library for a mobile app nor could we get it to build into anything that would run in a web browser despite more than a week of effort.

We had Unity working for both use cases in under a day.

>We needed the 3d engine but also needed native phone features.

PUBG mobile, which is in unreal, uses flutter for exactly this case.[0]

[0] https://flutter.dev/showcase/pubg-mobile

Interesting! Thank you for sharing.

> in hypercasual type stuff…

Yes. Well.

The idea that developer iteration speed is actually an indicator of project-completion-at-scale speed is really only true at a trivial scale; you know, when you only have developers. Maybe a handful of them. ..and like, one does-everything artist.

When you have multiple different teams including non developers working on actually building a significant game, crafting levels, assets, etc. the iteration speed of your handful of devs is really really a drop in the ocean.

There are a lot of very powerful tools in unreal for teams, and they have consistently invested in tooling (eg. File per actor) and real life production needs (eg. LED stage support) with their customers.

Unity has invested in different areas, with a lot of effort, and bluntly, nothing to show for it.

    really only true at a trivial scale

You seem to suggest this means it doesn't really matter? I run a startup with 4 employees (only 2 of us are developers). I care about stuff in this "trivial scale" and a lot of other developers are like me.

It's not just hobbyists and students.

> at a trivial scale; you know, when you only have developers. Maybe a handful of them. ..and like, one does-everything artist.

And that includes most games.

>Unity has invested in different areas, with a lot of effort, and bluntly, nothing to show for it.

Aren't they making shitloads on advertising?

> The problem Unity have created is if something can be made with Unity it will get crowded out with clones in five minutes.

This really has nothing to do with Unity. Flappy Bird could have been built on any platform and you would still have a million clones of it. Because it takes a day to make it. It's just as easy to clone that game in Unreal Engine, fwiw.

Unity didn't create the concept of the quickly built game, nor is Unity responsible for society incentivizing this type of game dev. If anything, the new runtime fees will disincentivize this type of game, so maybe that's a good thing?

How do you square what you say here with your prior comment that unity is driving devs away?

Is Unreal known for having poor web and mobile support? Genuinely curious.

Compared to unity, yes (especially for 2D stuff which is more the norm on those platforms).

Unity is already imho pretty bloated but at least useable and a sensible choice for both, Unreal is just too massive and more suited for console 3D type of games.

Unreal is nowhere in the mobile space.

I'm a game dev and Unreal is not a Unity replcement imo.. Making a game in Unity feels like making a game in XNA, you just start writing code and can write your entire game from scratch and can ignore most of Unity's features. Unreal on the other hand feels like you are modding an existing game and you must use their many existing systems and patterns. I'm moving to Godot, it feels like the new Unity / XNA.

In the past fews years, it feels like Unity had exactly one programmer for each important package like SRP/UI Toolkit and all the other employees were sales and PR.

Reply on news.ycombinator.com