8 ms·

The anatomy of a Godot API call

219 points by amitmathew 3y ago

anothernewdude 3y ago
Sounds a lot like Unity to me.
- hiccuphippo 3y ago
  Yes, I was under the impression that Unity was also slow and people who use it don't particularly care because it's still fast enough for their purposes. But with so many eyes on Godot now, I can only see it getting better.
  - debacle 3y ago
    Unity just released first class support for ECS which will greatly speed up the engine for most users.
- bowsamic 3y ago
  Not really. Unity has great performance
- deleted 3y ago
  [deleted]
- spookie 3y ago
  I'm also concerned with the approach the dev is taking on their game. That's a lot of raycasts.
  - johnnyanmac 3y ago
    They described it as so: >I'm making a top down 2D game and Godot's too slow to handle my character controllers at 120fps without a lot of hacks. In Unity they run in 2ms. It's not just The Last of Us that this matters to. >The controller gets used for NPCs too, so I can have quite a few of them on screen at once. It's got quite a complicated substepped movement and collision response system which does lots of ray and shape casts. A typical frame may end up around 500. Even if its not efficient for their specific game, a few hundred raycasts should not be taking nearly a millisecond to perform. No wonder there's so much work to do to get Godot to be 3D ready.
    - spookie 3y ago
      Oh yeah, for sure. I've developed some VR demos in Godot and it seemed quite capable. But, I was never calling this many raycasts from the CPU side of things. Never had an excuse to do so. I'm just saying this because I really think Godot is able to produce good 3D experiences as of now. I appreciate the criticism, and of course would like it to get better. But, I don't know, something tells me the dev could take another approach in the meantime. It seems the post started some ongoing conversations with the devs to solve this issue, so that's nice.
      - johnnyanmac 3y ago
        > I'm just saying this because I really think Godot is able to produce good 3D experiences as of now I guess I'll see for myself next year as I work on a 3D title. But my current research doesn't make me optimistic. I am very much ready to help contribute to address these sorts of issues if/when I run into them. But I want to actually contribute, not just take my ball, fork, and redesign the engine. If I get this much friction introducing optimizations, and/or am unable to find out who/where is working on such things, I don't know what to say.
zerr 3y ago
How usable is Godot's native/C++ API for actual game programming, akin to Unreal? (never mind the hot reloading).
- janosdebugs 3y ago
  It's a lot clunkier than Unreal. You'll have to build a .so/.dll using scons or cmake (good luck finding a CMakeLists.txt that actually works) and you have to register all types manually. You will also not be able to work around the issues with the APIs mentioned in the article around dictionaries AFAIK. There is no header tool and no autogenerated code for your classes. Oh, and reloading the DLL on Windows requires an editor restart. Plus I haven't found a good way to debug load failures either apart from starting the editor from a console window. I ended up sticking to GDScript in the end, but the typing system is very basic and the code can get very messy quickly. Plus, as far as I could tell, there is a race condition between signals and the process function, but I need to debug that more thoroughly to be sure.
  - rsstack 3y ago
    Are you using call_deferred from your signal handlers?
    - janosdebugs 3y ago
      No. Should I?
  - lainga 3y ago
    I used GDExtension extensively on a previous project, and I ended up just installing the .so, launching Godot headless, and immediately exiting, as part of my build script. To catch anything that might break extension loading.
- badsectoracula 3y ago
  TBH if i was making a game using Godot i'd just be modifying the engine itself to add any "heavy" functionality (the nodes system would most likely help here) and expose custom high level APIs to GDScript. IMO scripting languages should be used to script the behavior of a game: i.e. tell the engine what to do, not how to do it (which should be written in native code). From the subreddit submission about this blog post (linked in the post itself) it seems this is something some people already do. The GDExtension API seems something to use only if you want to write C++ extensions/plugins to be usable by other people, but i don't see much of a point in restricting yourself to it if you are making your own games.
robertlagrant 3y ago
I'm not sure I understood everything here, but I think the tl;dr is that Godot has a powerful new rendering technique called "foreshadowing".
- xg15 3y ago
  cue theatrical thunder and lightning
- deleted 3y ago
  [deleted]
- panzagl 3y ago
  That why it seems slow- if you want the gun to fire in act 2, you have to show it in act 1.
  - meepmorp 3y ago
    Oh, now I get it - they named the engine after the play, "Waiting for Mr Chekhov."
- CobrastanJorji 3y ago
  It's new in Godot 4.1.1. When enabled, if two opaque polygons are between the user and a light source, the shading can reflect their relationship.
gustavus 3y ago
The thesis of the article appears to be > However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch. If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly quickly if people start flocking to a tool.
- guideamigo_com 3y ago
  Javascript still remains slow. Java is fast enough that it doesn't matter. However, no one will use Java to build Linux kernel.
  - foderking 3y ago
    JavaScript isn't slow
  - viraptor 3y ago
    JavaScript is very fast if you want/need it to be. Emscripten/asm.js approach is in the same category as native for example. Your simple code won't be too fast, but not all code needs to be. Also, have you heard of JavaOS? https://en.m.wikipedia.org/wiki/JavaOS https://en.m.wikipedia.org/wiki/JavaOS
  - wiseowise 3y ago
    Define slow. JS is plenty fast for a dynamic language.
  - pjmlp 3y ago
    Mostly because Linus won't accept anything other than C on his beloved kernel. Sun had experimental support for Java drivers on Solaris, Android has support for writing drivers in Java, Android Things only allowed for Java written drivers.
- deleted 3y ago
  [deleted]
- 3y ago
karaterobot 3y ago
This matches up with what I've heard from people with experience in both Unity and Godot. As convenient as it would be if Godot was ready to swap in for Unity, it's got some significant issues that would make that difficult to unfeasible for many people.
- CodeCompost 3y ago
  Nobody suggested that Godot was on par with Unity. The hope is that resources get diverted away from Unity towards Godot so that it can develop into a top-notch game engine. It's time to stop waiting and start working on Godot.
  - karaterobot 3y ago
    I've seen comments here on HN that make me believe some people think Godot is on par with Unity, or that it will be soon. The title of the linked article also acknowledges that some people in the world at least have a misapprehension to that effect.
    - rhtgrg 3y ago
      All you have to do is look at games made with Unity and compare with games made with Godot. The proof, as they say, is in the pudding.
  - fluxem 3y ago
    You clearly weren't on reddit. Everyone there will urge you to switch to Godot even though your game is almost finished and Godot doesn't have feature parity. It reminds me of the linux debate: - A: I hate Windows telemetry - B: Then switch to linux. It's as good - A: But it doesn't have a good video editor. - B: You should develop your own video editor and share it with the community - A: Ughh... I just want to edit my videos... I use linux and love it, but there are users who need Windows or Unity.
    - sockaddr 3y ago
neonsunset 3y ago
So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for Godot and C# ecosystems, and more emphasis on the ability to use very rich selection of libraries written for .NET would not hurt either.
- xmonkee 3y ago
  I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.
  - janosdebugs 3y ago
    In GDScript you kind of get code completion. Kind of. 50% of the time it doesn't give anything useful.
  - jackmott42 3y ago
    If you use C# then you can use Visual Studio or Rider or VSCode and get that
    - deleted 3y ago
      [deleted]
  - rsstack 3y ago
    You have to make sure you opt into the type-safe GDScript. It's not easy. There's an IDE feature that highlights lines that are not type-safe but the default color is a hard-to-see grey. I changed it to be red ("Line Number Color" is the one for untyped lines), and then fixed all typing issues. Then, autocomplete works as does cmd+click to go to definition.
  - TazeTSchnitzel 3y ago
bakugo 3y ago
> That’s right, our raycast is returning an untyped dictionary. This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?
- jay_kyburz 3y ago
  There are red flags everywhere. I think Godot has this really nice looking editor, and the nodes look nice, but the engineering foundations are just not there. I think a lot of people start Godot projects but not many finish them because they run into these WTF issues.
  - syntheweave 3y ago
    Godot has always made a point of prioritizing features and simplicity of modification over speed. In a lot of instances it does just ignore low-hanging opportunities for performance because the simple thing works and needs less code, which isn't always useful, but means it's easier to replace. Like, my reaction to the blogpost is, "oh, OK, if raycasting nodes are fast, and I need a lot of raycasts, then worst case, I will introduce a custom node designed to do 300 raycasts in one call or whatever." The corresponding WTF in Unity tends to be "sorry, no code access, SOL" so the inclination of a Unity dev is that they need as direct an API as possible and it needs to be as fast as possible. There are tremendous numbers of shipped Unity games that don't trust the engine to do what it's supposed to and just use it as a HAL, and so there's a culture clash in approach which makes Godot the wrong tool for a dev that wants that kind of system.
- Narishma 3y ago
  Presumably because GDScript doesn't support structs.
  - nextaccountic 3y ago
    In this sense it's like Lua right? And people don't complain (much) about using Lua in gamedev
  - 3y ago
Waterluvian 3y ago
I tried using Godot for Web game toy projects and unfortunately the base file size is like 12MB and closer to 40MB if you use C#. I think Unity was like 3MB with C# Not a big deal for a lot of cases. Don’t let it deter you. But for my specific target it was a problem. To be honest I’m not sure how Unity can be so small. Does it compile the C# or something avoiding the need for a beefy runtime?
- Hamcha 3y ago
  Dunno if it was your case but yes, Unity has had AOT compilation since forever with both ILCPP and (more recently) Burst.
- amitmathew 3y ago
  There's a good post on Reddit of a dev creating small web exports using custom builds: https://old.reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k15rip4/ https://old.reddit.com/r/godot/comments/16lti15/godot_is_not....
  - deleted 3y ago
    [deleted]
  - Waterluvian 3y ago
    Thanks. I first misread the C++ part but it sounds like they have some way of paring down the runtime when using GDScript. I’ll have to seek that out.
fidotron 3y ago
When I first encountered Unity it was because there were performance problems on a Japanese only version of Bejeweled built with it and they needed someone to fix it. It was a classic: creating huge numbers of new objects for particle effects hammering the gc, and the fill rate of the then cutting edge device GPUs not being a match for their screen resolutions. Unity took several years, and a huge amount of investment, along with improvements in the wider ecosystem, before performance became much less of a concern for normal developers. A lot of the work they did around C# usage to achieve this is really surprisingly intense. In the near future I seriously think 2D (and some subset of simple 3D) game devs would be better off looking at Defold, and if you want to make immersive 3D just bite the bullet and move to Unreal. These days cost of preparing assets drastically exceeds coding time anyway.
- Fraterkes 3y ago
  What advantage do you think defold has over godot for 2d (apart from currently seemingly being more polished)? Theres lots of people complaining in this thread that GDscript is not serious enough as an engine language, but Godot at least has a decent c++ api. Defold only seems to support Lua (although you can extend the engine with other languages afaik).
  - fidotron 3y ago
    Bluntly, getting too hung up on languages is procrastination. Lua is more than fine. (GDScript isn't actually that bad, just completely esoteric). Similarly I wouldn't get hung up on Blueprints or C++ when worrying about Unreal, partly because their C++ is so particular it's extreme. Defold is basically a pile of interesting simple subsystems, especially around game logic, that in combination become surprisingly powerful, and the experience of the devs shows. It is one of those tools that even if you never use it again some of the ideas stay with you.
    - Fraterkes 3y ago
      I actually agree with you about the language-stuff. I thought your parent-command was essentially making some kind of performance-based comparison between defold and godot, which is why I mentioned Lua. Defold seems interesting, but unlike Heaps and Godot it hasn't yet been used for any game I've heard of. (additionaly I don't really agree that Gdscript is particullary esoteric. It's basically python, with a bunch of very obvious engine-api stuff added on top. Language-wise theres very little to learn there, which is great)
MrLeap 3y ago
I didn't read anything that indicated a hard block to creating new methods that bypass the binding layer? All the layers are open source. Unity has their fair share of bolted on methods with a "NonAlloc" suffix. Seems obvious to prioritize raycasts / intersection / collision code to receive this treatment. I've noticed a few lower lift things I'd like to submit PR's for, just to see how/if I can help.
- johnnyanmac 3y ago
  I hear the recommended approach is to write your own module in the engine level code. But that means you need to compile the engine everytime you change your module. Possible, but you are losing a lot of iteration unless you are experienced in rolling in your own physics. Nothing stop you from modifying the engine code, but the problem lies in the binding layer, not the engine perormance (as you see in the blog, the raw engine performance for a raycast is about the same as Unity). That's a bit trickier to fix without intimate knowledge of such bindings, and you'll likely break a lot of GDScripting support (so by extension, c# scripting) in the process.
zamalek 3y ago
This dictionary stuff is truly bizarre. I have been playing around with GDExtension and Rust - specifically the meshing interface. This dictionary stuff shows up there. Not only couldn't I figure out why (the GDScript angle makes sense in hindsight), but it also makes the API virtually impossible to discover: you have to resort to reading things up in the documentation. As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.
- Rapzid 3y ago
  Yeah, my take is the API should be made clean of this stuff and a shim layer added on top for GDScript to consume.
- RobKohr 3y ago
  If you are using Rust, you should check out https://bevyengine.org https://bevyengine.org which is a rust based game engine with a focus on ECS
droptablemain 3y ago
I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project. Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.
- Lucasoato 3y ago
  They should remember that even Unity had to deprecate the Boo language to go forward :)
  - mattigames 3y ago
    Both Boo language and UnityScript were deprecated (the later was oftenly mislabeled as JavaScript, creating quite a confusion between newbies)
  - dandellion 3y ago
    Not sure Unity is a good role model... Also, having used both Boo back in the day and GDScript in Godot more recently, I'd say that one big difference between the two is that Boo was really bad, and GDScript is actually pretty good.
    - eddythompson80 3y ago
      What's wrong with Unity from a technical prospective not marketing/business prospective?
      - cfgyuiikhg 3y ago
        It was fat and glitchy from the get go.
      - johnnyanmac 3y ago
        Unity got a stigma for delivering half baked features and dropping support for existing features without a replacement. The epitome of this was where in Netcode, where I believe they had no officially supported solution despite the engine having 2 different packages which were both half-baked, all while the DOTS variant was far from release. I don't think Godot should go that route.
Dudester230602 3y ago
If Godot has a first-class C# support then why `Godot.Collections.Dictionary` exists when there is already `System.Collections.Generic.Dictionary`? https://learn.unity.com/tutorial/lists-and-dictionaries https://learn.unity.com/tutorial/lists-and-dictionaries
- worble 3y ago
  https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/c_sharp_collections.html https://docs.godotengine.org/en/stable/tutorials/scripting/c... > The main difference between the .NET collections and the Godot collections is that the .NET collections are implemented in C# while the Godot collections are implemented in C++ and the Godot C# API is a wrapper over it, this is an important distinction since it means every operation on a Godot collection requires marshaling which can be expensive especially inside a loop. > Due to the performance implications, using Godot collections is only recommended when absolutely necessary (such as interacting with the Godot API). Godot only understands its own collection types, so it's required to use them when talking to the engine.
- TazeTSchnitzel 3y ago
  Bridging collection types between languages is never easy. Apple only manage it because they control the compiler and runtime on both sides, and that still comes with performance pitfalls. Allowing both to exist and telling people when to use one or the other is not only easier to implement, it has more predictable performance and gives the user more control.
TheMagicHorsey 3y ago
Curious if anyone here has tried Bevy (Rust game engine). Godot has a beautiful editor and great tooling for a free engine ... but I worry about the choice of C# and GDScript as the expected way for devs to interact with the project (what if performance is a concern or you need to develop some low-level features). Another post in this thread said the C++/native interface was not great and difficult to work with. And C++ even in the best of times is not my favorite thing to work in.
- deleted 3y ago
  [deleted]
- Daegalus 3y ago
  I looked into this, but it seems most gamedev communities I asked, say Bevy isnt great, and everyone seems to be recommending Fyrox instead. No clue if it actually is, just parroting what I have been told. Either way, I don't think either is ready for prime time as its still early development.
- MegaDeKay 3y ago
  Bevy came up on /r/rust_gamedev a little while back. The general sentiment seemed fairly negative, with comments that you either do things Bevy's way or the highway. https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_bevy_the_best_option_for_a_rust_based_game/ https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...
  - johnnyanmac 3y ago
    A lot of the consensus there seems to come down to 1. the engine isn't stable and has breaking updates (why does that sound familiar...) 2. ECS is hard to learn and Bevy is too strict with ECS. It's hard in the same way OOP is hard, I guess. But it's just that: a paradigm. It's harder to google because ECS is a specific paradigm for applications that want to follow data oriented design. If you don't care about that, then you lose all that benefit and google-ability for not much gain. I guess that's just the state of FOSS game engines right now. People basically just want Unity/Unreal without the copporate overlords. But while oppressive, they also did fund the engineers to make those solutions so attractive to begin with. You'll inevitably get your hands dirty if you go of those smooth UE/Unity roads. Especially if you're choosing an up and coming language like Rust on top of all things.
jayd16 3y ago
Funny that they have to use a custom dictionary setup when C# supports dynamic types. >Mixing fast and slow APIs as discussed above would leave us with headaches for decades Meh. Unity has allocating and "NonAlloc" methods, even on the raycast API in question here. It's a really minor issue. Sounds like Godot will need more time to bake before its perfect but we already knew that.
- deleted 3y ago
  [deleted]
rybosworld 3y ago
One thing that stands out as odd to me is the small selection of really "good" game engines. Unreal seems to have the most features and the steepest learning curve. Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains. Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many features as the other two and the commitment to GDscript seems... odd. If I were picking a game engine today, it'd be between Unreal and Godot, but I'm not sure I'd feel great about either choice.
- jay_kyburz 3y ago
  I'm thinking about going back to 2d. If Factorio and Slay The Spire can be smash hits in 2d, perhaps I can as well :) I'm a fan of Love but I have to admit the amount of Lua I wrote for just my prototypes did start to get a little scary. I might have a play with raylib.
  - cmovq 3y ago
    Interestingly both of the games you mentioned use custom engines. I think people overestimate the difficulty of rolling out your own 2D engine.
  - mnk47 3y ago
    If you like or don't mind using Go, check out Ebiten as well. I think it's similar to Raylib in spirit, but it also supports Nintendo Switch, iOS and Xbox. IIRC it uses native graphics APIs (Metal for MacOS, DirectX for Windows) while Raylib just uses OpenGL.
- zzo38computer 3y ago
  I think that which game engine will be "good" depend on manyu things including what kind of game, what computer system, FOSS, licensing, other features, etc.
- jayd16 3y ago
  It really depends on what your game/team needs. If you're trying to make a match-3 then Unreal is maybe not the best choice. If you're trying for competitive cutting edge graphics in an engine that is mostly done so you can actually focus on the graphics, then Unreal is top of list. I think its probably better to look at Unreal as state of the art but licensable. Other big game companies have cutting edge engines but they're proprietary and not available to license.
timmytokyo 3y ago
>Unity has spent the last five years working on speeding up their scripting with crazy projects such as building two custom compilers, SIMD maths libraries, custom collections and allocators, and of course the giant (and very much unfinished) ECS project. It’s been their CTO’s primary focus since 2018. That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forums for over a year. (He used to be quite active on Unity's forums.) The entire leadership of the ECS/DOTS team has resigned.
- pests 3y ago
  > the entire leadership of the ECS/DOTS team has resigned Recently because of the drama or unrelated? That’s sad to hear as I was very excited on that effort.
  - timmytokyo 3y ago
    I don't think it was due to the recent drama. (Although who knows, maybe they knew what was coming.) Mike Acton and Andreas Fredriksson left back in March 2023 I think. They posted to twitter. EDIT: It was in May.
  - johnnyanmac 3y ago
    Not recently, but there was a steady drain of talent. The two heads of the DOTS initiative were gone by May of this year and the CTO, and the last original Founder of Unity, and arguably largest champion of DOTS, silently stepped down in April when introducing the new CTO. Johacim's official status is apparently "sabbatical" (I'm sure he owns way too much stock and other sway to be hoisted out the traditional way).
- johnnyanmac 3y ago
  He wasn't just active on forums, he was actively developing on Unity itself, in the weeds with all the other engineers. He arguably got a bit too involved at times, but it was very admirable for a "executive" who could retire on the interest of his shares in Unity to still take so much care in the product. I can't say that about many 10+ year old company founders, let alone ones that went public. And of course the moment he silently stepped out, Unity rolls all this BS out in less than 6 months. Joe wasn't just champion of the tech, he was likely one of the last of the old guard up top keeping things focused on the actual product instead of how to extract infinite monies.
generichuman 3y ago
Response to the article from godot dev: https://reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k16982q/ https://reddit.com/r/godot/comments/16lti15/godot_is_not_the... TL;DR is that they know this & working on it
- lainga 3y ago
  I might throw in a bit of gossip here - many who were following the development of GD 4 last year (myself included as I was using it :) ) thought it was kind of rushed out in time for GDC 2023 in March. And immediately after GDC, Godot 4.1 followed (and now rc's for 4.2), with lots of fixes. So on the one hand, yeah, 4.0 lacks polish, and I certainly have felt some strong feelings working with GDExtension... but I also believe there was a reason for that, and I believe the team when they say they're working on improvements now
reactordev 3y ago
Never underestimate the power of open source game developers. If we could do it with XNA, we’ll do it with Unity. If we have to tear the place down and rebuild it on a rust il-compliant vm instead of mono, we damn sure will [0] [0] https://crates.io/crates/netcorehost https://crates.io/crates/netcorehost *edit* everything in the article is on point. Function pointers as binding glue sucks. There’s tons of optimizations to be done in the engine for sure. However, having a robust C# api is on top of list since it was introduced. I do think Godot 5 should make a hard choice and just support C# instead of GDScript.
Scalene2 3y ago
So, what I'm gathering is if you're bothered by the Unity (either a developer, publisher, gamer) developments, and wish Godot was a better alternative than it is, contributing to the project (by donating either time or money) is probably necessary to get there.
Madmallard 3y ago
[flagged]
KMcPheeters 3y ago
When the performance of Godot's physics engine has been mentioned before I've seen https://github.com/godot-jolt/godot-jolt https://github.com/godot-jolt/godot-jolt pointed to as a drop in more performant solution. Haven't tried it in a project yet myself
CreepGin 3y ago
The biggest problem for me in moving to Godot is the editor tooling. I find the @tool and EditorPlugin workflow to be very finicky. Editor restarts were needed to refresh/correct changes from @tool scripts. And a lot of what I needed to do in the scene view (context-free) required hacky solutions. Not to mention, they changed a lot of related APIs in Godot 4, most of what I google are still from Godot 3 and don't work in Godot 4 (no backward compatibility). That said, I'm still enjoying Godot, the only fun part in the past week.
- 0x_rs 3y ago
  It's made great progress in this regard since 3.x, and it's an an extremely powerful system, but dealing with some @tool intricacies can very quickly make you waste days trying to figure out what's going on. My greatest annoyance regrettably lies in one of Godot's most convenient features, custom resources, that are so extremely tedious to use with @export from the editor in any meaningful, useful way that I've personally given up on it for the time being, their lifecycles even avoiding _init() cross well beyond the bug behavior territory and GDscript permits no alternative approaches code-wise that aren't absolute monstrosities of jerryrigged variadic functions (not supported except for a few API calls resembling them) jumping one into another or endless walls of parameters you get lost into.
wkat4242 3y ago
It's not Godot if you don't have to wait for something.
tacotacotaco 3y ago
I am so glad that Juan et al are leading Godot and not me because frankly I would be offended by all of this. It hasn’t been a week since the Unity fiasco and all I see is post after post from people complaining that Godot isn’t c# enough. This is like showing up for dinner and insulting cooking before you’ve even tasted the meal. There are definitely opportunities to improve Godot but there are more constructive ways to contribute than drawing a new floor plan for the house on the table cloth while the first course is being served. Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.
- johnnyanmac 3y ago
  >Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#. This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum, simply due to how the c++ and C#/GDSctipt/GDExtension layers talk. Take this as a warning, not a dismissal. Unity went down this exact path and we see how viable it became for large scale game development. I sympathize with you for those who are outright trashing the GDScript for being a scipting language, and I do wish those arguments would die down (it's simply language wars). But there are definitely fixes here that would improve all diferent bindings, even if they never diverged (which IMO, they should). >This is like showing up for dinner and insulting cooking before you’ve even tasted the meal cooking is subjective (mostly), performance is not. This is more like asking why the cook is trying to carefully drain out the water with a loose lid instead of using a strainer. Sure, it may work for the cook and they've done it all this time, but I'd rather give a safer solution that won't burn them long term, or spill out excess food.
  - tacotacotaco 3y ago
    > This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Better memory utilization, better processor performance[1], and no more garbage collection stutters. Oh right, it’s not your preferred language. I’d rather we all just make games instead of fighting language wars, but seeing so many of these posts in the last week makes the community feel hostile. [1] https://programming-language-benchmarks.vercel.app/rust-vs-csharp https://programming-language-benchmarks.vercel.app/rust-vs-c...
homarp 3y ago
reply from Juan Linietsky (BDFL of Godot) https://gist.github.com/reduz/cb05fe96079e46785f08a79ec3b0ef21 https://gist.github.com/reduz/cb05fe96079e46785f08a79ec3b0ef... discussed here https://news.ycombinator.com/item?id=37598985 https://news.ycombinator.com/item?id=37598985

219 points by amitmathew 3y ago

anothernewdude 3y ago

Sounds a lot like Unity to me.

hiccuphippo 3y ago
Yes, I was under the impression that Unity was also slow and people who use it don't particularly care because it's still fast enough for their purposes. But with so many eyes on Godot now, I can only see it getting better.
- debacle 3y ago
  Unity just released first class support for ECS which will greatly speed up the engine for most users.
bowsamic 3y ago
Not really. Unity has great performance
deleted 3y ago
[deleted]
spookie 3y ago
I'm also concerned with the approach the dev is taking on their game. That's a lot of raycasts.
- johnnyanmac 3y ago
  They described it as so: >I'm making a top down 2D game and Godot's too slow to handle my character controllers at 120fps without a lot of hacks. In Unity they run in 2ms. It's not just The Last of Us that this matters to. >The controller gets used for NPCs too, so I can have quite a few of them on screen at once. It's got quite a complicated substepped movement and collision response system which does lots of ray and shape casts. A typical frame may end up around 500. Even if its not efficient for their specific game, a few hundred raycasts should not be taking nearly a millisecond to perform. No wonder there's so much work to do to get Godot to be 3D ready.
  - spookie 3y ago
    Oh yeah, for sure. I've developed some VR demos in Godot and it seemed quite capable. But, I was never calling this many raycasts from the CPU side of things. Never had an excuse to do so. I'm just saying this because I really think Godot is able to produce good 3D experiences as of now. I appreciate the criticism, and of course would like it to get better. But, I don't know, something tells me the dev could take another approach in the meantime. It seems the post started some ongoing conversations with the devs to solve this issue, so that's nice.
    - johnnyanmac 3y ago
      > I'm just saying this because I really think Godot is able to produce good 3D experiences as of now I guess I'll see for myself next year as I work on a 3D title. But my current research doesn't make me optimistic. I am very much ready to help contribute to address these sorts of issues if/when I run into them. But I want to actually contribute, not just take my ball, fork, and redesign the engine. If I get this much friction introducing optimizations, and/or am unable to find out who/where is working on such things, I don't know what to say.

zerr 3y ago

How usable is Godot's native/C++ API for actual game programming, akin to Unreal? (never mind the hot reloading).

janosdebugs 3y ago
It's a lot clunkier than Unreal. You'll have to build a .so/.dll using scons or cmake (good luck finding a CMakeLists.txt that actually works) and you have to register all types manually. You will also not be able to work around the issues with the APIs mentioned in the article around dictionaries AFAIK. There is no header tool and no autogenerated code for your classes. Oh, and reloading the DLL on Windows requires an editor restart. Plus I haven't found a good way to debug load failures either apart from starting the editor from a console window. I ended up sticking to GDScript in the end, but the typing system is very basic and the code can get very messy quickly. Plus, as far as I could tell, there is a race condition between signals and the process function, but I need to debug that more thoroughly to be sure.
- rsstack 3y ago
  Are you using call_deferred from your signal handlers?
  - janosdebugs 3y ago
    No. Should I?
- lainga 3y ago
  I used GDExtension extensively on a previous project, and I ended up just installing the .so, launching Godot headless, and immediately exiting, as part of my build script. To catch anything that might break extension loading.
badsectoracula 3y ago
TBH if i was making a game using Godot i'd just be modifying the engine itself to add any "heavy" functionality (the nodes system would most likely help here) and expose custom high level APIs to GDScript. IMO scripting languages should be used to script the behavior of a game: i.e. tell the engine what to do, not how to do it (which should be written in native code). From the subreddit submission about this blog post (linked in the post itself) it seems this is something some people already do. The GDExtension API seems something to use only if you want to write C++ extensions/plugins to be usable by other people, but i don't see much of a point in restricting yourself to it if you are making your own games.

robertlagrant 3y ago

I'm not sure I understood everything here, but I think the tl;dr is that Godot has a powerful new rendering technique called "foreshadowing".

xg15 3y ago
cue theatrical thunder and lightning
deleted 3y ago
[deleted]
panzagl 3y ago
That why it seems slow- if you want the gun to fire in act 2, you have to show it in act 1.
- meepmorp 3y ago
  Oh, now I get it - they named the engine after the play, "Waiting for Mr Chekhov."
CobrastanJorji 3y ago
It's new in Godot 4.1.1. When enabled, if two opaque polygons are between the user and a light source, the shading can reflect their relationship.

gustavus 3y ago

The thesis of the article appears to be > However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch. If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly quickly if people start flocking to a tool.

guideamigo_com 3y ago
Javascript still remains slow. Java is fast enough that it doesn't matter. However, no one will use Java to build Linux kernel.
- foderking 3y ago
  JavaScript isn't slow
- viraptor 3y ago
  JavaScript is very fast if you want/need it to be. Emscripten/asm.js approach is in the same category as native for example. Your simple code won't be too fast, but not all code needs to be. Also, have you heard of JavaOS? https://en.m.wikipedia.org/wiki/JavaOS https://en.m.wikipedia.org/wiki/JavaOS
- wiseowise 3y ago
  Define slow. JS is plenty fast for a dynamic language.
- pjmlp 3y ago
  Mostly because Linus won't accept anything other than C on his beloved kernel. Sun had experimental support for Java drivers on Solaris, Android has support for writing drivers in Java, Android Things only allowed for Java written drivers.
deleted 3y ago
[deleted]
3y ago

karaterobot 3y ago

This matches up with what I've heard from people with experience in both Unity and Godot. As convenient as it would be if Godot was ready to swap in for Unity, it's got some significant issues that would make that difficult to unfeasible for many people.

CodeCompost 3y ago
Nobody suggested that Godot was on par with Unity. The hope is that resources get diverted away from Unity towards Godot so that it can develop into a top-notch game engine. It's time to stop waiting and start working on Godot.
- karaterobot 3y ago
  I've seen comments here on HN that make me believe some people think Godot is on par with Unity, or that it will be soon. The title of the linked article also acknowledges that some people in the world at least have a misapprehension to that effect.
  - rhtgrg 3y ago
    All you have to do is look at games made with Unity and compare with games made with Godot. The proof, as they say, is in the pudding.
- fluxem 3y ago
  You clearly weren't on reddit. Everyone there will urge you to switch to Godot even though your game is almost finished and Godot doesn't have feature parity. It reminds me of the linux debate: - A: I hate Windows telemetry - B: Then switch to linux. It's as good - A: But it doesn't have a good video editor. - B: You should develop your own video editor and share it with the community - A: Ughh... I just want to edit my videos... I use linux and love it, but there are users who need Windows or Unity.
  - sockaddr 3y ago

neonsunset 3y ago

So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for Godot and C# ecosystems, and more emphasis on the ability to use very rich selection of libraries written for .NET would not hurt either.

xmonkee 3y ago
I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.
- janosdebugs 3y ago
  In GDScript you kind of get code completion. Kind of. 50% of the time it doesn't give anything useful.
- jackmott42 3y ago
  If you use C# then you can use Visual Studio or Rider or VSCode and get that
  - deleted 3y ago
    [deleted]
- rsstack 3y ago
  You have to make sure you opt into the type-safe GDScript. It's not easy. There's an IDE feature that highlights lines that are not type-safe but the default color is a hard-to-see grey. I changed it to be red ("Line Number Color" is the one for untyped lines), and then fixed all typing issues. Then, autocomplete works as does cmd+click to go to definition.
- TazeTSchnitzel 3y ago

bakugo 3y ago

> That’s right, our raycast is returning an untyped dictionary. This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?

jay_kyburz 3y ago
There are red flags everywhere. I think Godot has this really nice looking editor, and the nodes look nice, but the engineering foundations are just not there. I think a lot of people start Godot projects but not many finish them because they run into these WTF issues.
- syntheweave 3y ago
  Godot has always made a point of prioritizing features and simplicity of modification over speed. In a lot of instances it does just ignore low-hanging opportunities for performance because the simple thing works and needs less code, which isn't always useful, but means it's easier to replace. Like, my reaction to the blogpost is, "oh, OK, if raycasting nodes are fast, and I need a lot of raycasts, then worst case, I will introduce a custom node designed to do 300 raycasts in one call or whatever." The corresponding WTF in Unity tends to be "sorry, no code access, SOL" so the inclination of a Unity dev is that they need as direct an API as possible and it needs to be as fast as possible. There are tremendous numbers of shipped Unity games that don't trust the engine to do what it's supposed to and just use it as a HAL, and so there's a culture clash in approach which makes Godot the wrong tool for a dev that wants that kind of system.
Narishma 3y ago
Presumably because GDScript doesn't support structs.
- nextaccountic 3y ago
  In this sense it's like Lua right? And people don't complain (much) about using Lua in gamedev
- 3y ago

Waterluvian 3y ago

I tried using Godot for Web game toy projects and unfortunately the base file size is like 12MB and closer to 40MB if you use C#. I think Unity was like 3MB with C# Not a big deal for a lot of cases. Don’t let it deter you. But for my specific target it was a problem. To be honest I’m not sure how Unity can be so small. Does it compile the C# or something avoiding the need for a beefy runtime?

Hamcha 3y ago
Dunno if it was your case but yes, Unity has had AOT compilation since forever with both ILCPP and (more recently) Burst.
amitmathew 3y ago
There's a good post on Reddit of a dev creating small web exports using custom builds: https://old.reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k15rip4/ https://old.reddit.com/r/godot/comments/16lti15/godot_is_not....
- deleted 3y ago
  [deleted]
- Waterluvian 3y ago
  Thanks. I first misread the C++ part but it sounds like they have some way of paring down the runtime when using GDScript. I’ll have to seek that out.

fidotron 3y ago

When I first encountered Unity it was because there were performance problems on a Japanese only version of Bejeweled built with it and they needed someone to fix it. It was a classic: creating huge numbers of new objects for particle effects hammering the gc, and the fill rate of the then cutting edge device GPUs not being a match for their screen resolutions. Unity took several years, and a huge amount of investment, along with improvements in the wider ecosystem, before performance became much less of a concern for normal developers. A lot of the work they did around C# usage to achieve this is really surprisingly intense. In the near future I seriously think 2D (and some subset of simple 3D) game devs would be better off looking at Defold, and if you want to make immersive 3D just bite the bullet and move to Unreal. These days cost of preparing assets drastically exceeds coding time anyway.

Fraterkes 3y ago
What advantage do you think defold has over godot for 2d (apart from currently seemingly being more polished)? Theres lots of people complaining in this thread that GDscript is not serious enough as an engine language, but Godot at least has a decent c++ api. Defold only seems to support Lua (although you can extend the engine with other languages afaik).
- fidotron 3y ago
  Bluntly, getting too hung up on languages is procrastination. Lua is more than fine. (GDScript isn't actually that bad, just completely esoteric). Similarly I wouldn't get hung up on Blueprints or C++ when worrying about Unreal, partly because their C++ is so particular it's extreme. Defold is basically a pile of interesting simple subsystems, especially around game logic, that in combination become surprisingly powerful, and the experience of the devs shows. It is one of those tools that even if you never use it again some of the ideas stay with you.
  - Fraterkes 3y ago
    I actually agree with you about the language-stuff. I thought your parent-command was essentially making some kind of performance-based comparison between defold and godot, which is why I mentioned Lua. Defold seems interesting, but unlike Heaps and Godot it hasn't yet been used for any game I've heard of. (additionaly I don't really agree that Gdscript is particullary esoteric. It's basically python, with a bunch of very obvious engine-api stuff added on top. Language-wise theres very little to learn there, which is great)

MrLeap 3y ago

I didn't read anything that indicated a hard block to creating new methods that bypass the binding layer? All the layers are open source. Unity has their fair share of bolted on methods with a "NonAlloc" suffix. Seems obvious to prioritize raycasts / intersection / collision code to receive this treatment. I've noticed a few lower lift things I'd like to submit PR's for, just to see how/if I can help.

johnnyanmac 3y ago
I hear the recommended approach is to write your own module in the engine level code. But that means you need to compile the engine everytime you change your module. Possible, but you are losing a lot of iteration unless you are experienced in rolling in your own physics. Nothing stop you from modifying the engine code, but the problem lies in the binding layer, not the engine perormance (as you see in the blog, the raw engine performance for a raycast is about the same as Unity). That's a bit trickier to fix without intimate knowledge of such bindings, and you'll likely break a lot of GDScripting support (so by extension, c# scripting) in the process.

zamalek 3y ago

This dictionary stuff is truly bizarre. I have been playing around with GDExtension and Rust - specifically the meshing interface. This dictionary stuff shows up there. Not only couldn't I figure out why (the GDScript angle makes sense in hindsight), but it also makes the API virtually impossible to discover: you have to resort to reading things up in the documentation. As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.

Rapzid 3y ago
Yeah, my take is the API should be made clean of this stuff and a shim layer added on top for GDScript to consume.
RobKohr 3y ago
If you are using Rust, you should check out https://bevyengine.org https://bevyengine.org which is a rust based game engine with a focus on ECS

droptablemain 3y ago

I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project. Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.

Lucasoato 3y ago
They should remember that even Unity had to deprecate the Boo language to go forward :)
- mattigames 3y ago
  Both Boo language and UnityScript were deprecated (the later was oftenly mislabeled as JavaScript, creating quite a confusion between newbies)
- dandellion 3y ago
  Not sure Unity is a good role model... Also, having used both Boo back in the day and GDScript in Godot more recently, I'd say that one big difference between the two is that Boo was really bad, and GDScript is actually pretty good.
  - eddythompson80 3y ago
    What's wrong with Unity from a technical prospective not marketing/business prospective?
    - cfgyuiikhg 3y ago
      It was fat and glitchy from the get go.
    - johnnyanmac 3y ago
      Unity got a stigma for delivering half baked features and dropping support for existing features without a replacement. The epitome of this was where in Netcode, where I believe they had no officially supported solution despite the engine having 2 different packages which were both half-baked, all while the DOTS variant was far from release. I don't think Godot should go that route.

Dudester230602 3y ago

If Godot has a first-class C# support then why `Godot.Collections.Dictionary` exists when there is already `System.Collections.Generic.Dictionary`? https://learn.unity.com/tutorial/lists-and-dictionaries https://learn.unity.com/tutorial/lists-and-dictionaries

worble 3y ago
https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/c_sharp_collections.html https://docs.godotengine.org/en/stable/tutorials/scripting/c... > The main difference between the .NET collections and the Godot collections is that the .NET collections are implemented in C# while the Godot collections are implemented in C++ and the Godot C# API is a wrapper over it, this is an important distinction since it means every operation on a Godot collection requires marshaling which can be expensive especially inside a loop. > Due to the performance implications, using Godot collections is only recommended when absolutely necessary (such as interacting with the Godot API). Godot only understands its own collection types, so it's required to use them when talking to the engine.
TazeTSchnitzel 3y ago
Bridging collection types between languages is never easy. Apple only manage it because they control the compiler and runtime on both sides, and that still comes with performance pitfalls. Allowing both to exist and telling people when to use one or the other is not only easier to implement, it has more predictable performance and gives the user more control.

TheMagicHorsey 3y ago

Curious if anyone here has tried Bevy (Rust game engine). Godot has a beautiful editor and great tooling for a free engine ... but I worry about the choice of C# and GDScript as the expected way for devs to interact with the project (what if performance is a concern or you need to develop some low-level features). Another post in this thread said the C++/native interface was not great and difficult to work with. And C++ even in the best of times is not my favorite thing to work in.

deleted 3y ago
[deleted]
Daegalus 3y ago
I looked into this, but it seems most gamedev communities I asked, say Bevy isnt great, and everyone seems to be recommending Fyrox instead. No clue if it actually is, just parroting what I have been told. Either way, I don't think either is ready for prime time as its still early development.
MegaDeKay 3y ago
Bevy came up on /r/rust_gamedev a little while back. The general sentiment seemed fairly negative, with comments that you either do things Bevy's way or the highway. https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_bevy_the_best_option_for_a_rust_based_game/ https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...
- johnnyanmac 3y ago
  A lot of the consensus there seems to come down to 1. the engine isn't stable and has breaking updates (why does that sound familiar...) 2. ECS is hard to learn and Bevy is too strict with ECS. It's hard in the same way OOP is hard, I guess. But it's just that: a paradigm. It's harder to google because ECS is a specific paradigm for applications that want to follow data oriented design. If you don't care about that, then you lose all that benefit and google-ability for not much gain. I guess that's just the state of FOSS game engines right now. People basically just want Unity/Unreal without the copporate overlords. But while oppressive, they also did fund the engineers to make those solutions so attractive to begin with. You'll inevitably get your hands dirty if you go of those smooth UE/Unity roads. Especially if you're choosing an up and coming language like Rust on top of all things.

jayd16 3y ago

Funny that they have to use a custom dictionary setup when C# supports dynamic types. >Mixing fast and slow APIs as discussed above would leave us with headaches for decades Meh. Unity has allocating and "NonAlloc" methods, even on the raycast API in question here. It's a really minor issue. Sounds like Godot will need more time to bake before its perfect but we already knew that.

deleted 3y ago
[deleted]

rybosworld 3y ago

One thing that stands out as odd to me is the small selection of really "good" game engines. Unreal seems to have the most features and the steepest learning curve. Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains. Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many features as the other two and the commitment to GDscript seems... odd. If I were picking a game engine today, it'd be between Unreal and Godot, but I'm not sure I'd feel great about either choice.

jay_kyburz 3y ago
I'm thinking about going back to 2d. If Factorio and Slay The Spire can be smash hits in 2d, perhaps I can as well :) I'm a fan of Love but I have to admit the amount of Lua I wrote for just my prototypes did start to get a little scary. I might have a play with raylib.
- cmovq 3y ago
  Interestingly both of the games you mentioned use custom engines. I think people overestimate the difficulty of rolling out your own 2D engine.
- mnk47 3y ago
  If you like or don't mind using Go, check out Ebiten as well. I think it's similar to Raylib in spirit, but it also supports Nintendo Switch, iOS and Xbox. IIRC it uses native graphics APIs (Metal for MacOS, DirectX for Windows) while Raylib just uses OpenGL.
zzo38computer 3y ago
I think that which game engine will be "good" depend on manyu things including what kind of game, what computer system, FOSS, licensing, other features, etc.
jayd16 3y ago
It really depends on what your game/team needs. If you're trying to make a match-3 then Unreal is maybe not the best choice. If you're trying for competitive cutting edge graphics in an engine that is mostly done so you can actually focus on the graphics, then Unreal is top of list. I think its probably better to look at Unreal as state of the art but licensable. Other big game companies have cutting edge engines but they're proprietary and not available to license.

timmytokyo 3y ago

>Unity has spent the last five years working on speeding up their scripting with crazy projects such as building two custom compilers, SIMD maths libraries, custom collections and allocators, and of course the giant (and very much unfinished) ECS project. It’s been their CTO’s primary focus since 2018. That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forums for over a year. (He used to be quite active on Unity's forums.) The entire leadership of the ECS/DOTS team has resigned.

pests 3y ago
> the entire leadership of the ECS/DOTS team has resigned Recently because of the drama or unrelated? That’s sad to hear as I was very excited on that effort.
- timmytokyo 3y ago
  I don't think it was due to the recent drama. (Although who knows, maybe they knew what was coming.) Mike Acton and Andreas Fredriksson left back in March 2023 I think. They posted to twitter. EDIT: It was in May.
- johnnyanmac 3y ago
  Not recently, but there was a steady drain of talent. The two heads of the DOTS initiative were gone by May of this year and the CTO, and the last original Founder of Unity, and arguably largest champion of DOTS, silently stepped down in April when introducing the new CTO. Johacim's official status is apparently "sabbatical" (I'm sure he owns way too much stock and other sway to be hoisted out the traditional way).
johnnyanmac 3y ago
He wasn't just active on forums, he was actively developing on Unity itself, in the weeds with all the other engineers. He arguably got a bit too involved at times, but it was very admirable for a "executive" who could retire on the interest of his shares in Unity to still take so much care in the product. I can't say that about many 10+ year old company founders, let alone ones that went public. And of course the moment he silently stepped out, Unity rolls all this BS out in less than 6 months. Joe wasn't just champion of the tech, he was likely one of the last of the old guard up top keeping things focused on the actual product instead of how to extract infinite monies.

generichuman 3y ago

Response to the article from godot dev: https://reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k16982q/ https://reddit.com/r/godot/comments/16lti15/godot_is_not_the... TL;DR is that they know this & working on it

lainga 3y ago
I might throw in a bit of gossip here - many who were following the development of GD 4 last year (myself included as I was using it :) ) thought it was kind of rushed out in time for GDC 2023 in March. And immediately after GDC, Godot 4.1 followed (and now rc's for 4.2), with lots of fixes. So on the one hand, yeah, 4.0 lacks polish, and I certainly have felt some strong feelings working with GDExtension... but I also believe there was a reason for that, and I believe the team when they say they're working on improvements now

reactordev 3y ago

Never underestimate the power of open source game developers. If we could do it with XNA, we’ll do it with Unity. If we have to tear the place down and rebuild it on a rust il-compliant vm instead of mono, we damn sure will [0] [0] https://crates.io/crates/netcorehost https://crates.io/crates/netcorehost *edit* everything in the article is on point. Function pointers as binding glue sucks. There’s tons of optimizations to be done in the engine for sure. However, having a robust C# api is on top of list since it was introduced. I do think Godot 5 should make a hard choice and just support C# instead of GDScript.

Scalene2 3y ago

So, what I'm gathering is if you're bothered by the Unity (either a developer, publisher, gamer) developments, and wish Godot was a better alternative than it is, contributing to the project (by donating either time or money) is probably necessary to get there.

Madmallard 3y ago

[flagged]

KMcPheeters 3y ago

When the performance of Godot's physics engine has been mentioned before I've seen https://github.com/godot-jolt/godot-jolt https://github.com/godot-jolt/godot-jolt pointed to as a drop in more performant solution. Haven't tried it in a project yet myself

CreepGin 3y ago

The biggest problem for me in moving to Godot is the editor tooling. I find the @tool and EditorPlugin workflow to be very finicky. Editor restarts were needed to refresh/correct changes from @tool scripts. And a lot of what I needed to do in the scene view (context-free) required hacky solutions. Not to mention, they changed a lot of related APIs in Godot 4, most of what I google are still from Godot 3 and don't work in Godot 4 (no backward compatibility). That said, I'm still enjoying Godot, the only fun part in the past week.

0x_rs 3y ago
It's made great progress in this regard since 3.x, and it's an an extremely powerful system, but dealing with some @tool intricacies can very quickly make you waste days trying to figure out what's going on. My greatest annoyance regrettably lies in one of Godot's most convenient features, custom resources, that are so extremely tedious to use with @export from the editor in any meaningful, useful way that I've personally given up on it for the time being, their lifecycles even avoiding _init() cross well beyond the bug behavior territory and GDscript permits no alternative approaches code-wise that aren't absolute monstrosities of jerryrigged variadic functions (not supported except for a few API calls resembling them) jumping one into another or endless walls of parameters you get lost into.

wkat4242 3y ago

It's not Godot if you don't have to wait for something.

tacotacotaco 3y ago

I am so glad that Juan et al are leading Godot and not me because frankly I would be offended by all of this. It hasn’t been a week since the Unity fiasco and all I see is post after post from people complaining that Godot isn’t c# enough. This is like showing up for dinner and insulting cooking before you’ve even tasted the meal. There are definitely opportunities to improve Godot but there are more constructive ways to contribute than drawing a new floor plan for the house on the table cloth while the first course is being served. Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.

johnnyanmac 3y ago
>Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#. This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum, simply due to how the c++ and C#/GDSctipt/GDExtension layers talk. Take this as a warning, not a dismissal. Unity went down this exact path and we see how viable it became for large scale game development. I sympathize with you for those who are outright trashing the GDScript for being a scipting language, and I do wish those arguments would die down (it's simply language wars). But there are definitely fixes here that would improve all diferent bindings, even if they never diverged (which IMO, they should). >This is like showing up for dinner and insulting cooking before you’ve even tasted the meal cooking is subjective (mostly), performance is not. This is more like asking why the cook is trying to carefully drain out the water with a loose lid instead of using a strainer. Sure, it may work for the cook and they've done it all this time, but I'd rather give a safer solution that won't burn them long term, or spill out excess food.
- tacotacotaco 3y ago
  > This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Better memory utilization, better processor performance[1], and no more garbage collection stutters. Oh right, it’s not your preferred language. I’d rather we all just make games instead of fighting language wars, but seeing so many of these posts in the last week makes the community feel hostile. [1] https://programming-language-benchmarks.vercel.app/rust-vs-csharp https://programming-language-benchmarks.vercel.app/rust-vs-c...

homarp 3y ago

reply from Juan Linietsky (BDFL of Godot) https://gist.github.com/reduz/cb05fe96079e46785f08a79ec3b0ef21 https://gist.github.com/reduz/cb05fe96079e46785f08a79ec3b0ef... discussed here https://news.ycombinator.com/item?id=37598985 https://news.ycombinator.com/item?id=37598985