12 ms·

Comparing a web library to game engine is a bit of a stretch. Unity is very nice to develop actually. It's a lot more simple than UE4 for example, but UE4 is m

Comparing a web library to game engine is a bit of a stretch. Unity is very nice to develop actually. It's a lot more simple than UE4 for example, but UE4 is much better suited for more complicated games, but then again, Subnautica is made in Unity, so Unity is very flexible. Neither is "bad" or "worse". Unity is obviously not perfect, but video game engines move and change all the time, that is the nature of the video game industry. Unity is mostly used for mobile video games, to which UE4 is not that much suited because it's more complicated and requires a better phone + the apk size will be larger in the end.

davnicwil 6y ago
> Comparing a web library to game engine is a bit of a stretch I don't necessarily disagree, but an interesting thing to point out here is that a lot of the inspiration for React in fact came from game engines! The ideas around virtual dom diffs, figuring out the minimum necessary set of deltas, and only rendering those because that's the slow part, in particular.
johnfn 6y ago
It's really not as much of a stretch as you might think. Let's put aside everything that the two libraries actually do for a second, and just think about them in the abstract. React very clearly tries to guide the developer towards correct patterns and abstractions. It's clear that React developers have thought very deeply about how to lead engineers towards the happy path of code with fewer bugs in it. It throws loud errors and warnings if you do something that could even potentially lead to an error down the line. They deprecate and eventually remove broken features. And it almost goes without saying, but they finish the features they're working on, rather than leaving them in the codebase in a half-finished state. Unity does none of these things. Unity doesn't mark old features as deprecated: you could be using a deprecated or obsolete API for months without ever recognizing it because the only communication Unity gives you is a post on the Unity blog post from years ago. (This has happened to be multiple times.) Unity doesn't tell you when you're doing something wrong - you can still StartCoroutine with a string, even though you should be using a function reference. Unity absolutely does not try to lead your code towards the happy path of fewer bugs - GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists, so if you forget and remove it later, your code will crash. React is very intentionally designed not to have problems like this. I wrote like 4000 words on this topic, if you want more detail. Feel free to dig in if you'd like: https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7afb42bdb05cadcd3c2dbd77 https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...
- ImprobableTruth 6y ago
  >GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.
  - johnfn 6y ago
    That's true, but I've always thought that removing components at runtime is such a rare thing to do, and the cost of allowing it on an engine level - inability to statically verify components - is such a high price to pay that the tradeoff just doesn't make sense. If I was czar of Unity (ha!) I would never have allowed AddComponent and RemoveComponent to be a thing - I would have required the user to add all of the components they expect to need at edit time instead. The dynamism that Unity currently affords rarely improves my game, but it does lead to a lot of bugs. If users really want to turn components on and off, they could have an enabled flag.
    - DonHopkins 6y ago
      Well so much for dynamic and procedural and data driven content, under your reign as Unity Czar. People use Unity for a lot more than Flappy Bird clones, you know. Components do have an enabled flag. https://docs.unity3d.com/ScriptReference/Behaviour-enabled.html https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h...
      - johnfn 6y ago
        Well, I would certainly hope that as my reign as Unity Czar would include guidelines for storing procedural content somewhere other than in Components :) I mean, if you're adding a new component to a GameObject for every room in your dungeon or something, you're doing something very wrong. At least in my opinion!
    - nikki93 6y ago
      Being able to add / remove components then query based on component sets an entity has is an important part of ECS data driven design, which Unity is trying to move to with eg. DOTS. Just leads to less branching etc. once your data is prepared. I'd rather just have my code express expectations upfront then query the entities that match, vs. needing to handle a combinatorial explosion of if/else based on existence checks.
tutino 6y ago
It may be your opinion, but after having used Godot I think Unity is horrible to develop with. It all depends what you are looking for in a game engine. If you want to be fast at having something nice looking on your screen , then yes Unity + asset store is great. If you care about clean code, maintainability, elegence of concepts, abstractions, architecture, long term, etc. then Unity is very bad for that. > video game engines move and change all the time, that is the nature of the video game industry. No, a fast moving field is not an excuse for having a messy architecture, half abandoned features , a unintuitive UI, no planing, and puting all your budget in shiny features and marketing instead of long term robustness and coherence. Look at Blender, they maintained coherence in fundamental concepts, architecture and UI over time yet they are in the top most amazing 3D softwares (and now 2D with grease pencil)

davnicwil 6y ago

> Comparing a web library to game engine is a bit of a stretch I don't necessarily disagree, but an interesting thing to point out here is that a lot of the inspiration for React in fact came from game engines! The ideas around virtual dom diffs, figuring out the minimum necessary set of deltas, and only rendering those because that's the slow part, in particular.

johnfn 6y ago

It's really not as much of a stretch as you might think. Let's put aside everything that the two libraries actually do for a second, and just think about them in the abstract. React very clearly tries to guide the developer towards correct patterns and abstractions. It's clear that React developers have thought very deeply about how to lead engineers towards the happy path of code with fewer bugs in it. It throws loud errors and warnings if you do something that could even potentially lead to an error down the line. They deprecate and eventually remove broken features. And it almost goes without saying, but they finish the features they're working on, rather than leaving them in the codebase in a half-finished state. Unity does none of these things. Unity doesn't mark old features as deprecated: you could be using a deprecated or obsolete API for months without ever recognizing it because the only communication Unity gives you is a post on the Unity blog post from years ago. (This has happened to be multiple times.) Unity doesn't tell you when you're doing something wrong - you can still StartCoroutine with a string, even though you should be using a function reference. Unity absolutely does not try to lead your code towards the happy path of fewer bugs - GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists, so if you forget and remove it later, your code will crash. React is very intentionally designed not to have problems like this. I wrote like 4000 words on this topic, if you want more detail. Feel free to dig in if you'd like: https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7afb42bdb05cadcd3c2dbd77 https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...

ImprobableTruth 6y ago
>GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.
- johnfn 6y ago
  That's true, but I've always thought that removing components at runtime is such a rare thing to do, and the cost of allowing it on an engine level - inability to statically verify components - is such a high price to pay that the tradeoff just doesn't make sense. If I was czar of Unity (ha!) I would never have allowed AddComponent and RemoveComponent to be a thing - I would have required the user to add all of the components they expect to need at edit time instead. The dynamism that Unity currently affords rarely improves my game, but it does lead to a lot of bugs. If users really want to turn components on and off, they could have an enabled flag.
  - DonHopkins 6y ago
    Well so much for dynamic and procedural and data driven content, under your reign as Unity Czar. People use Unity for a lot more than Flappy Bird clones, you know. Components do have an enabled flag. https://docs.unity3d.com/ScriptReference/Behaviour-enabled.html https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h...
    - johnfn 6y ago
      Well, I would certainly hope that as my reign as Unity Czar would include guidelines for storing procedural content somewhere other than in Components :) I mean, if you're adding a new component to a GameObject for every room in your dungeon or something, you're doing something very wrong. At least in my opinion!
  - nikki93 6y ago
    Being able to add / remove components then query based on component sets an entity has is an important part of ECS data driven design, which Unity is trying to move to with eg. DOTS. Just leads to less branching etc. once your data is prepared. I'd rather just have my code express expectations upfront then query the entities that match, vs. needing to handle a combinatorial explosion of if/else based on existence checks.

tutino 6y ago

It may be your opinion, but after having used Godot I think Unity is horrible to develop with. It all depends what you are looking for in a game engine. If you want to be fast at having something nice looking on your screen , then yes Unity + asset store is great. If you care about clean code, maintainability, elegence of concepts, abstractions, architecture, long term, etc. then Unity is very bad for that. > video game engines move and change all the time, that is the nature of the video game industry. No, a fast moving field is not an excuse for having a messy architecture, half abandoned features , a unintuitive UI, no planing, and puting all your budget in shiny features and marketing instead of long term robustness and coherence. Look at Blender, they maintained coherence in fundamental concepts, architecture and UI over time yet they are in the top most amazing 3D softwares (and now 2D with grease pencil)