8 ms·

I wonder if they're trapped in a Godot/Epic sandwich right now. I moved from Unity to Godot more or less and while it's not as good, and I'd not use it for com

I wonder if they're trapped in a Godot/Epic sandwich right now. I moved from Unity to Godot more or less and while it's not as good, and I'd not use it for commercial stuff (similarly, the Unreal Engine is for my purposes waaay too heavyweight/heavy-duty), it's probably eaten a lot of the good will/vibes audience that Unity enjoyed. (Also Epic donated 250k to Unity a few years ago - https://godotengine.org/article/godot-engine-was-awarded-epic-megagrant https://godotengine.org/article/godot-engine-was-awarded-epi... ). It might be the Godot side is insignificant, but I do wonder! Unity was and remains a cool engine on the whole, I think.

marcodiego 4y ago
Every time I see articles about Godot on HN I get the impression that it is much easier to beginner developers, hobbyists and amateurs. I think the only thing keeping Unity popular among these segments is popularity. This will probably be fixed after Godot 4.0 release.
BlargMcLarg 4y ago
Godot is insignificant but growing, that's the best way to put it. Godot has a lot of pain points, lack of knowledge and best practices which most Unity devs already figured out about Unity. Especially indie 3D is still kind of a pain in Godot. Mostly waiting for Godot 4 and hoping a lot of those pains will be solved, both 2D and 3D.
- mattlondon 4y ago
  I recently just picked up Godot after years of tinkering with unity as a hobbyist. On the whole I like Godot and will probably continue to use it instead of unity I am not a pro, but it feels like there are a few rough edges in Godot that will trip up someone used to unity. E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO - no tabs, shows you all scripts and not just the ones in the scene you are editing etc), you cannot easily "view"/"find" a node in the scene by double-clicking, you can easily dig into an instanced scene to edit it but there is no intuitive way of going "back up" so it is easy to get lost in the embedded scenes-within-scenes, you can't move the panes around in the editor how you'd like, you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult). It is taking some getting used-to. I hope v4 sorts some of these niggles out.
  - BlargMcLarg 4y ago
    >you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult). Do you mean actually pausing the game (play using the editor, then pause) and then checking the remote tree? You can check the remote tree while the game is paused. I have noticed breakpoints (in C#) tend to freeze updates on the remote tree though. Additionally, you can show collision shapes during gameplay by toggling it. >E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO) Big reason I use VS Code to edit. Unfortunately shaders are still best written in-engine and the shader window has a really, really annoying tendency of removing itself once selecting a different node without selecting a different shader. Funny since animation and audio tabs don't show the same behavior (the animation tab stays locked until you select another animation tree, audio behaves similarly). >so it is easy to get lost in the embedded scenes-within-scenes My biggest problem with scenes, I can get used to scenes-within-scenes by keeping things on a code level, but nodes tend to be fairly expensive and making things like components isn't the most intuitive in Godot coming from Unity, Unreal or anything similar. If the community was a bit more mature and bigger, someone would've probably figured out best practices to avoid these things rather it looking like a flaw in the system itself.
    - mattlondon 4y ago
      The remote tree is useful, but a fully visual representation in the editor would be best. It seems that I can force the game to reflect what I set in the editor , but not make the editor visually show what is happening in the game at that specific moment. E.g. imagine I am creating a platformer (for a totally hypothetical example) with a moving platform. There is a bug in the game where the player sometimes drops through the moving platform. In unity I can pause the game when the bug happens and then in the editor I can visually see all of the colliders and so on and quickly work out what is happening (e.g. perhaps the collider for the platform is too short or something and so the player misses it). In Godot it seems there is no way of doing this. Yes I can use the inspector on the remote tree, but this is not easy to visualise the colliders and their overlapping. Add in 3D and it gets even harder. Perhaps I am just missing some button somewhere? Debugging collision issues in Godot is proving to be a real pain in the backside without this feature. I guess that for Godot it just shells out a new process to run the game and the game is not running in the editor as it appears to be in unity, and that makes it hard to visualise the state in the editor.
- mcv 4y ago
  From what I understand (I have no personal experience with it), Godot is better than Unity at 2D games, but not remotely as good at 3D.
  - BlargMcLarg 4y ago
    Yes and no. The main benefit of Godot 2D is that it is strictly 2D, 2D and 3D are split. If you do things without needing 2D, it will edge out over Unity (UI tends to be better, pains with window sizing etc. tend to be better than Unity). The moment you want any 3D feature, you either do a shoddy hackjob retroactively fitting it into your 2D game, or you rewrite a lot of things to get 3D. Unity's main benefit is everything essentially being a 3D game, and 2D games being hamfisted in a 3D scene, making it so adding the slightest 3D feature is far easier. Simple example, if you wanted to spin sprites a la Paper Mario, you can't just do that in Godot 2D, but you can easily do it in Unity '2D'. On top, Godot's general lack of community and features still means going beyond a certain level of polish, even in 2D, becomes a bit more annoying. Support for 3rd party plug-ins are limited*. VFX examples are extremely limited. Particles are still fairly barebones in features compared to Unity (Godot 4 is bringing updates to this), and Unity has the added benefit of having a far larger community. In general you'll find similar issues you'd find in Unity, with less history or support to get you out of a bind. Godot does particularly well in fairly simple games and styles, but the moment you go beyond that scope it's basically a toss-up whether you're better or worse off using Unity right now. That should be changing in the future as more people adopt Godot, but it isn't as cut-and-dry as "2D for Godot is better". Anyone saying that may as well vouch for GameMaker, Ren'py, RPGMaker or something else based on their requirements. *: Especially art. There are tons of art workflows being popularized now to make art production easier for artists, many coming from Japan. Their support in Unity is already fairly minimal, in Godot it is practically non-existent. I imagine having good plugins for say, Spine 2D, Live2D etc. would help bring over the mobile crowd in particular and cross over to the PC/console markets as indies start trying more than just pixel art.
    - darkteflon 4y ago
      > There are tons of art workflows being popularized now to make art production easier for artists, many coming from Japan. This sounds really interesting. Could you elaborate?
- deleted 4y ago
  [deleted]
psyc 4y ago
In my opinion, UE being "too heavyweight" is more perception than reality. I didn't find it more difficult to learn than Unity. Sure, unimaginable power is there, but you don't have to use it, and some of it has very little mental overhead (almost 'for free'). I used Unity daily for 4 years, both at work (at Hololens and Oculus) and for a few personal projects and indie games, one of which was much more complex than anything I ever did at work. When I first started, I remember this feeling of being unchained and my productivity as a game developer going through the roof. (For the prior 15 years I'd been building directly on top of DirectX.) When I switched to UE5, I had that same feeling again. Of being let loose or given superpowers. I would not go back for anything. Among many other factors, access to the source code is game-changing and should not by any means be underestimated.
- nazgulsenpai 4y ago
  Not OP but in my experience, heavyweight is in reference to the sheer size, feature set and the resultant system requirements of the engine, not that it's more or less difficult to learn.
- WillPostForFood 4y ago
  Among many other factors, access to the source code is game-changing and should not by any means be underestimated. It is great of you know c++, but if you aren’t, Unreal neither offers a scripting language, nor does access to the source code offer any benefit. I’m hopefully waiting the scripting language they announced last year. (Verse?)
  - gpm 4y ago
    Blueprints are a pretty fully featured scripting language, they just happen to not be text based.
  - towaway15463 4y ago
    Why not just learn c++? There are probably millions of tutorials in general and probably thousands specific to UE.
  - 4y ago
202206241203 4y ago
Isn't Godot pushing (though not mandating) users to utilise it's own little niche scripting language? Good luck switching industries with that experience...
- TulliusCicero 4y ago
  GDScript is its 'native language', but you can also use C#. I started using GDScript and then switched, porting over my code manually to C#. I hate lack of static typing (support for static typing in GDScript is limited), and as a Java dev using C# was pretty straightforward.
  - krapp 4y ago
    I really wish it's 'native language' was Webassembly. I know they're going all in on GDScript but integrating Godot with the existing Webassembly ecosystem seems like such a good idea. There is a proposal[0] but it seems to be on hold. [0]https://github.com/godotengine/godot-proposals/issues/3370 https://github.com/godotengine/godot-proposals/issues/3370
- HideousKojima 4y ago
  GDScript is basically just a weird Python, but they also officially support C#, C, and C++. Also there are community-developed extensions for Rust and a few other languages. Also the C# support will be improving drastically with Godot 4.0 when they switch from Mono to .NET 6. You cam already build a preview version of Godot 4 with .NET 6 support if you do some tweaking, the work is pretty far along. That said, most of the documentation and guides assume you're using GDScript or sometimes maybe C#.
  - krapp 4y ago
    The languages listed as "production ready" here[0] are Javascript, Lua, Nim, Rust and Typescript. Also I would hesitate to call GDScript a weird Python. It shares some of Python's syntax, like significant whitespace, but beyond that it's a completely different beast. There is an actual Python for Godot project[1] but I don't know how close it is to ready for prime time. [0]https://github.com/Vivraan/godot-lang-support https://github.com/Vivraan/godot-lang-support [1]https://github.com/touilleMan/godot-python https://github.com/touilleMan/godot-python
Thaxll 4y ago
Godot is nowhere, it's not used by anything major. It's not even a drop in the ocean.
- datalopers 4y ago
  If the goal was actually releasing a game, why would anyone choose Godot over Unity or Unreal? Feels like it's a hobby or a statement of "I'm 100% non-commercial FOSS!"
  - TulliusCicero 4y ago
    From the hobbyist angle, Godot has tremendously better UX/ramp-up. I tried going through a book on basic Unity development and it was painful, and eventually I hit a bug I couldn't fix with the camera and had to give up. In comparison, Godot was SO much easier to get started with, the UI feels drastically more streamlined and user-friendly.

marcodiego 4y ago

Every time I see articles about Godot on HN I get the impression that it is much easier to beginner developers, hobbyists and amateurs. I think the only thing keeping Unity popular among these segments is popularity. This will probably be fixed after Godot 4.0 release.

BlargMcLarg 4y ago

Godot is insignificant but growing, that's the best way to put it. Godot has a lot of pain points, lack of knowledge and best practices which most Unity devs already figured out about Unity. Especially indie 3D is still kind of a pain in Godot. Mostly waiting for Godot 4 and hoping a lot of those pains will be solved, both 2D and 3D.

mattlondon 4y ago
I recently just picked up Godot after years of tinkering with unity as a hobbyist. On the whole I like Godot and will probably continue to use it instead of unity I am not a pro, but it feels like there are a few rough edges in Godot that will trip up someone used to unity. E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO - no tabs, shows you all scripts and not just the ones in the scene you are editing etc), you cannot easily "view"/"find" a node in the scene by double-clicking, you can easily dig into an instanced scene to edit it but there is no intuitive way of going "back up" so it is easy to get lost in the embedded scenes-within-scenes, you can't move the panes around in the editor how you'd like, you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult). It is taking some getting used-to. I hope v4 sorts some of these niggles out.
- BlargMcLarg 4y ago
  >you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult). Do you mean actually pausing the game (play using the editor, then pause) and then checking the remote tree? You can check the remote tree while the game is paused. I have noticed breakpoints (in C#) tend to freeze updates on the remote tree though. Additionally, you can show collision shapes during gameplay by toggling it. >E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO) Big reason I use VS Code to edit. Unfortunately shaders are still best written in-engine and the shader window has a really, really annoying tendency of removing itself once selecting a different node without selecting a different shader. Funny since animation and audio tabs don't show the same behavior (the animation tab stays locked until you select another animation tree, audio behaves similarly). >so it is easy to get lost in the embedded scenes-within-scenes My biggest problem with scenes, I can get used to scenes-within-scenes by keeping things on a code level, but nodes tend to be fairly expensive and making things like components isn't the most intuitive in Godot coming from Unity, Unreal or anything similar. If the community was a bit more mature and bigger, someone would've probably figured out best practices to avoid these things rather it looking like a flaw in the system itself.
  - mattlondon 4y ago
    The remote tree is useful, but a fully visual representation in the editor would be best. It seems that I can force the game to reflect what I set in the editor , but not make the editor visually show what is happening in the game at that specific moment. E.g. imagine I am creating a platformer (for a totally hypothetical example) with a moving platform. There is a bug in the game where the player sometimes drops through the moving platform. In unity I can pause the game when the bug happens and then in the editor I can visually see all of the colliders and so on and quickly work out what is happening (e.g. perhaps the collider for the platform is too short or something and so the player misses it). In Godot it seems there is no way of doing this. Yes I can use the inspector on the remote tree, but this is not easy to visualise the colliders and their overlapping. Add in 3D and it gets even harder. Perhaps I am just missing some button somewhere? Debugging collision issues in Godot is proving to be a real pain in the backside without this feature. I guess that for Godot it just shells out a new process to run the game and the game is not running in the editor as it appears to be in unity, and that makes it hard to visualise the state in the editor.
mcv 4y ago
From what I understand (I have no personal experience with it), Godot is better than Unity at 2D games, but not remotely as good at 3D.
- BlargMcLarg 4y ago
  Yes and no. The main benefit of Godot 2D is that it is strictly 2D, 2D and 3D are split. If you do things without needing 2D, it will edge out over Unity (UI tends to be better, pains with window sizing etc. tend to be better than Unity). The moment you want any 3D feature, you either do a shoddy hackjob retroactively fitting it into your 2D game, or you rewrite a lot of things to get 3D. Unity's main benefit is everything essentially being a 3D game, and 2D games being hamfisted in a 3D scene, making it so adding the slightest 3D feature is far easier. Simple example, if you wanted to spin sprites a la Paper Mario, you can't just do that in Godot 2D, but you can easily do it in Unity '2D'. On top, Godot's general lack of community and features still means going beyond a certain level of polish, even in 2D, becomes a bit more annoying. Support for 3rd party plug-ins are limited*. VFX examples are extremely limited. Particles are still fairly barebones in features compared to Unity (Godot 4 is bringing updates to this), and Unity has the added benefit of having a far larger community. In general you'll find similar issues you'd find in Unity, with less history or support to get you out of a bind. Godot does particularly well in fairly simple games and styles, but the moment you go beyond that scope it's basically a toss-up whether you're better or worse off using Unity right now. That should be changing in the future as more people adopt Godot, but it isn't as cut-and-dry as "2D for Godot is better". Anyone saying that may as well vouch for GameMaker, Ren'py, RPGMaker or something else based on their requirements. *: Especially art. There are tons of art workflows being popularized now to make art production easier for artists, many coming from Japan. Their support in Unity is already fairly minimal, in Godot it is practically non-existent. I imagine having good plugins for say, Spine 2D, Live2D etc. would help bring over the mobile crowd in particular and cross over to the PC/console markets as indies start trying more than just pixel art.
  - darkteflon 4y ago
    > There are tons of art workflows being popularized now to make art production easier for artists, many coming from Japan. This sounds really interesting. Could you elaborate?
deleted 4y ago
[deleted]

psyc 4y ago

In my opinion, UE being "too heavyweight" is more perception than reality. I didn't find it more difficult to learn than Unity. Sure, unimaginable power is there, but you don't have to use it, and some of it has very little mental overhead (almost 'for free'). I used Unity daily for 4 years, both at work (at Hololens and Oculus) and for a few personal projects and indie games, one of which was much more complex than anything I ever did at work. When I first started, I remember this feeling of being unchained and my productivity as a game developer going through the roof. (For the prior 15 years I'd been building directly on top of DirectX.) When I switched to UE5, I had that same feeling again. Of being let loose or given superpowers. I would not go back for anything. Among many other factors, access to the source code is game-changing and should not by any means be underestimated.

nazgulsenpai 4y ago
Not OP but in my experience, heavyweight is in reference to the sheer size, feature set and the resultant system requirements of the engine, not that it's more or less difficult to learn.
WillPostForFood 4y ago
Among many other factors, access to the source code is game-changing and should not by any means be underestimated. It is great of you know c++, but if you aren’t, Unreal neither offers a scripting language, nor does access to the source code offer any benefit. I’m hopefully waiting the scripting language they announced last year. (Verse?)
- gpm 4y ago
  Blueprints are a pretty fully featured scripting language, they just happen to not be text based.
- towaway15463 4y ago
  Why not just learn c++? There are probably millions of tutorials in general and probably thousands specific to UE.
- 4y ago

202206241203 4y ago

Isn't Godot pushing (though not mandating) users to utilise it's own little niche scripting language? Good luck switching industries with that experience...

TulliusCicero 4y ago
GDScript is its 'native language', but you can also use C#. I started using GDScript and then switched, porting over my code manually to C#. I hate lack of static typing (support for static typing in GDScript is limited), and as a Java dev using C# was pretty straightforward.
- krapp 4y ago
  I really wish it's 'native language' was Webassembly. I know they're going all in on GDScript but integrating Godot with the existing Webassembly ecosystem seems like such a good idea. There is a proposal[0] but it seems to be on hold. [0]https://github.com/godotengine/godot-proposals/issues/3370 https://github.com/godotengine/godot-proposals/issues/3370
HideousKojima 4y ago
GDScript is basically just a weird Python, but they also officially support C#, C, and C++. Also there are community-developed extensions for Rust and a few other languages. Also the C# support will be improving drastically with Godot 4.0 when they switch from Mono to .NET 6. You cam already build a preview version of Godot 4 with .NET 6 support if you do some tweaking, the work is pretty far along. That said, most of the documentation and guides assume you're using GDScript or sometimes maybe C#.
- krapp 4y ago
  The languages listed as "production ready" here[0] are Javascript, Lua, Nim, Rust and Typescript. Also I would hesitate to call GDScript a weird Python. It shares some of Python's syntax, like significant whitespace, but beyond that it's a completely different beast. There is an actual Python for Godot project[1] but I don't know how close it is to ready for prime time. [0]https://github.com/Vivraan/godot-lang-support https://github.com/Vivraan/godot-lang-support [1]https://github.com/touilleMan/godot-python https://github.com/touilleMan/godot-python

Thaxll 4y ago

Godot is nowhere, it's not used by anything major. It's not even a drop in the ocean.

datalopers 4y ago
If the goal was actually releasing a game, why would anyone choose Godot over Unity or Unreal? Feels like it's a hobby or a statement of "I'm 100% non-commercial FOSS!"
- TulliusCicero 4y ago
  From the hobbyist angle, Godot has tremendously better UX/ramp-up. I tried going through a book on basic Unity development and it was painful, and eventually I hit a bug I couldn't fix with the camera and had to give up. In comparison, Godot was SO much easier to get started with, the UI feels drastically more streamlined and user-friendly.