3 ms·

Godot is an awesome engine and I recommend everyone still using the ancient ones like Unreal and Unity to switch to it, at least on new projects. You can script

Godot is an awesome engine and I recommend everyone still using the ancient ones like Unreal and Unity to switch to it, at least on new projects. You can script it in pretty much whatever language you want.

viraptor 7y ago
Downvoted for "ancient". There's quite a lot of competition between those engines and people have different reasons for choosing each of them. You can find quite a few "why I chose X for my game" videos on YouTube, all with very good reasoning regarding features, payments, available resources, available positions in the industry, etc. Fanboy-style recommendations are not enough.
darkwinx 7y ago
How are Unreal and Unity ancient?
- deleted 7y ago
  [deleted]
- shmerl 7y ago
  They might be not ancient, but they still didn't manage to produce a good quality parallelized Vulkan renderer. Unreal made something (and marked the whole effort "archived"¹), but it's not really parallelized and performance is bad. I bet Godot will beat them to it, because they are focusing on Vulkan as their primary API. 1. https://trello.com/c/lzLwtb5P/124-vulkan-for-pc-and-linux https://trello.com/c/lzLwtb5P/124-vulkan-for-pc-and-linux
pjmlp 7y ago
As nice as Godot might be, it still as a lot of growing up to do before it can match "ancient" engines.
classified 7y ago
C is even more ancient and it is used by more developers than all the game engines added together. When people use "ancient" tools they tend to have good reasons for it.
krapp 7y ago
>I recommend everyone still using the ancient ones like Unreal and Unity to switch to it, at least on new projects. The last reason you'd want to switch to a new game engine or framework is because it's newer. And, while I like Godot, the implication that it can replace Unity (much less Unreal) at this point is just ludicrous for anything but bare minimal toy projects. >You can script it in pretty much whatever language you want. Yes, no and maybe? Someone has to write the interface for each language and be willing to update it with each version of Godot, and all existing documentation and tutorials reference GDScript and maybe C#. There are language forks out there but I'm unaware of any projects being completed with them, so their stability and viability is questionable.
- jmiskovic 7y ago
  > And, while I like Godot, the implication that it can replace Unity (much less Unreal) at this point is just ludicrous for anything but bare minimal toy projects. That's going way too far in other direction. IMO Godot can support any kind of 2D project and deliver polished and performant product. In 3D medium the competition is too far ahead with ready-made assets and robust tooling, but complex projects still seem doable. Currently Godot is used mostly by open-source gamedev enthusiasts and not professional teams with art talent and funding. The editor and engine was not really pushed to its limits. I agree with your other points though.
  - krapp 7y ago
    Fair enough in the case of 2D, but the most common use case for Unity and especially Unreal is 3D games. Godot still lacks features like occlusion culling and compute shaders that would even make it competitive with the other engines in that regard. I think Godot's still a couple of major versions away from that, at least. I agree that so far no one's really tried pushing Godot to the limit as far as I've seen. But when all you have to go by is the content on /r/godot it doesn't make a compelling argument for Godot as a viable replacement for existing engines yet.
BlargMcLarg 7y ago
Godot still has a lot of issues for which workarounds don't exist, doubly so when working in a team. Issues we've run into: The way references are handled in scene files makes it easy to get conflicts when working on the same scene. In Unity, solving these conflicts is a lot easier (from personal experience, only an issue working in teams). Animation files sometimes empty themselves when using a composition-based approach. If the object you reference no longer exists (e.g. you programmatically decide what weapon a player uses and don't instantiate anything preemptively) the animation player will opt to rewrite the animation as if that component never existed, resulting in loss of work. Low level oddities: drawing lines using the drawing system doesn't work if the point is outside view of the screen. You can't specify whether to draw the segment that would be visible if possible. There still isn't a whole lot of support to release on some specific platforms, and some popular programs don't have a support plugin yet (e.g. Live2D). The object-oriented structure of each node type can be severely limiting towards a composition-based approach. Minor gripe as it is possible to work around this or implement your own entity-component-system framework or Unity-like GetComponent/AddComponent structure. It is definitely a great engine and regarding 2D, I'd say it is at least on par with Unity. For 3D and general-purpose, it is still subpar to Unity and definitely subpar to Unreal. Of course, the easy solution to each of my problems is "why not write it yourself?", but that requires time saved when using Unity. On the other hand, I do find Unity to be particularly cumbersome on the final 20% of the project, whereas Godot is much easier to finish a project with.
Agentlien 7y ago
Back in 2016 I made a comment[1] about Unity being impressive because of how easy it is to use and a great option for simple indie game. I noted, however, that it didn't yet seem to be a good enough option for AAA development. Since then, Unity has grown into a serious contender and while my experience with Unreal is limited to hobby projects I can definitely say I prefer Unity over Frostbite for AAA development. At this point, I'd like to say that what I said back then now seems to be true for Godot instead. [1]: https://news.ycombinator.com/item?id=13151354 https://news.ycombinator.com/item?id=13151354

viraptor 7y ago

Downvoted for "ancient". There's quite a lot of competition between those engines and people have different reasons for choosing each of them. You can find quite a few "why I chose X for my game" videos on YouTube, all with very good reasoning regarding features, payments, available resources, available positions in the industry, etc. Fanboy-style recommendations are not enough.

darkwinx 7y ago

How are Unreal and Unity ancient?

deleted 7y ago
[deleted]
shmerl 7y ago
They might be not ancient, but they still didn't manage to produce a good quality parallelized Vulkan renderer. Unreal made something (and marked the whole effort "archived"¹), but it's not really parallelized and performance is bad. I bet Godot will beat them to it, because they are focusing on Vulkan as their primary API. 1. https://trello.com/c/lzLwtb5P/124-vulkan-for-pc-and-linux https://trello.com/c/lzLwtb5P/124-vulkan-for-pc-and-linux

pjmlp 7y ago

As nice as Godot might be, it still as a lot of growing up to do before it can match "ancient" engines.

classified 7y ago

C is even more ancient and it is used by more developers than all the game engines added together. When people use "ancient" tools they tend to have good reasons for it.

krapp 7y ago

>I recommend everyone still using the ancient ones like Unreal and Unity to switch to it, at least on new projects. The last reason you'd want to switch to a new game engine or framework is because it's newer. And, while I like Godot, the implication that it can replace Unity (much less Unreal) at this point is just ludicrous for anything but bare minimal toy projects. >You can script it in pretty much whatever language you want. Yes, no and maybe? Someone has to write the interface for each language and be willing to update it with each version of Godot, and all existing documentation and tutorials reference GDScript and maybe C#. There are language forks out there but I'm unaware of any projects being completed with them, so their stability and viability is questionable.

jmiskovic 7y ago
> And, while I like Godot, the implication that it can replace Unity (much less Unreal) at this point is just ludicrous for anything but bare minimal toy projects. That's going way too far in other direction. IMO Godot can support any kind of 2D project and deliver polished and performant product. In 3D medium the competition is too far ahead with ready-made assets and robust tooling, but complex projects still seem doable. Currently Godot is used mostly by open-source gamedev enthusiasts and not professional teams with art talent and funding. The editor and engine was not really pushed to its limits. I agree with your other points though.
- krapp 7y ago
  Fair enough in the case of 2D, but the most common use case for Unity and especially Unreal is 3D games. Godot still lacks features like occlusion culling and compute shaders that would even make it competitive with the other engines in that regard. I think Godot's still a couple of major versions away from that, at least. I agree that so far no one's really tried pushing Godot to the limit as far as I've seen. But when all you have to go by is the content on /r/godot it doesn't make a compelling argument for Godot as a viable replacement for existing engines yet.

BlargMcLarg 7y ago

Godot still has a lot of issues for which workarounds don't exist, doubly so when working in a team. Issues we've run into: The way references are handled in scene files makes it easy to get conflicts when working on the same scene. In Unity, solving these conflicts is a lot easier (from personal experience, only an issue working in teams). Animation files sometimes empty themselves when using a composition-based approach. If the object you reference no longer exists (e.g. you programmatically decide what weapon a player uses and don't instantiate anything preemptively) the animation player will opt to rewrite the animation as if that component never existed, resulting in loss of work. Low level oddities: drawing lines using the drawing system doesn't work if the point is outside view of the screen. You can't specify whether to draw the segment that would be visible if possible. There still isn't a whole lot of support to release on some specific platforms, and some popular programs don't have a support plugin yet (e.g. Live2D). The object-oriented structure of each node type can be severely limiting towards a composition-based approach. Minor gripe as it is possible to work around this or implement your own entity-component-system framework or Unity-like GetComponent/AddComponent structure. It is definitely a great engine and regarding 2D, I'd say it is at least on par with Unity. For 3D and general-purpose, it is still subpar to Unity and definitely subpar to Unreal. Of course, the easy solution to each of my problems is "why not write it yourself?", but that requires time saved when using Unity. On the other hand, I do find Unity to be particularly cumbersome on the final 20% of the project, whereas Godot is much easier to finish a project with.

Agentlien 7y ago

Back in 2016 I made a comment[1] about Unity being impressive because of how easy it is to use and a great option for simple indie game. I noted, however, that it didn't yet seem to be a good enough option for AAA development. Since then, Unity has grown into a serious contender and while my experience with Unreal is limited to hobby projects I can definitely say I prefer Unity over Frostbite for AAA development. At this point, I'd like to say that what I said back then now seems to be true for Godot instead. [1]: https://news.ycombinator.com/item?id=13151354 https://news.ycombinator.com/item?id=13151354