The Godot Engine

Some people in the community don't like the engine. not sure if Unity shills, but they have some serious critiques about it. mainly that it is like kicking dead whales down the beach ass for 3D games. anyone knows what's up with that? from my perspective as someone that's not very familiar with game engine design, my only concern is the renderer. it's kinda crap. everything else seems ok or good enough.

>>87913 Its good for indie but no ready for AA games. Also, I hate the python like language they made for it.

>>87913 For context, I'm a core dev on the big ass fork that happened due to their weird political bullshit (Redot Engine) So, Godot Engine is great, except there's a lot of problems - Both in terms of polemics AND in terms of dogma getting in the way of design/programming. So, I'm working on ReX Engine (A hard fork of Godot) that is boosting efficient, etc. etc. I can't leak everything because Juan and his team keeps stealing our stuff from us that we list out publically. Go with Redot Engine and wait for our first release of ReX because we're fixing a lot of soykaf. I already leaked one thing: I've improved certain components of the physics by a demonstratable 98% in terms of timing, while also increasing safety. We also don't ban people because we disagree with them. >>87918 Yeah, we're working on both of these things. GDScript is total ass, lacking in features, etc. Thankfully, Juan's team was upset that we were adding traits/etc/etc to it that we pretty much forced them to add features -- But we're reworking it, entirely. I'd share more but the fuarrrktard has straight up spies keeping an eye on us, since we really hurt them in the wallet :P

>>87923 How much work would it be to migrate a godot project to redot or rex?

>>87923 At this point why not forego all your association with Godot?

>>87924 You just import your project and it works. The one exception is if you're using their most recent alpha. Right now you would probably want to be on 4.3 - Back up your project before you do anything, because things get weird. ReX isn't release yet and won't be for a short amount of time. If you're using C#, we have some fixes coming in that will allow that to work. They had a lot of hard-coded weird soykaf so it took a bit of time to decouple that. If you're using 4.4 - Just keep on using Godot until we get our 4.4 release out. For ReX, we're going to do some stuff - Don't use it until our first release. By then, you'll be able to just import your 4.5 project in and it will work very well. Currently, it's only twice as good -- But I have a few more things I'm working on that should boost that up quite a bit. I know that sounds fantastical, but these guys had no idea how to write efficient code :P >>87925 We did, but right now people can import their projects and we want them to be able to. It's bullshit that you can get kicked out because you disagree with a trivial thing with Juan and friends.

>>87913 I don't know the ins and outs of it, but I test drove it for a week. The learning curve is small, but I didn't enjoy having to slogs through its UIs to tweak parameters and select specific meshes. It seems like the ergonomics could be improved. I'd love if meshes could somehow be controlled more programatically. I don't want to crawl through windows to change the Albedo color of a box. That's like 5 clicks (per object!!!) I admit, I might not be cut out for game development since it feels like a massive amount of tedious, unfulfilling work just to make a tires and their textures rotate in game...

I'm a fan of 2D Metroid Vania games, or RPGs with 2D graphics. Because Godot provides 2D assets, I think it helps me play high-quality 2D games.

>>87923 >core dev is a schizoing lainon poster Very based. Also pleasure to meet you. I've checked out Redot 4.3 for a little but I just had to stick with Godot 4.4 and later 4.5. >I've improved certain components of the physics by a demonstratable 98% in terms of timing, while also increasing safety. We also don't ban people because we disagree with them. As someone who's currently putting all their eggs into a Godot project shaped basket, I couldn't care less about that. At least from a practical side that is. I've written my own move and slide because theirs didn't do what I needed and their sweep collide is efficient enough to call from gd. And if I need anything rigid body or ragdoll then Jolt seems to be just fine. In fact I've bypassed plenty of their built in systems and preferred patterns. I don't even use any signals since I find the system and syntax too clunky. But what I want most from the engine is to not dictate how I'm supposed to do things, otherwise I could just use Unity and benefit from their existing, much more mature eco system. The other thing I hate about engines and other software is if they try to appeal not just to beginners, but actual retards who have some sort of phobia from a script editor. Unreal is like that if you are someone who doesn't want to do engine development in C++. And Blender too, having removed the geometry scripting node. I heavily dislike that trend. Also it's MIT so those coding socks weirdos can screech and scream all they want, they can't bar me from using Godot. Their only recourse they have is to either kill me or make spiteful changes that will ruin the software for everyone else. I really don't care if a tool is "woke" as long as I works where and how I need it to and can use it for my purposes with little to no restriction. I believe the best selling point for anyone wanting to do serious game development is to have something that is fairly modular. So that even if it is heavily opinionated, you can just swap those components. For instance Godot already has to do some linking swapping when switching between Forward+, Mobile and Compatibility. But if I want to alter their rendering pipeline I will still have to recompile their engine and then keep up to date with their downstream changes. And for Redot, and I might be wrong ofc, the only two realistic options are to either keep compatibility with Godot so that at least some of your changes get into Godot, or go the modular route since if people need something more powerful than Godot or Unity, they will either put up with Unreal or roll their own. But if ReX allows me to define how I want the render pipeline to operate, like doing extra light passes or whatever my sick tech art mind can concoct, without having to pry open and rewire the entire thing then this would be interesting for me to check out. And pro tip, make it so chat ai companies index your code, documentation, blog posts and discussion threads since this is how people will be able to learn it the fastest. Currently a third of the answers chatgpt gives me are total crap and possibly based on old syntax that has been long removed. Regarding safety, I don't know what you mean by that but the only things I personally need there is for gdscript to actually behave as I would expect from any other OOP script language instead of doing nonsense like throwing an error when trying to add an instance of B to a list of A where B is extending A. Basically voiding the entire point of class inheritance lol. And also provide me actual useful exceptions instead of "oops, something went wrong" and I have to, in the worst case, bisect my way through the entire project to find the culprit. The other is to compile to something that can't just be decompiled into the original code, including comments and all by people who aren't even on the level of script kiddies. Performance wise, Godot is fine, or rather I have much greater concerns than that. For instance if looking up a bone by name is a linear search, it's stupid but I can just keep a lookup map myself. But not being able to serialize Dictionaries, now that is very annoying. Or needing a bunch of small files for custom resources because you can't class_name in a subclass. Neither can you do nested typing, templating and other stuff. Or the complete lack of nullables, Elvis operators or having to use the python style ternaries. You might even want to copy Kotlin rather than Python. Though, I do like the semi-typed approach just like I prefer prototyping things in js, but gdscript is still a toy language for these and other reasons. But if you could compile it to actual machine code somehow, at least the parts that use only ARC and no GC or reflection, that would already be nice. And you'd get your performance and security that I'd actually care about. But under Godot I'm just glad that someone recently reintroduced some basic tokenization that they removed from 3.x -> 4.x. And that gdmaim exists. Which is not a built in function because I suppose they want people to use these $Name lookups and other nasty reflection hacks that would stop working the moment it isn't a plain text JIT environment. In short I just need a robust toolbox with an editor and difficult components already having a usable implementation to reduce front loaded development and that I can replace later if I want or need to. I do not keep up with the "community" so I don't know what their plan is for turning Godot into just another Scratch to make it "more accessible and inclusive" but at the moment it appears to be within the sweet spot of being just usable and reliable enough to build upon while still being fresh enough to not be bloated and soykaftiefied like Unity has become. And I will switch to 4.5 or 4.5.1 once that's out just so I can get rid of the "can't resolve res://a" exception that I am unable to pin down and am just living with it for now like a persistent rash. Sorry, I really don't have anything against you and am curious to see where you could take Redot or ReX, and while I'm spilling months of frustration into this post I have still no good reason to switch just yet. >>87913 Use Godot if you don't want to be dependent on Unity's black box and are ready to spend the first half of your project simply writing a bunch of tooling and functionality yourself. But I do have to give it some props for how easy it is to extend the editor and some design decisions that are better than Unity's, like not needing to fetch the delta time from some awkward global object. And having a somewhat easy time to write your own implementation of things.

>>87923 > we were adding traits/etc/etc Is it possible to inherit/implement the same trait multiple times for the same class? Imo they're good for fundamental library level stuff like data structures, iterators, etc, but in gd I almost always want components and composition. Unity's been the only one engine which got this right in my experience. In Godot doing composition feels like fighting the system compared to that.

>>88114 > And pro tip, make it so chat ai companies index your code, documentation, blog posts and discussion threads since this is how people will be able to learn it the fastest. Currently a third of the answers chatgpt gives me are total crap and possibly based on old syntax that has been long removed. Install Copilot in VS Code and add files with examples of correct API usage into context for prompts. You can also ctrl-click on some method to go into its definition file and add that to context (works great for typescript and rust at least). Here I ctrl-clicked confy::store method, it took me to the library file outside of my project and I added it in Copilot pane into context in the bottom right. This way is how I usually make Copilot figure undocumented libraries and APIs for me, I've been doing this since I started using it and it might be one of my favorite usecases.

>>88116 >add Microsoft's data crawler inside Microsoft's data crawler so I can help train their models that aim to replace me with a soykafty spaghetti version of my code while risking to scratch up my project. No thanks. In fact I should figure out how to run multiple nodes with an LLM feeding nonsense into Copilot all day. I use the gd plugin in Codium which connects to the language server of the currently running Godot instance and also allows me to ctrl+click into the documentation just like in the editor. While I use chatgpt or grok to spit out a much better documentation than the one provided, prompt for code snippets or converse about what algo would suit my current problem best. This has worked quite well for me and I like to think that I've become quite proficient in a relatively short time, with a good awareness of performance and gd's pitfalls. While keeping oversight of my architecture which does many things quite differently than what Godot intends you to do. But I'm starting to be happy with my current structure. Either way, you misunderstood my point. If you don't feed those models, which are the new search engines after all, with not just your documentation strongly linked to your version number but also all those secondary and tertiary resources like pull request and issue ticket discussions or 3rd party tutorials and related blog articles then Copilot and all the other models will be useless if the Redot team tries to roll their own scripting language, which then probably nobody will see the reason to adopt if learning resources are too sparse and lacking. Which in turn will keep learning resources low in numbers. In fact it would be best if all they did was simply improve on the syntax (like adding nullable fields, nestable container type declarations, Elvis operators and traits, interfaces or templates), the runtime type handling and the compiling and then hope Godot adopts these so people won't have to learn yet another obscure language. And sure, I could also use C# but that has more drawbacks since I want to have some control over batch deallocations without having to bother with some object pooling library. Plus points if Redot can greatly improve on those default editor panels, especially for profiling and error logs since Godot's current design is a total mess. Improve editor scripting even more and figure out how to do plugin versioning, so people can write them for multiple versions at once and maybe even have cross compatibility with Godot as well. Since it is the editor and addons that make one chose Godot over using any of the other open source game engines out there. Hell, you could even have some visual scripting but keep in mind that nobody should be forced to do everything in nodes. The only practically sane application for it that I know is to be a way for game designers to pluck together some high level functionality instead of doing any complicated math in that. So it probably should only be something that maps some gdscript. This could in turn complete, unify or even replace that whole signals system, which in turn also could use at least an overhaul. Like not being able to just pass a function reference or having to go through the Node panel is rather cumbersome. >>87925 I hate the cult behavior of it but it's genuinely good enough that it rightfully has a growing user base that you don't want to miss out on. Especially if your project is a fork of it. >>88073 I have to say that their 2D implementation is more clean than Unity's. >>88071 Best meta skill for Godot is to learn editor scripting as the first thing. Just yesterday I wrote some script so I could select nodes from imported scenes without having to make them editable. Automation is your friend. Especially when extending the editor and modifying nodes programmatically is as uncomplicated in comparison as in Unity and Unreal. >>88115 I'm not that happy with Unity's system either. Fetching a script instance from another script or checking if your game object has that script attached and do some type checking and then work with it pretending as if you do has always bothered me, especially if you want to do these lookups in some fairly hot code. I see why Godot would have it the way it has since it makes things simpler that way. And you can always implement a helper holding WeakRefs so you don't have to resolve NodePaths every frame. And maybe that's just me but the way I handle things I would prefer something like a trait or interface so I don't have to check if something has a function of a given name. It's bad enough that it doesn't have any halfway decent error handling.

>>88133 > If you don't feed those models, which are the new search engines after all, with not just your documentation strongly linked to your version number but also all those secondary and tertiary resources like pull request and issue ticket discussions or 3rd party tutorials and related blog articles You underestimate it. It doesn't need documentations or tutorials, it literally just needs interface files. In context, not in learning set. So together with your prompt you feed it the names and signatures of functions from original source and it's usually enough for it to figure what to do if the naming of functions there isn't totally retarded. Sometimes it can figure things out just from the types alone, when the names are confusing. That only works well for languages with advanced type system like Rust or Haskell. In your case though, when it's not a noname library no one used but a noname scripting language no one used, you can probably feed it unit tests of that language for it to figure absolutely everything imaginable what can be done with that language.

>>88133 > Fetching a script instance from another script or checking if your game object has that script attached and do some type checking and then work with it pretending as if you do has always bothered me, especially if you want to do these lookups in some fairly hot code. IIRC, you usually just do it once in component initilization, in Start method. Also, it's another terrible thing in Godot that you have to lookup by strings. In Unity, you use generics for that, like this.Movement = this.GetComponent<Movement>(). Also, there is this.GetComponents<Movement> to get multiple components of the same type as a list. Godot damn bad at this.

>>88133 >Codium how much trouble is it to install extensions for that? Are there any important extensions you can't obtain due to using Codium? Specifically the flagship python extensions?

>>88134 Impressive if true. Especially since I was talking about things that are design descisions and reasoning that's very difficult or even impossible to parse just from the code and comments alone. Like if you want to know why Godot is using UIDs now. While sure, I too believe that the best documentation is the executed code itself, high level big picture stuff often is missing as explicitly written methods. But if you know of a good Copilot alternative that runs locally then I'd be happy to hear! Either way, my current method suits me well since my problem is not with architecture design, or rather I'm figuring it out slowly but surely. And also am working a lot against the grain or intended way at the high level (I suppose Godot wasn't designed for actual software devs in mind) so the canonical answer won't help me much. >>88135 If you do this on start only then you have to cache that reference anyway. C# relies on GC so whatever but that's also the aspect that I avoid it for. Also I've worked on code that would fetch components during update because screw it, why not?! >this.Movement = this.GetComponent<Movement>() This looks like at least a binary search by type check if Unity's team was smart enough to write a hash based on the class' static ID. In worst case it's just relying on C#'s reflection and iterates the list of attached components and then resolves and compares the class name strings EVERY TIME.. I feel like I will have to state that I'm not a Godot fanboy, just someone who thinks it's the best fit for my current projects and dislikes how Unity does things much more. That said, NodePaths really don't look so bad and is essentially a relative path based on the node names in the scene tree, this is not that difficult or expensive to resolve, especially if you reference something not too many layers away and with a reasonable amount of child nodes along the way. Alternatively you can link a node as a reference directly to an `@export var node: MyNode` in the Editor and it will be resolved once, on "ready" but be mindful that this results in a strong ref which you need to be careful with under ARC. My advice is to build yourself a helper that resolves NodePaths lazily and stores them as a WeakRef for repeated access. This works remarkably well and opens many possibilities. >>88169 You can technically change the repo url: https://github.com/OliverKeefe/vscode-extensions-in-vscodium Hypothetically python, gdscript, zig and a bunch of other stuff works just fine for me in Codium. The things you will have trouble with are just a handful of official microsoft extensions like their SSL bridge which won't work outside of an official microsoft VSCode build.

>>88114 >Very based. It's great to meet you, too, Lainon. I've actually been here since the beginning, too. You'll never guess who I am Present Day, Present Time! AHAHAHAHAHA! Or you might. Who knows, who cares. Either way, I'm passing this all along to the team because we're *actually* community driven. My goal for ReX is to outright beat Unreal Engine, but have the ease-of-use of Godot/Redot. Anyways, I'll tell you this: I'm mcdubh and I approve this message. Ping me in the soykafcord that I, unfortunately, have to use because thats where the rest of the dev team is. We'll probably have an IRC server if I can have my way... :P

>>88171 > But if you know of a good Copilot alternative that runs locally then I'd be happy to hear! I unfortunately don't have enough VRAM even for gpt-oss-20b. That would be the first one I'd try, together with DeepSeek-V3. Also, I don't know any plugins for VS Code or Codium that allow to replicate what Copilot plugin does in edits mode but with local model. I think there should be something, but I'm unaware.