Hacker News Reader

Comment by Pfhreak | Hacker News Reader

I absolutely love Unity, and it's what I reach for as my default for new projects, despite several years working in the games industry.

It's easy to get started, iterate on ideas, there are tons of examples of things online.

That said, it's not without its warts -- APIs change constantly, which means many of the examples or assets you find are no longer functional or need to poking to get working. Sometimes things just... behave oddly... in the editor. And the story around collaborating with friends is still not great (though a free tier for Unity Collaborate has helped with this a bit.)

If you haven't messed around with Unity, I encourage folks to give it a try. The new Universal Render Pipeline stuff they've been building is really nice for a solo/small team project.

View on HN

The most important thing about Unity is to know that the Editor is not the same as the Client.

Assets load differently, in surprising ways. Materials may work fine in Editor but not in Client.

Code executes differently. Timings are different, the Editor shares managed Heap with the Client, and so garbage collection is different.

And so on.

Rule 0 with Unity: _do not rely on the Editor for testing_.

Don't rely on race conditions and your code will run similarly on device and in editor.

I agree that you can't easily use editor performance profiles though; there's far too much editor noise.

I found that the programming model in unity makes avoiding race conditions more inconvenient than in other types of programming. Specifically the component and game object initialization orders are not specified unless you do extra work to manually initialize everything in some clunky init code

A good pattern for this is to use the Unity serialization to inject all the references and initialized values you need. This allows Unity track all the dependencies and load everything you need.

Unity is still crap at loading things in order but you simply have to make peace with that. Instead you have to write a bit more defensively and assume that your code will get initialized in a random order. As long as you use Unity serialization all the references will be set when the lifecycle callbacks fire.

You can - Use coroutine Starts to wait for initialization

- Ensure all the inits are done in Awake so things are ready during Start

- You can also move away form initialization towards a more lazy pattern and make sure any calls into your behavior are asynchronous and include self init when needed.

It is a bit clunky but you can get used to it. Lean into the idea of behaviors being asynchronous actors and it makes a bit more sense.

Coroutines are dangerous to use for initialization and I strongly recommend to be wary of that.

All coroutines on a gameobject are halted if it is disabled, _and do not restart_ when it is re-enabled.

For this reason it is easy to mistakenly leave a game object half-initialized, due to an enormous amount of plausible situations where some event, script or other may disable the game object.

Now, there is a work-around: have Start yield a coroutine started on a "safe" object that will never disable.

The caveat is that the caller can be destroyed during execution of the coroutine but the coroutine will persist to execute because it is on another object.

You've just shifted the problem. Its better to just track your exact state and leverage the fact that you get exclusive atomic control of the main thread until you yield or return.

The only lifecycle a behavior can trust is its own. Relying on other objects turns into a mess when your weak assumptions are violated.

Besides causing a spaghetti mess of lifecycle tracking and callbacks and such, it leaves you wide open to the major problem if callbacks running pass the life of the thing to call back to. You've thrown away Unity's lifecycle tools by dumping everything into a big pot. Now you have to null-check in the callbacks to make sure your things are still alive. Track your own state and you'll be fine.

Coroutines will stop when the owner dies and that is by design. Leverage that to ensure brain dead clean up.

Objects are very often going to be disabled through user action anyway, eg quitting a level. Its better to just assume that will happen at any time and plan accordingly.

In the case of UGC, you have zero ability to assume control of the object's lifecycle and enabled state. Zarro.

Hot take: to some extent, this is a good thing as it discourages relying on emergent behavior in the client, like timings, the heap, etc that may or may not differ between your machine, your player's machines, and even future hardware that does not exist right now.

I'm with you there, but (and, this is an unpopular opinion) I think it would be even better if it went the way of Go. Go will randomize iteration order of unordered collections (at least in development builds?) on purpose so you learn not depend on it. The "tricky" thing with Unity is that you might find a consistent client behavior and unknowingly depend on it.

I think with time/experience you'll learn to spot what to ignore (frame lengths, etc) and what you could count on. And just to test fully-build games often, and across clients.

* C# does something similar with hash across builds (so you don't depend on serializing/deserializing hashes and expect them to work; they want the freedom to change hash functions).

Go doesn't randomise map order, it's just indeterminate. It picks a lot random bucket to start the iteration but the order will always be the same in the end (at least when I last investigated it). It's essentially free, so it does it in production too

I’ve had frustration with the warts you describe. Have you tried Godot? Any idea if it’s any better in those regards?

Godot isn't finished yet.

Unless you plan on developing an open source game or need absolute total control over your project I wouldn't use Godot.

The greatest advantage of Unity is anyone can develop something for it very fast. The worst part of Unity is anyone can develop something for it very fast. An asset developer might build something which he or she doesn't actually update, or has a nasty habit of completely breaking your project.

The one thing I don't like about Unity is the lack of quality control with assets. Some assets will give you a nice foundation for a fantastic project, others will set you back days. Asset authors are almost always either absolute Angels, who will go out of their way to help you and if they can't offer you a refund.

Or their jerks, their assets don't do what they promised and they'll refuse to refund your money. If I could fix one thing about the unity ecosystem, I'd tell Unity to give asset buyers a few no contest refunds . I probably spend about 1000$ on Unity assets per year.

The one time a $15 asset ends up not working correctly I should be able to get a refund without begging the author for it.

Plus it's essential to understand what your goal is. Do you want to actually ship your game within a reasonable amount of time? Or do you feel like creating a project primarily for learning, or to just share the code on GitHub?

If you want to ship a game, either use Unity or Unreal. These are the only two engines which are well supported enough where you can get something done within a reasonable amount of time.

Open source engines are cool, but there is absolutely no expectation of things working as well. Let's say you want to build a project with Godot, and it's going well so you want to publish it to Switch. You're going to run into a ton of problems off the bat, one open source projects tend to not support closed apis which council manufacturers force you to support. So you're going to have to build your own integration there.

Vs clicking a build to Switch button with Unity.

Honestly I can't say enough good things about Unity, you have an amazing amount of educational material they publish. And for the most part I've been able to buy assets for $50 or $100, and save myself 80% of the development time on my projects. You aren't going to have a good time with Unity if you're adverse to buying assets.

I think all your comments are valid, except for the one on support for Switch (and other consoles). I've never done this, but when I was playing with Godot there were references to being able to go to a particular consultancy who are able to provide a build chain for consoles - the issue there isn't that Godot can't support them, but that the NDAs required for console builds don't allow the integrations to be open source.

> Godot isn't finished yet.

So you're saying we're Waiting for Godot?

Second this. I protyped in both Unity and Godot for the same concept. Godot is just harder and more work generally. Then getting published on consoles with Godot requires partnering with the one vendor who supports it. Whereas Unity has wider support.

> Godot isn't finished yet.

Very surprising. ;-)

> Godot isn't finished yet.

What important features is Godot missing that Unity has?

Well, Unity has hundreds of full time engineers working on features and Godot has, what, five? (Plus non-full time contributors) So it’s no surprise that Unity is ahead of Godot in terms of functionality. Godot may suit your needs just fine, but Unity has a lot more work out into it.

When I played with Godot (two years ago, a lot has been improved since), it was definitely a bit raw. It worked, but I found it a bit of a struggle. I’ve been reading their release notes since and they’ve improved a lot, but I haven’t actually tried it out yet.

The one thing I personally don’t like about Unity is how much emphasis is put on C#, I just never got into the language and have no desire to use it. Godot is a bit nicer for me in that respect. I prefer Unity’s ECS and job system over Godot’s scene system though, but lots of people say the opposite.

Of course Unity is ahead and of course Godot has lots of features people want to add in the future. The same applies to Unity and any game engine I've encountered.

I don't see anything so far to back up the claim that Godot isn't finished, which would mean it's not suitable for anything except for experimentation. Seems like it's at least fine for smaller games.

Yes, people do use it for real games after all. I think the 2D side is very mature while the 3D side is currently being worked on.

There are a few interesting Reddit posts.

Here's a summary: https://www.reddit.com/r/godot/comments/axsohk/in_your_opini...

Missing occlusion culling is on the top of list.

Probably worth mentioning that thread is a year old and some of those issues may have been addressed by now.

The latest reference (from 9 months ago, so not much more recent) I could find for occlusion culling[0] says it and LOD are planned for the Vulkan branch, so those are still issues.

[0]https://old.reddit.com/r/godot/comments/emachb/how_long_unti...

Yeah, I know they have CSG now, for example, because I studied the code for a personal project.

What kind of assets are you buying? I thought most assets were character models and such but sounds like you buy assets with actual functionality. Do you have any examples?

Maybe a less intense example here is, for example, custom shaders. You can get better terrain systems that do exactly what you want, etc from the Unity asset store.

Especially for a software engineer, there's of course always the fantasy of coding everything on your own. I might not get a platformer system because that seems "fun" to implement, but shaders often feel so beyond me that I'd just rather get someone's optimized shader.

https://assetstore.unity.com/packages/templates/systems/corg...

That's basically a 2D / 2.5d game framework.

Interesting. Is this essential for people making 2D games in Unity? I see that it's officially recommended by Unity themselves.

It’s not essential but this is one of Unity’s revenue sources, so they will advertise it . In fact, one key aspect to finding success (disclosure: I am an ex Unity AssetStore publisher) in the AssetStore is to persuade buyers in thinking your asset is essential for making their project come true. It’s all about selling shovels and dreams.

Where is it officially recommended? There is other content that is created by Unity but that is clearly labeled as such.

Nothing from the Asset Store is essential, but it would take much longer to do everything yourself from scratch, as well as being difficult to learn how to do everything yourself without examples to experiment with.

I think it was this part:

> The Corgi Engine is recommended by Unity as part of its 2D Essentials Pack.

Maybe I read too much into it.

How much experience have you had with Godot?

I played with the Godot editor for a few hours.

It's simply nowhere near as polished as Unity or Unreal. If you want to make something in Unity, you can pay a few hundred dollars for some assets, snap them together like Legos , add your own character models and be ready to ship in months.

In Godot, it's rare at all to see any paid assets. Meaning instead of being able to buy a starter kit and get my project done, I'm coding all this stuff by myself.

For another alternative (especially if you want to stay with C#) have a look at https://stride3d.net

Reply on news.ycombinator.com