Random Thoughts about Unity

The quantity of money legitimately is an issue too though. Especially for mobile games -- which rely heavily on advertising and scaling up thin margins -- 2.5% of revenue (plus $2,000/yr/seat) could be quite a significant percentage of profit.

Yeah certainly, changing the terms retroactively was just something else.

However I still think that the $0.20 headlines did a lot of reputational damage (even if most medium-major customers did the math) and that could easily have been avoided.

The way they introduced the already the hardly fathomable changes was IMHO as amateurish and half backed as it gets. Literally a corporate suicide attempt, can't imagine what were they thinking...

It's not as much the language itself as the build process and iteration time (although C++ enables nasty types of bugs that are mostly avoided in C# - memory leaks, heap corruption, etc)

While I'm very new to UE but experienced with Unity, one of the first things I ran into with Unreal was the complexity of implementing a ComponentVisualiser in UE vs using OnDrawGizmos (or a custom inspector) in Unity.

Drawing a couple of lines in editor mode involved dealing with build scripts to add an editor module to the project. While live coding/hot reload works for minor edits, some code chanfes require closing+reopening the editor. In Unity, it'd have been a few lines of code in an OnDrawGizmos function and no editor reloading or messing with build setup.

It's C++, which is rarely good. The language is large and complicated and you generally need to be extra careful when using it. There's a lot of features that interact with one another in surprising ways. UE5 does its best not to make things worse, but it's not always successful. (Are you certain you've tagged everything as UPROPERTY/UCLASS/USTRUCT that needs to be? Are you definitely always capturing your UObject pointers correctly? Are you definitely never using UObjects outside the game thread? Is your TSharedPtr structure acyclic? Are you certain they're all getting cleaned up? Have you tagged each one with the correct multithreading mode? Are you keeping an eye on FName creation? Etc., etc. - perhaps some of these are fixed now, this is just some stuff I've had to fix in the past that stuck in my mind.)

C++ build times are often terrible and UE5 does not buck this trend. Editor startup and on-the-fly cooking can also adds to the iteration time. (If you're part of a larger team you'll also spend a lot of time waiting for Perforce and watching it compile shaders and recook. OK, so you can't lay the blame for this bit at C++'s feet, but if you're anything like me then this will give you additional time to spend thinking about how much the iteration time sucks.)

The debugging experience is also subpar, because you pretty much always have to run an optimised build, which makes debugging tedious. Missing variables, wonky single stepping, inlined functions that are impossible to breakpoint, all the usual problems. It's no fun having to work with C++ code using the disassembly.

Having an enormous pile of engine code to carry around also does not help when trying to get the game into a shippable state. Eliminating all the minor hitches and surprising crashes is a huge pain, simply because there's so many places they could be coming from, and even when it's obvious what the problem actually is, actually fixing it is another matter. The build times (which towards the end of the project are as bad as will ever be) really don't help; you'll be working largely with code you've never seen before, and the issue could be anywhere, so header changes aren't uncommon and spending time deep in thought while waiting for builds is not as helpful as it might be if working with your own stuff.

Unreal was really designed to be blueprint first then only move the messy parts to C++. So if you are using it like that you won't hate the C++ side of things.

I think a lot of ppl that come from Unity want to go all in on C++ and run into issue after issue after issue. Then end up hating the living hell out of it.

The non-standard scripting language is really easy to pick up and kind of fun.

Mm.

I like godot, but c# is second class citizen in that ecosystem, which they are open about (1) and despite improving (2), it still a bit rough.

“Fully supports”? I’d say more like “works mostly”.

/shrug

Gdscript is a weird stupid custom language. I feel like in most cases you shouldn’t write a new programming language for your application unless there’s no viable alternative.

I know, unreal did it with blueprint, but that’s because there are no good open visual scripting languages; and they had a lot of existing infrastructure from their previous (also stupid, for the same reasons) unreal script.

What they’re doing with verse is arguably also stupid, but I’ll give them the benefit of the doubt on the basis of a) having done it before, b) having unusual requirements for their metaverse ambitions.

Anyway. Godot did have any good excuse; gdscript was not something people asked for or wanted; it was a lazy version of python because actually embedding python was too hard. Other options existed. …but, instead the time and effort went to building a new language.

One thing you can look back at in Unitys history that is interesting is their aborted attempt to have js, c# and boo as scripting targets.

…but over time, it became clear that having feature parity in all of them wasn’t plausible.

I guess we’ll see where godot ends up, but my $0.02 is that as the api surface increases, feature parity is difficult to maintain, and gd supoort for other languages will wane with community interest.

The only language they are committed to is gdscript.

[1] - https://docs.godotengine.org/en/stable/tutorials/scripting/c...

[2] - https://github.com/godotengine/godot-proposals/discussions/4...

I write Godot games using both C# and GDScript and they’re both excellent. It’s wonderful being able to use the latest C# features, and integration with the engine and API is flawless. GDScript is just python, but with a few extra functional programming features added that make it a much nicer language to code with than Python. And it’s fun and easy to learn - a reasonably experienced developer can learn it in a few hours.

Keep in mind that it speaks more about Unity-specific behavior of C# rather than the way it performs outside of it, like in Stride3D or Godot. There is an absolutely massive performance rift between Unity's Mono and .NET 8's CoreCLR. Unity fixes this by using a subset of C# as DSL for its Burst compiler which is LLVM-based for specific hot paths, but it's something you don't need to do with "vanilla" .NET where all code has good codegen or offers really good SIMD API.

Also if your application is bottlenecked by allocation and collection throughput, you might see even greater difference in performance.

Entity Component System.

In Unity's ECS they literally had to throw out every single thing from the OO game engine to get ECS working.

So it was like having two entirely different ways of building a game in the same game engine. Everything one knew about Unity was now gone and you had to learn an entirely new way of solving the same problems. Sure you can still do OO things like inherit systems or whatnot but it was nothing like the original unity.

Once they realized how big of a change this was they did come out with some hybrid approach where you can have OO objects converted into Entities. But really it was just a Band-Aid to the gaping wound they made of the engine.

I really dont see what the big deal is here with the 60/30; who cares it was 15 years ago.

I was more identifying the philosophy present in this talk https://www.youtube.com/watch?v=rX0ItVEVjHc