8 ms·

Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

277 points by mdtrooper 3y ago

mdtrooper 3y ago
The original link in HN is in: https://news.ycombinator.com/item?id=37561762 https://news.ycombinator.com/item?id=37561762
ladberg 3y ago
> Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. I feel like this entirely disregards the caching costs of using >2x more memory in some cases, speed of float32 vs float64 operations on CPU, and potential CPU <-> GPU memory transfers. EDIT: Nvm disregard this comment, I just noticed the existence of: PackedByteArray, PackedInt32Array, PackedInt64Array, PackedFloatArray, PackedDoubleArray Anything set of numbers needed by the GPU or big enough to affect the cache will probably use those arrays.
- jackmott42 3y ago
  In the context of function parameters at the edge of C# and c++ I don't think it will ever amount to a large amount of memory being wasted. The cache point may be relevant, but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. So maybe not so bad.
  - jayd16 3y ago
    >but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. How do you figure? Are you saying there should be no tight loops that hit engine code, none that live in the C#/scripting lifecycle or all tight loops should be rewritten in C++? The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me.
    - badsectoracula 3y ago
      > The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me. As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive the behavior.
      - jayd16 3y ago
        This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints. But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.
        johnnyanmac 3y ago
        It's such a bizarro world after a bunch of UE discussions to suddenly see people dismiss scripting concerns with "well just write that code in C++. Blueprints is slow". I'm usually the one saying that, but that's as a professional developer who needs to optimize all that stuff (and TBH the blueprint code tends to have some bad performance choices even before discussing the BP perf loss). Hearing people dismiss the performance of something as basic as a raycast with "well just code in C++", while many people (including this founder) say that Godot focuses on simplicity sounds counter-intuitive. So is GDScript a lie for anything slightly intensive (and again, raycast. I'm using "intense" in the loosest of words) and I should simply make my whole game an engine module? But I keep hearing that "I should just try GDScript it's really easy and you come around to it!" Feels like a motte and bailey.
        badsectoracula 3y ago
        What i wrote wasn't making your whole game an engine module (i.e. writing everything in C++) but writing your intensive code in C++ and using scripting (be it blueprints, GDScript or whatever) to drive that intensive code. There is nothing counterintutive in that, it is right in the name of scripting languages: they're meant to script behavior. And the dismissal isn't about having a raycast being slow, but about using too many raycast queries in script to do something reusable that should be in native code in the first place. If your scripting language ends up in your performance profile chances are you are using it wrong. The occasional raycast query in scripts to make a decision is fine, doing thousands of individual raycast queries from scripts is not - if nothing else, make an API that accepts multiple raycast queries at once, performs it in C++ in a single call (so you only get the scripting overhead for that single call) and gives the result back. But IMO if, as mentioned in the article, you are going to make a controller that is to be used by multiple entities in the game, then you should make it in C++ - potentially with script hooks to customize the behavior, if needed.
  - lainga 3y ago
    I think part of the problem is that using GDExtension is like a two-way FFI. You can call (C++) extension functions from GDScript, but the same interface and overhead are used to call (lib) Godot functions from the (C++) extension. AFAIK it's not like there's a <godot_impl.h> with engine functions that the compiler could inline. Here's a good example (look, there I am!), although it's a bit old and actually led to perf improvement: https://github.com/godotengine/godot-cpp/issues/1063 https://github.com/godotengine/godot-cpp/issues/1063
- gabereiser 3y ago
  Yes, however, by the time they fix the dictionary hack glue code as described, PCI bus transfer speeds will have increased (again). I’m a fan of making everything 64bit from an api level, but sometimes you have to work with the right type for the architecture.
- deleted 3y ago
  [deleted]
3seashells 3y ago
Yet
jmull 3y ago
Strong response. I'm not sure I would have been so generous to the author of the article this is in reply to. But I suppose that's a skill of a successful open source leader -- to turn interactions with critics into productive discussions rather than arguments, and perhaps even turn the critics into supporters. It seems to have been that author who chose the FUD-ful title "Godot is not the new Unity". I guess there are times in life where you face a choice: be fair, reasonable, and intelligent, or... just try to get them clicks. Well, that article got a lot of click. Good job?
- kbelder 3y ago
  I said this not long ago in a different thread, but after reading this article I want to say it again. I'm very impressed with the management of the Godot project. They seem to be avoiding all the common mistakes and drama that so many projects fall prey to. They're doing everything professionally.
  - Lerc 3y ago
    I have contributed a very small amount of code to Godot. In the process of doing so I was very impressed with the entire process. They were very supportive and quick to respond. Overall it was one of the best open-source contribution interactions I have experienced.
- JD557 3y ago
  > I'm not sure I would have been so generous to the author of the article this is in reply to. But I suppose that's a skill of a successful open source leader -- to turn interactions with critics into productive discussions rather than arguments, and perhaps even turn the critics into supporters. FWIW, reduz (Godot author) and sprudd ("Godot is not the new Unity" author) previously discussed this on Reddit[1], and sprudd was actually sounded pretty nice (the first reply even includes a "and I hope that I wasn't too rude in the article. :)"). Overall, I think the original article was written in good faith, just with a click-baity title (and I imagine reduz thought the same thing). That might have helped to avoid a more angry reply. 1: https://www.reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k16982q/ https://www.reddit.com/r/godot/comments/16lti15/godot_is_not...
json2d 3y ago
"Godot is/is not the new Unity" is a pretty loaded statement, and would mean different things to different folks. This particular discussion focuses on the performance gap between the two engines looking specifically at how raycasts are implemented, and the larger implications from that analysis.
LarsDu88 3y ago
Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on...
- hutzlibu 3y ago
  "If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on..." Yup .. but maybe not stupidity, but rather a non generic game. In my case I need lots of raycasts, to determine what exactly the player and the enemy bots can see. Basically I have a simulation in 2D (using box2d directly in js as a wasm libary) - and all the bots and the player only (mostly) get information based on raycasts. They have to scan the world and react to that information, which leads to a different result, than the usual approach (cheating). So I am looking forward to get this fixed asap as well and also cannot really consider godot before that. Edit: performance problems with raycasts I had to experience as well, because the roundtrip js to wasm is expensive. I first wrote a WebGPU shader doing only raycasting in my world, but better was modifying box2d (and compiling to wasm) to include a function, that does all my raycasts in one call and returns a big array (or rather a array with pointers to the structs in the internal wasm heap).
  - rngname22 3y ago
    If the game is 2D and you can divide space into tiles/blocks and walls/obstacles have their own blocks/tiles (or you can easily establish a grid over your world and determine what cell each actor is in), I wonder if there's way to use BFS in a maze-solving manner to calculate shortest path between a given actor and the target you want to check visibility for, and if the distance in blocks/tiles returned by BFS/pseudo-pathfinding is greater than a direct distance formula calculation between the two blocks/cells then maybe you know there's an obstacle? I guess that requires you to be able to create the network/graph of traversable nodes as well.
marcodiego 3y ago
Of course not. It won't have a draconian license agreement.
26fingies 3y ago
It seems weird to extrapolate where Godot will live in the game development ecosystem from its current performance characteristics for certain operations. It's like trying out Windows 95 and saying "Microsoft isn't going to dominate the PC world because Windows 95 crashes a lot!" Maybe.. but these sorts of technical minutae are not the things that determine winners as far as I can tell.
- dundarious 3y ago
  “Godot is not the new Unity” is a present tense statement, issued at a time when many studios are considering a hasty and impromptu transition from Unity -- they are looking for a suitable equivalent now, not many years into the future. It's a sensible question about today and the very near future.
gsuuon 3y ago
It sounds like Godot just needs a few more hands on deck to close up a lot of these smaller gaps, as Juan mentions most of the issues are already being discussed or were simply lower priority to fix. Hopefully with the influx of Unity refugees (and potential contributors) they'll be able to quicker ship more of the things they already have on their roadmap. I do think the original article's claim of 'Godot is not the new Unity' is accurate, just not for the architectural reasons claimed. Folks probably shouldn't go into it thinking that Godot will handle every use case just as well as Unity. It hasn't had billions poured into it like Unity, but it is mature and ready for serious games. Plus - open source means you can just get your hands dirty and fix critical (for you) bugs instead of hoping Unity gets around to it.
philipov 3y ago
Offtopic: BDFL is a funny initialism. Although it means Benevolent Dictator For Life, its visual similarity to BOFH evokes a second meaning.
lukebitts 3y ago
Great response, I downloaded Godot because I was looking for a lightweight engine that doesn't take two minutes to load. This seems to explain the reason for the performance, I'm glad its one of their focus
stephc_int13 3y ago
I think this type of discussion can help the design team behind Godot to improve their practices and implementation, in the end it would be very healthy for the gamedev community to have a reliable and performance open-source engine as the "standard" for students, indies and AA projects alike. Godot is better than Unity on many sides, but the internal architecture is coming from a place where they relied too much on naive and inefficient OOP constructs, those can be very hard to optimize later. Performance should not be treated as a second class citizen when creating an engine, there are always solutions but it can be very time consuming to find workarounds to palliate design issues with the engine, it can also be a real motivation killer for a small team when they discover the framerate of their game on older/smaller devices...
kaveh808 3y ago
The killer feature of whatever game engine replaces Unity in developers' hearts and minds is going to be the platform delivery aspect. Once you can press a button and get Win/Mac/Linux/Android/iOS/etc versions of your game built, you're in business. All the higher-level features (3D, ray casting, etc) will be contributed by the community over time.
- andrewmcwatters 3y ago
  I think you mean lower-level.
johnnyanmac 3y ago
>Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. I believe the issue was less with the sizes of items being passed in and more with the API conforming to work with GDScript first and formost. Returning a dictionary for an operation that has a few float64's feels overkill and doesn't make sense even with an explanation of the available datatypes. >Only a pathological use case is shown, the rest of the API is fine. I wouldn't call raycasting in a full blown engine "pathological". Especially one that touts 3D Secondly, that doesn't inspire confidence. "Don't mind the room on fire, the rest of the house is fine!". The onus is on the engine to prove that, and numbers prevail over words. So far only one part of the conversation has shown that. Even in the next sentence it sounds like they focus on a simple API over performance, and that doesn't fill me with confidence. If Godot isn't focusing on 3D, that is fine but there's so much noise trying to to say otherwise > Eventually, C# will be moved to the universal extension system and this will allow the unifying of the default and .net editors, it is just not the case yet, but its top in the list of priorities I hope so, but there seems to be a trend of various "top priorities" from Godot that have trouble crossing the finish line. That's a reocurring issue even in this response alone: I'm not convinced that performance is a top priority for Godot. And that confidence means everything if the "BDFL" controls what gets into the project proper. >The problem is that, at the C++ level, this function takes a struct pointer for performance. But at the language binding API this is difficult to expose properly. This is very old code (dating to the opensourcing of Godot) and a Dictionary was hacked-in to use temporarily until something better is found Yup... so 10 years later that hack stays in and modern programmers come cross it. This isn't even a critique, that's simply the nature of legacy code. Unreal has an entire part of a forced namimg scheme (the compiler won't let you run the game without conforming) that can only be explained as "well we wanted to do this in the 90's but we slowly took it out sp it's not relevant today". But if it took 10 years for someone to do more than a few dozen raycasts a frame, it says more about the battletesting than any deep dive. It goes back to my confidence above. >, you need to create a C# version of a C++ instance as an adapter... Why is it troublesome? because C# has a garbage collector and C++ does not. slight nitpick: while garbage collection is annoying, you technically do have a built in way to disable it in certain regions, as well as the option in later versions to have unmanaged blocks of code. I'm not saying this is easy to do, but it is something that developers much smarter than me in c# have gotten around. I know c# bindings was a relatively recent endeavor so I'm not going to give it too much flak > Godot containers don't work like STL containers. Because they are used mainly to pass data around, they are allocated once and then kept via reference counting. 1) reference counting implies some sort of automated memory free-ing scheme. 2) That doesn't necessarily address potential issues of inefficiently allocating memory and keeping it contiguous. But I won't talk much on that because I'd need to first read more on the engine's memory allocating schemes first. > Godot uses far more optimized containers that are not directly exposed to the binder API. Okay, but why? Someone wanting to use C# or c++ or whatever script extension that isn't GDScript wants those optimized containers. Does it go back to the earlier quote of "it's difficult to get right and no one wanted it"? >As a result, we created a special path for GDScript to call more efficiently. okay, and the link is... an open issue on Github made 2 months ago, with no additional comments or discussions. Simply a request from a code owner. I don't know if this conversation is simply happening in IRC/chat, but it's unusual given how much other activity I have seen in other PR's/proposals (recent and from years prior). Was this the best reassurance that they are addressing performance? --------- I don't mean to sound like a downer, but I feel the article is overall missing the forest for the trees. I've read about several different kinds of devs from years prior talk about how they passed on Godot because they hit hitch after hitch once they were doing something slightly advanced. a dismissal of "this is a pathological use case" sounds fine in a vacuum, but it sounds like this has been a long standing issue, and priorities simply weren't on smoothing out such hitches. I'm not saying they should have listened to those devs, but I think the most frustrating thing is that I don't know what or who Godot wants to service. So far it sounds like they want to have all the cake, but currently are also low-key fine being a hobbyist 2D engine that can maybe do some simple 3D stuff. Which again, is fine. But that's not what it sounds like Godot is selling. It unfortunately reminds me a lot of Unity, both on the outside (yeah, having 2 unsupported netcode solutions with a 3rd in pre-alpha isn't a good look) and within the company itself. I'll quote some part of a post from the creator of Rimworld, who had similar evaluation and conclusions over 5 years ago: >There's obviously a tremendous amount of technical talent going into Godot, but from what I can tell there's no strategic thought about market positioning or success pathways or goal pillars at all. It basically comes down to "make a good game engine", with all the lack of boundaries and lack of focus that implies. >My initial thought: Be best at one valuable thing first, then expand out from there into adjacent domains, using the momentum accrued from the initial success. (e.g. If you want to build a restaurant empire, you start with one restaurant to dominate one neighborhood and then expand from there - you don't try to build 100 restaurants at once).
imtringued 3y ago
>Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. Yeah but you have a 32 bit data type and a packed 32 bit array, so why not have the same for 16 bit? Not just that, there are also SIMD operations that work better with 16 bit numbers.
throwawayyy9237 3y ago
> "Godot is not production ready" Personally, I find this a refreshing admission.

277 points by mdtrooper 3y ago

The original link in HN is in: https://news.ycombinator.com/item?id=37561762 https://news.ycombinator.com/item?id=37561762

ladberg 3y ago

> Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. I feel like this entirely disregards the caching costs of using >2x more memory in some cases, speed of float32 vs float64 operations on CPU, and potential CPU <-> GPU memory transfers. EDIT: Nvm disregard this comment, I just noticed the existence of: PackedByteArray, PackedInt32Array, PackedInt64Array, PackedFloatArray, PackedDoubleArray Anything set of numbers needed by the GPU or big enough to affect the cache will probably use those arrays.

jackmott42 3y ago
In the context of function parameters at the edge of C# and c++ I don't think it will ever amount to a large amount of memory being wasted. The cache point may be relevant, but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. So maybe not so bad.
- jayd16 3y ago
  >but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. How do you figure? Are you saying there should be no tight loops that hit engine code, none that live in the C#/scripting lifecycle or all tight loops should be rewritten in C++? The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me.
  - badsectoracula 3y ago
    > The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me. As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive the behavior.
    - jayd16 3y ago
      This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints. But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.
      - johnnyanmac 3y ago
        It's such a bizarro world after a bunch of UE discussions to suddenly see people dismiss scripting concerns with "well just write that code in C++. Blueprints is slow". I'm usually the one saying that, but that's as a professional developer who needs to optimize all that stuff (and TBH the blueprint code tends to have some bad performance choices even before discussing the BP perf loss). Hearing people dismiss the performance of something as basic as a raycast with "well just code in C++", while many people (including this founder) say that Godot focuses on simplicity sounds counter-intuitive. So is GDScript a lie for anything slightly intensive (and again, raycast. I'm using "intense" in the loosest of words) and I should simply make my whole game an engine module? But I keep hearing that "I should just try GDScript it's really easy and you come around to it!" Feels like a motte and bailey.
        badsectoracula 3y ago
        What i wrote wasn't making your whole game an engine module (i.e. writing everything in C++) but writing your intensive code in C++ and using scripting (be it blueprints, GDScript or whatever) to drive that intensive code. There is nothing counterintutive in that, it is right in the name of scripting languages: they're meant to script behavior. And the dismissal isn't about having a raycast being slow, but about using too many raycast queries in script to do something reusable that should be in native code in the first place. If your scripting language ends up in your performance profile chances are you are using it wrong. The occasional raycast query in scripts to make a decision is fine, doing thousands of individual raycast queries from scripts is not - if nothing else, make an API that accepts multiple raycast queries at once, performs it in C++ in a single call (so you only get the scripting overhead for that single call) and gives the result back. But IMO if, as mentioned in the article, you are going to make a controller that is to be used by multiple entities in the game, then you should make it in C++ - potentially with script hooks to customize the behavior, if needed.
- lainga 3y ago
  I think part of the problem is that using GDExtension is like a two-way FFI. You can call (C++) extension functions from GDScript, but the same interface and overhead are used to call (lib) Godot functions from the (C++) extension. AFAIK it's not like there's a <godot_impl.h> with engine functions that the compiler could inline. Here's a good example (look, there I am!), although it's a bit old and actually led to perf improvement: https://github.com/godotengine/godot-cpp/issues/1063 https://github.com/godotengine/godot-cpp/issues/1063
gabereiser 3y ago
Yes, however, by the time they fix the dictionary hack glue code as described, PCI bus transfer speeds will have increased (again). I’m a fan of making everything 64bit from an api level, but sometimes you have to work with the right type for the architecture.
deleted 3y ago
[deleted]

3seashells 3y ago

Yet

jmull 3y ago

Strong response. I'm not sure I would have been so generous to the author of the article this is in reply to. But I suppose that's a skill of a successful open source leader -- to turn interactions with critics into productive discussions rather than arguments, and perhaps even turn the critics into supporters. It seems to have been that author who chose the FUD-ful title "Godot is not the new Unity". I guess there are times in life where you face a choice: be fair, reasonable, and intelligent, or... just try to get them clicks. Well, that article got a lot of click. Good job?

kbelder 3y ago
I said this not long ago in a different thread, but after reading this article I want to say it again. I'm very impressed with the management of the Godot project. They seem to be avoiding all the common mistakes and drama that so many projects fall prey to. They're doing everything professionally.
- Lerc 3y ago
  I have contributed a very small amount of code to Godot. In the process of doing so I was very impressed with the entire process. They were very supportive and quick to respond. Overall it was one of the best open-source contribution interactions I have experienced.
JD557 3y ago
> I'm not sure I would have been so generous to the author of the article this is in reply to. But I suppose that's a skill of a successful open source leader -- to turn interactions with critics into productive discussions rather than arguments, and perhaps even turn the critics into supporters. FWIW, reduz (Godot author) and sprudd ("Godot is not the new Unity" author) previously discussed this on Reddit[1], and sprudd was actually sounded pretty nice (the first reply even includes a "and I hope that I wasn't too rude in the article. :)"). Overall, I think the original article was written in good faith, just with a click-baity title (and I imagine reduz thought the same thing). That might have helped to avoid a more angry reply. 1: https://www.reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k16982q/ https://www.reddit.com/r/godot/comments/16lti15/godot_is_not...

json2d 3y ago

"Godot is/is not the new Unity" is a pretty loaded statement, and would mean different things to different folks. This particular discussion focuses on the performance gap between the two engines looking specifically at how raycasts are implemented, and the larger implications from that analysis.

LarsDu88 3y ago

Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on...

hutzlibu 3y ago
"If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on..." Yup .. but maybe not stupidity, but rather a non generic game. In my case I need lots of raycasts, to determine what exactly the player and the enemy bots can see. Basically I have a simulation in 2D (using box2d directly in js as a wasm libary) - and all the bots and the player only (mostly) get information based on raycasts. They have to scan the world and react to that information, which leads to a different result, than the usual approach (cheating). So I am looking forward to get this fixed asap as well and also cannot really consider godot before that. Edit: performance problems with raycasts I had to experience as well, because the roundtrip js to wasm is expensive. I first wrote a WebGPU shader doing only raycasting in my world, but better was modifying box2d (and compiling to wasm) to include a function, that does all my raycasts in one call and returns a big array (or rather a array with pointers to the structs in the internal wasm heap).
- rngname22 3y ago
  If the game is 2D and you can divide space into tiles/blocks and walls/obstacles have their own blocks/tiles (or you can easily establish a grid over your world and determine what cell each actor is in), I wonder if there's way to use BFS in a maze-solving manner to calculate shortest path between a given actor and the target you want to check visibility for, and if the distance in blocks/tiles returned by BFS/pseudo-pathfinding is greater than a direct distance formula calculation between the two blocks/cells then maybe you know there's an obstacle? I guess that requires you to be able to create the network/graph of traversable nodes as well.

marcodiego 3y ago

Of course not. It won't have a draconian license agreement.

26fingies 3y ago

It seems weird to extrapolate where Godot will live in the game development ecosystem from its current performance characteristics for certain operations. It's like trying out Windows 95 and saying "Microsoft isn't going to dominate the PC world because Windows 95 crashes a lot!" Maybe.. but these sorts of technical minutae are not the things that determine winners as far as I can tell.

dundarious 3y ago
“Godot is not the new Unity” is a present tense statement, issued at a time when many studios are considering a hasty and impromptu transition from Unity -- they are looking for a suitable equivalent now, not many years into the future. It's a sensible question about today and the very near future.

gsuuon 3y ago

It sounds like Godot just needs a few more hands on deck to close up a lot of these smaller gaps, as Juan mentions most of the issues are already being discussed or were simply lower priority to fix. Hopefully with the influx of Unity refugees (and potential contributors) they'll be able to quicker ship more of the things they already have on their roadmap. I do think the original article's claim of 'Godot is not the new Unity' is accurate, just not for the architectural reasons claimed. Folks probably shouldn't go into it thinking that Godot will handle every use case just as well as Unity. It hasn't had billions poured into it like Unity, but it is mature and ready for serious games. Plus - open source means you can just get your hands dirty and fix critical (for you) bugs instead of hoping Unity gets around to it.

philipov 3y ago

Offtopic: BDFL is a funny initialism. Although it means Benevolent Dictator For Life, its visual similarity to BOFH evokes a second meaning.

lukebitts 3y ago

Great response, I downloaded Godot because I was looking for a lightweight engine that doesn't take two minutes to load. This seems to explain the reason for the performance, I'm glad its one of their focus

stephc_int13 3y ago

I think this type of discussion can help the design team behind Godot to improve their practices and implementation, in the end it would be very healthy for the gamedev community to have a reliable and performance open-source engine as the "standard" for students, indies and AA projects alike. Godot is better than Unity on many sides, but the internal architecture is coming from a place where they relied too much on naive and inefficient OOP constructs, those can be very hard to optimize later. Performance should not be treated as a second class citizen when creating an engine, there are always solutions but it can be very time consuming to find workarounds to palliate design issues with the engine, it can also be a real motivation killer for a small team when they discover the framerate of their game on older/smaller devices...

kaveh808 3y ago

The killer feature of whatever game engine replaces Unity in developers' hearts and minds is going to be the platform delivery aspect. Once you can press a button and get Win/Mac/Linux/Android/iOS/etc versions of your game built, you're in business. All the higher-level features (3D, ray casting, etc) will be contributed by the community over time.

andrewmcwatters 3y ago
I think you mean lower-level.

johnnyanmac 3y ago

>Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. I believe the issue was less with the sizes of items being passed in and more with the API conforming to work with GDScript first and formost. Returning a dictionary for an operation that has a few float64's feels overkill and doesn't make sense even with an explanation of the available datatypes. >Only a pathological use case is shown, the rest of the API is fine. I wouldn't call raycasting in a full blown engine "pathological". Especially one that touts 3D Secondly, that doesn't inspire confidence. "Don't mind the room on fire, the rest of the house is fine!". The onus is on the engine to prove that, and numbers prevail over words. So far only one part of the conversation has shown that. Even in the next sentence it sounds like they focus on a simple API over performance, and that doesn't fill me with confidence. If Godot isn't focusing on 3D, that is fine but there's so much noise trying to to say otherwise > Eventually, C# will be moved to the universal extension system and this will allow the unifying of the default and .net editors, it is just not the case yet, but its top in the list of priorities I hope so, but there seems to be a trend of various "top priorities" from Godot that have trouble crossing the finish line. That's a reocurring issue even in this response alone: I'm not convinced that performance is a top priority for Godot. And that confidence means everything if the "BDFL" controls what gets into the project proper. >The problem is that, at the C++ level, this function takes a struct pointer for performance. But at the language binding API this is difficult to expose properly. This is very old code (dating to the opensourcing of Godot) and a Dictionary was hacked-in to use temporarily until something better is found Yup... so 10 years later that hack stays in and modern programmers come cross it. This isn't even a critique, that's simply the nature of legacy code. Unreal has an entire part of a forced namimg scheme (the compiler won't let you run the game without conforming) that can only be explained as "well we wanted to do this in the 90's but we slowly took it out sp it's not relevant today". But if it took 10 years for someone to do more than a few dozen raycasts a frame, it says more about the battletesting than any deep dive. It goes back to my confidence above. >, you need to create a C# version of a C++ instance as an adapter... Why is it troublesome? because C# has a garbage collector and C++ does not. slight nitpick: while garbage collection is annoying, you technically do have a built in way to disable it in certain regions, as well as the option in later versions to have unmanaged blocks of code. I'm not saying this is easy to do, but it is something that developers much smarter than me in c# have gotten around. I know c# bindings was a relatively recent endeavor so I'm not going to give it too much flak > Godot containers don't work like STL containers. Because they are used mainly to pass data around, they are allocated once and then kept via reference counting. 1) reference counting implies some sort of automated memory free-ing scheme. 2) That doesn't necessarily address potential issues of inefficiently allocating memory and keeping it contiguous. But I won't talk much on that because I'd need to first read more on the engine's memory allocating schemes first. > Godot uses far more optimized containers that are not directly exposed to the binder API. Okay, but why? Someone wanting to use C# or c++ or whatever script extension that isn't GDScript wants those optimized containers. Does it go back to the earlier quote of "it's difficult to get right and no one wanted it"? >As a result, we created a special path for GDScript to call more efficiently. okay, and the link is... an open issue on Github made 2 months ago, with no additional comments or discussions. Simply a request from a code owner. I don't know if this conversation is simply happening in IRC/chat, but it's unusual given how much other activity I have seen in other PR's/proposals (recent and from years prior). Was this the best reassurance that they are addressing performance? --------- I don't mean to sound like a downer, but I feel the article is overall missing the forest for the trees. I've read about several different kinds of devs from years prior talk about how they passed on Godot because they hit hitch after hitch once they were doing something slightly advanced. a dismissal of "this is a pathological use case" sounds fine in a vacuum, but it sounds like this has been a long standing issue, and priorities simply weren't on smoothing out such hitches. I'm not saying they should have listened to those devs, but I think the most frustrating thing is that I don't know what or who Godot wants to service. So far it sounds like they want to have all the cake, but currently are also low-key fine being a hobbyist 2D engine that can maybe do some simple 3D stuff. Which again, is fine. But that's not what it sounds like Godot is selling. It unfortunately reminds me a lot of Unity, both on the outside (yeah, having 2 unsupported netcode solutions with a 3rd in pre-alpha isn't a good look) and within the company itself. I'll quote some part of a post from the creator of Rimworld, who had similar evaluation and conclusions over 5 years ago: >There's obviously a tremendous amount of technical talent going into Godot, but from what I can tell there's no strategic thought about market positioning or success pathways or goal pillars at all. It basically comes down to "make a good game engine", with all the lack of boundaries and lack of focus that implies. >My initial thought: Be best at one valuable thing first, then expand out from there into adjacent domains, using the momentum accrued from the initial success. (e.g. If you want to build a restaurant empire, you start with one restaurant to dominate one neighborhood and then expand from there - you don't try to build 100 restaurants at once).

imtringued 3y ago

>Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. Yeah but you have a 32 bit data type and a packed 32 bit array, so why not have the same for 16 bit? Not just that, there are also SIMD operations that work better with 16 bit numbers.

throwawayyy9237 3y ago

> "Godot is not production ready" Personally, I find this a refreshing admission.