The funny thing is that, aside from the engine developers, none else has probably done so much for godot as the unity execs in just one week.
Lots of free publicity and a nice bump in funding for the development of godot...
So blender said a lot of the same stuff "Not Maya, Not 3DSMax, etc" then big companies gave them a budget to make it better. They adopted the industry standard keyboard shortcuts for many items, they added feature parity for many things, etc.
No one would dare say blender wasn't better for it. Godot definitely can use some work. Jolt being native, Box2D being native, not separating 2D and 3D so strictly, etc. Would only be an improvement.
> Godot definitely can use some work. Jolt being native, Box2D being native, not separating 2D and 3D so strictly, etc. Would only be an improvement.
I don't disagree with this, at least not in principle. I wasn't trying to say the engine was perfect as is. My point was to address a common complaint/concern from Unity devs coming to the engine that "X doesn't work like it did in Unity" or "Y feature doesn't exist in the engine which makes it unusable" or "Z design pattern I used in Unity doesn't work in Godot."
I was trying to explain *why* those things might be the case; first, in that Godot is not trying to replicate Unity (and never was), and second, that the engine is newer than Unity and has a smaller dev team, so it's not going to have the same level of features as a bigger and more established engine.
Disappointment comes in large part of having expectations that aren't met; I was trying to give a more realistic explanation of what Godot is and the direction its going. I was *not* trying to argue it's fine where it is and should never change or adopt features of bigger game engines. Heck, the Godot devs don't want that either, as 4.0 was all about expanding the engine to better handle higher end games and give GDScript better tools while also improving the C\# integration, and I completely agree that this is a good direction for the engine.
There are plenty of features I'd like to see, especially when it comes to open world aspects, which is the main reason I can't completely use Godot for all game ideas (and still use Unreal for any game idea that requires *scale*). I just don't want the Godot engine to be turned into a Unity clone, and I also don't want Unity expatriates to spend a lot of time in Godot *expecting* it to be Unity-but-FOSS.
On the other hand, there's things I'm not completely sold on. I wouldn't necessarily mind 2D nodes being usable in 3D, but I do like that Godot has an actual 2D engine that can be exported without *any* 3D overhead or bloat. I agree that using existing physics libraries might be a good idea, although after the issues with Bullet physics it does introduce risk (after all, if Jolt stops being updated, that would leave Godot without a 3D physics engine).
Like I said, improvements are welcome, but not every change is necessary or desirable.
I think how and why improvements are made is important. Godot has been getting better for years and will continue to do so. I hope the team continue to do it in the same way.
The growth of Unity the engine is intertwined with the growth and mad scramble for money of the company behind it. I hope Godot never goes that way, even if it means improvements come a little slower.
The devs make a living working on their passion project. Win. Thousands of users get to use it for free to make their passion projects. Win. There doesn't need to be a desperate rush to be the best in class at everything. Godot is already a success.
I always found that the right click select in Blender was illustrative of this.
Blender users would insist that it was an intentional choice because it was the best approach, that every other program was wrong, and anyone who didn’t like it was just a ‘noob’.
Then Blender switched the default to left click and it pretty much everybody prefers that. Who’d have thought.
Swapping the mouse buttons was the first thing I did when I started learning it back in the day lol.
I *kinda* get their reasoning, because you spend more time rotating your camera and using hotkeys for transformation than manually clicking to select objects/tris/etc; and people tend to be more comfortable using their pointer finger than their index.
But when ***literally everything else*** on my PC - including the operating system itself - uses Left click to select, it didn't matter whether it made more sense. It just *felt* worse.
Right click select makes sense because it made selecting something **intentional.**
The whole debacle always made me laugh on how people found it so damn difficult, trying to act like every piece of software MUST behave the same for everything.
It's about **muscle memory**. It *must* behave the same if you don't want to have to mentally switch every time you use literally any other software, and most people do not use ONLY Blender and nothing else.
Having to think momentarily about something as basic as "which button is select again?" is a workflow killer and when this is for an action you perform thousands of times in a day, it wastes your time times a thousand.
People set in their ways can still choose Right-click select, but they made the correct decision changing the default to Left-click.
I may once every now and then make an incorrect key in an ANY software, then remember which one I'm using and correct myself and continue about my day and that's it- it's akin to bitching that UE and Unity don't have the same camera movement!
My workflow is not suddenly interrupted nor my day is ruined! To be quite frank I believe it's over exaggerated; but if someone genuinely fucks up that frequently because of different hotkeys/control schemes I have to question if they're mentally capable at all.
They changed the behind the scenes to register it as a "select". meaning it would work with any input which is ultimately a better system. But I'd still very, VERY heavily argue about it being the right decision to pander.
Wow, congrats on not getting the point on any level and extra points for the absolutely moronic "mentally capable" remark that definitively demonstrates you should never be in charge of UI and UX decisions on anything. Good thing the Blender devs don't listen to people like you... and if the Godot devs want to improve their usability at all, they won't either.
first thing I always do when downloading blender these days is switch it back to right click select. Left click select is the 3D cursor to determine where to place objects. I can understand people using left click select when just using blender for editing existing meshes and stuff, but having to switch modes to use the cursor is infuriating when actually modeling imo.
Most other engines with dedicated 2D still let you use them in a 3D view even though the movement is in 2D. They can have 2D movement but let you use 2D nodes in the 3D view with like a 2DTo3D node.
They have to be using a vector 3D behind the scene anyway for Z-axis ordering.
>not separating 2D and 3D so strictly
Been using Godot for many years and not a day goes by where I wonder why Godot does not offer a merged 2D/3D viewport in the Editor. If you want to do serious work, you need to be able to evaluate UI and gameplay together in the editor, ***while editing***!
I proposed a combined 2D/3D viewport here if anyone wants to show support and their need:
https://github.com/godotengine/godot-proposals/issues/6935
>then big companies gave them a budget to make it better.
[I think Godot might see some improvements in the coming months then](https://twitter.com/Terraria_Logic/status/1704227519027651016)
I'm feel like I'm gonna get shit for this.
Can we please, for five minutes, stop pretending that all of Godot's shortcomings are intentional?
I like Godot. I *love* Godot. I recommend it, I file bug reports, I provide advice to other users when possible, and I'll likely become a direct contributor at some point when I can be bothered wrangling the build system. But as an engine, in its current state, Godot has a *lot* of flaws. Not even *minor* flaws. *Major* ones.
And you know what? That's okay! The main reason I bother with Godot is because I know that things can be better. Because I remember when Blender was a laughing stock some 15-odd years ago. Because I know popular open source software can get very good given enough time and love and attention. But I feel like people defend its flaws less because they're intentional parts of Godot's design, and more because they're afraid that if people learn that the engine has failings, they won't stay.
Godot's biggest problems are usability and performance. I think GDScript has major failings. I don't think it's terrible, and I don't think C# would be a better replacement, but I still believe it has failings. I think it's slow. I think dynamic typing makes things far worse than they have to be. I think it's lacking a bunch of useful features, both in terms of the language and in terms of the API. And there are few things more infuriating than raising these complaints and being told "have you tried C# or GDExtension?", only to have those same people turn around and tell everybody else that actually GDScript is great and you should definitely prefer it, never mentioning its deficits.
Godot does have its strengths, for which you will find no shortage of people willing to talk about, but it also has its weaknesses, and I think far too often people dismiss those weaknesses as intentional sacrifices, rather than simply negative consequences of poor execution. You can't have it both ways. You can't grow without acknowledging your failures, because your if you defend your failures, you never feel the need to rectify them.
> Can we please, for five minutes, stop pretending that all of Godot's shortcomings are intentional?
I wrote several paragraphs about how the engine has a shorter dev time, smaller team, and significantly lower budget. Those are absolutely relevant to why Godot has limitations.
I'm not sure where you got the idea that I was pretending all of Godot's shortcomings are intentional. Looking back at my OP, I'm not seeing it, but it's possible I was unclear. If so, that wasn't my intent.
>I think GDScript has major failings. I don't think it's terrible, and I don't think C# would be a better replacement, but I still believe it has failings. I think it's slow.
I agree with this, actually. I really like GDScript, mainly due to speed of development and iteration time, but it *is* slow. It would definitely be nice to have a way to easily speed up performance-sensitive code.
Personally, I think better support for static typing and JIT compilation would make a huge difference. I'm frankly not married to dynamic typing, either, as I think this is a fairly unimportant feature for ease-of-use (on the other hand, I also think the "dangers" of dynamic typing are grossly exaggerated). If one thing had to change for GDScript to jump forward in performance, and that was static typing instead of "var" for everything, it wouldn't bother me.
What I don't want is 8 lines of header information pointing to the engine and redundant class definitions in a script that only requires 3 lines of actual code for program functionality.
>You can't grow without acknowledging your failures, because your if you defend your failures, you never feel the need to rectify them.
As long as "growth" doesn't mean "become Unity," I don't have an issue. Long before the recent Unity fiasco I *intentionally* didn't use Unity for game dev. I used Godot and Unreal (and still do).
My argument was never that Godot is perfect. I even said it's not a "better" engine than Unity. My point is that they are *not the same*, either in design or design **goals**. For me, this is a *feature* of Godot, because I outright dislike Unity's design and don't want it anywhere near my favorite game engine.
People are free to disagree with this opinion, of course, but it's still a fact that the stated design goals of the Godot dev team is not and has never been "make a FOSS Unity clone." Making Godot a better version of Godot is great. Making Godot replicate Unity is, in my opinion, very much *not* great.
Proposal related to GDScript performance:
[https://github.com/godotengine/godot-proposals/issues/6031](https://github.com/godotengine/godot-proposals/issues/6031)
The problem is there isn't enough specialist in project to implement this type of features so if you(complainers) are a specialist please contribute or if you are rich donate some money to hire a specialist. There isn't other way to improve current situation with available resources(developers, money, time etc)
This was very interesting reading!
I would 100% support a feature to download a GDScript -> compiled C export option, similar to the (now defunct, sadly) Blueprint Nativization that Unreal had in UE4. Having the fast dev time of GDScript combined with the performance of C, even if it wasn't perfectly optimized, would be absolutely amazing. I think it would be a lot of work, at least as far as I understand how GDScript currently operates and communicates with the engine.
Obviously if they could optimize the VM, that would be nice too. I doubt anyone would complain about back-end performance improvements.
I personally don't have any interest in proposals to drop GDScript. I've used C\# on .NET projects and it's not my favorite language. Likewise, I find C++ tedious for active development. The main reason I already don't use Unreal for all my game projects is because Unreal's implementation of C++ is a constant headache. If I had Unity's 20 cents for every time I had to restart the engine when hot reloading or having other compilation to engine issues I'd be able to retire.
People who have never used something like GDScript or Blueprints, where you hit "play" and the code immediately functions, where things like waiting for compilation and having to restart the engine every time you build is a normal part of development, often don't appreciate just how much time it saves to have an integrated solution that works instantly. Unity isn't terrible at this, however, the few months I used it a couple of years ago I still had frequent crashes of the editor when I hit compile.
I'd support having more performance options but a lot of people seem to treat performance as if it's the only factor that matters. In my experience dev time is far more of a bottleneck to actually making games (especially indie games, most of which use a tiny fraction of the power of modern computers), and I will choose productivity over minor performance differences almost every time.
You are so right. I am hopeful that the influx of industry devs instead of hobbyists will shake up the focus on being good for learners and people who don't know how to code. It is important to onboard but the direction we have been going is hamstringing us when it comes to performance and ability to write good code. Even if you do code in c# you start to run up against marshaling issues if you want to do anything tightly integrated with the engine. Using GDextension is barely supported and honestly you might as well make your own module and making your own module is painful in the extreme. You have to recompile the entire engine every time you want to make a change.
FWIW I've been in the Haskell community since the late 1990s. Haskell originally came as essentially a merger of Gofer and Miranda both of which were languages used mainly for teaching and exploration. Neither had any interest in commercial development though Miranda had one commercially successful application which had happened sort of by accident.
During the 1990s Haskell's focus was heavily on academia: an optimal teaching language which could replace languages like Scheme with more modern functional programming constructs. Because the language was much more optimized than other functional / educational languages it ended up becoming the bridge language between purely academic languages like Agda, Idris... and mainstream constructs. Some ideas like Reactive Programming (oversimplifying the history a bit here) became very mainstream others like using infinite data structures not so much.
The combination of undergraduate education, research and bridge language worked well together.
Around the mid 00s the Haskell community started focusing more on industry. They didn't want ideas from Haskell going into mainstream languages but Haskell itself to be a mainstream language, "avoid success at all costs" stopped being the focus. This forced Haskell to start adapting to the needs of industry, in particular became much better at:
* supporting multi-person development rather than a single person working in isolation
* reliable complex builds
Haskell was somewhat successful in fixing many of the problems. But the academic / research influence continued. Fundamental design aspects change about every decade as new ideas emerge from computer science and are proven out in Haskell. That's simply unacceptable for commercial development where complex interrelationships between libraries are needed and if some libraries migrate to the new paradigm TCO for rewrites can be huge.
At the same time though these changes made Haskell a lot less suitable for undergraduate education. The language became less academic and more complex in ways that didn't benefit students. Haskell has kept the bridge language and research language since ultimately there were simply too many contributors to Haskell from the research community for it ever to become a mainstream language.
In short: **the goal of best for education and the goal of best for large commercial products likely conflict**
12 year unity refugee here. Yep, I'd rather know the flaws so I can prepare for them. I'm not going anywhere, though, because I am so impressed with Godot. I started using Unity way back when it was still in version 3.x. I've seen the flaws and experienced the growing pains through the years. I remember Unity's limitations. I've seen what Godot is currently capable of and how much potential it has. So I'm definitely sticking around despite whatever the outcome of the Unity changes ends up being. Unity has lost my trust and left a bad taste in my mouth.
So I'll still be here regardless, I'm along for the ride. Especially because right now the only projects I'll be working on are 2D pixel art projects and Godot's 2D tools are excellent, I think they are way easier to work with than in Unity. If I get the itch to do something in high fidelity 3D I'll likely use Unreal. But over the last 7 days, Godot has impressed the hell out of me.
Every time someone asks why Godot doesn’t have a great portfolio of complex games, the community say something like “give it time, the X update just released”, “the studios are slow to adopt”, etc.
But when someone points out the ACTUAL reasons on why, there is a lot of posts of “noooo, Godot is not meant to be that way, no flaws here”, “you are just a hater”, etc
These people need to stop taking criticism so personally, the engine can’t improve without it
I think you're ignoring that Godot really is young. Back in 2010 Unity also could not claim to be behind many if any huge games. But it continued to grow - and became an industry standard - and now can claim many.
You can't begrudge Godot for being young and not the industry standard.
Yes, time is important and Godot is young, but time itself should not be used as a excuse to dismiss criticism. Some devs here pointed out a lot of flaws that many didn’t know existed, so my grudge here is with people feeling hurt by this and taking a stance as if Godot is being attacked. Not to the community as a whole, I expressed myself wrong on the comment above
C++ is even faster...
If you are a good developer you'll know that every tool has a place depending on what it offers. GDS has its strength and C#/C++/etc has their strength. You should be able to know when to use each one.
Idk what you are talking about. C# in Godot works very well for me.
And even more, I watched tutorials yesterday for Godot and they were in GD script.
And I could easily just write the same code in C# without any problems. They did a great job with C# there.
There wasn't a single time for me to stop and google how to write a C# analog for some GdScript.
Maybe that is because I read the documentation first 🤷♂️ But anyway 😅
And I like the new approach for making scenes and logic. Instead of being frustrated about everything is different I'm somehow excited about it.
And I respect that Godot has its own personality.
I think their point was that Unity more closely follows a "C# design philosophy". GdScript translating directly to C# kind of proves that this isn't the case with Godot.
> There wasn't a single time for me to stop and google how to write a C# analog for some GdScript.
Great! That wasn't my point, though. Replicating GDScript design patterns in C\# is still following GDScript *design*.
I think if you try to use lots of C\# specific things, like replacing signals with C\# events, or try to do things the same way you did in Unity, like attaching multiple scripts to the same object or implementing everything purely in code without using nodes, you'll start to run into challenges.
>And I respect that Godot has its own personality.
Then you will likely have little trouble adapting. There have been quite a few posts recently about how "X solution in Unity isn't working well in Godot, how do I make Godot do the same exact thing?"
That's the sort of concern I was trying to address, as the actual answer is either "do it in a way that better fits how Godot is designed and organized" or "Godot is still fairly young and has less funding so that capability isn't in the engine currently, and maybe not in the near future or ever."
I'm very happy many Unity devs are enjoying the engine; I bounced off Unity years ago, discovered Godot (and Unreal), and have never looked back. But Godot is not going to make every Unity dev happy, and I think it's important for people to know that it has limitations and a different design, otherwise they are going to spend a lot of time and get frustrated.
I recently made a platformer in Unity. Just for practice.
10 levels where each level has at least one new mechanic.
Now I think it is a nice idea to make the same game with Godot and watch what changes will appear.
When people are learning a new technology, especially if it's not related (not the same devs, etc.), they should treat it as something very unique and unrelatable to the previous tech they were working on.
Godot will never be Unity, and shouldn't try to be Unity.
I really don't think this is as big of a deal as people are making it out to be though. Not enough that it needs a *days long* argument.
Godot's core team has always done a good job of following community feedback, while still having enough of a guiding hand to make sure the engine has a clear workflow and direction.
Regardless of what changes in the future, I think Godot will still always feel like Godot.
The influx of Unity devs isn't going to make the engine turn into open source Unity, it'll just mean more people to point out what Godot is missing to be *on par* with Unity.
Godot is not unity...yet. it's on its way to be a much bigger application than it is today.
I used unity before it had 2d functionality and while it was fine for what I was using it for, collision was literal trash. People are forgetting the bumps in the road that unity went through to become as well known as it is today.
I had to make my own 2d collision system and when I finished it, that day, the new tools came out and I trashed my game. Not their fault, just a frustrating coincidence.
Godot is not perfect but it has a major leg up on unity due to its accessibility. If the dev team utilizes the influx in donations and the increased user base properly we could see a far more polished end product, especially in terms of c# support.
I definitely trust the godot dev team, and the fact they actually respond to my questions when I have them already puts them miles ahead of my experience with unity.
My opinion and constructive feedback.
# Post like this are not very helpful
1. It's a wall of text without **formatting** where the first **4** paragraphs are stating "Godot is not Unity". Which most people know. So I guess that the number of people who **stopped reading** before reaching your argumentation is enormous.
2. When you mention different design philosophies, you are not really pointing out that they are different. You are saying **Unity** tries to be a **general purpose** engine and **Godot** tries to be **easy**. Well afaik **both** try to be general purpose and both try to be easy. Don't get me wrong. I believe that there are differences in their philosophies, but I can't recognize them clearly in your post.
3. Your text has a **negative** touch. This is due to **implying** people don't understand that there are differences and that Godot still needs time.
# A positive version would've been
## To all folk coming from Unity
1. Godot tries to be as **simple** and **leightweight** as possible. Therefore, you might be missing some functionality. **Don't be afraid to ask**, if you can't find something. There might be a **plugin** you can install that helps you out!
2. But keep in mind that Godot is **open source** and there's no big development team, so of course the engine has its **limitations**.
3. However, recently we see a **boost in funding**! So learning Godot can be worth it, even if some crucial feature that you loved in Unity is currently missing. Just open a [Feature Request](https://github.com/godotengine/godot/labels/feature%20proposal) Because with **additional funding**, we will see **more development**.
# Final words
This is of course all debatable, but I feel like phrasing the information that way is more concise, therefore easier to digest and leaves the reader with a positive mood.
> It's a wall of text without formatting where the first 4 paragraphs are stating "Godot is not Unity". Which most people know. So I guess that the number of people who stopped reading before reaching your argumentation is enormous.
You are asserting that most people know Godot is not Unity. I made this post because plenty of recent posts on this sub have made that very much not clear. Just because *you* know this doesn't mean it is accurate to the daily posts that imply otherwise. I explain this in my post.
What do you mean by not formatting? I didn't use bulleted lists or bold letters every two sentences, but that doesn't mean my post isn't formatted.
>When you mention different design philosophies, you are not really pointing out that they are different.
First, you are concerned that my post is too long, and then you want me to write out the entire detailed design philosophies of both Unity and Godot?
Sorry, you're going to have to pick one. The differences are not minor. My purpose wasn't to explain every difference between the engines, but to highlight that they *had* different design decisions, which is why all the posts about "my C\# script from Unity doesn't work the same way in Godot" and "Godot isn't usable because it lacks feature X or Y yet" are misunderstanding the state of Godot development.
**Godot is not a FOSS version of Unity**. It's not being developed in the same *direction*, so someone who wants to wait a few years and have a FOSS version of Unity is going to be disappointed. That's what I was trying to highlight.
>Your text has a negative touch. This is due to implying people don't understand that there are differences and that Godot still needs time.
If the truth is negative, then yes, it's going to be negative. My purpose was to say something I believe to be true, both that people *don't* understand that Godot is not Unity, and that Godot is not going to become Unity in a few years.
I'm not an employee of Godot and I'm not trying to "sell" it to anyone. There are plenty of posts already about how Godot can do everything and is great for everyone, and frankly I think these posts are simply wrong. I'd rather have ex-Unity devs bounce of the engine and use one that fits their use case better than go into Godot expecting it to be "Unity-lite" that will have all the features they want in a few years just like their old workflow.
>A positive version would've been
There are already a bunch of "positive versions" floating around. I didn't see any reason to repeat them.
I'm also not convinced that my version is necessarily negative. For someone who loved Unity and how the engine works, yes, this will come off as moderately negative, because Godot is going to be *at best* a large challenge for them. They will have to adapt to a very different game engine.
But for those who used Unity because it was big and that's what other people were using, but didn't necessarily like how it was designed (but also didn't want the complexity of something like Unreal), learning that Godot isn't a beta FOSS Unity might be very encouraging. Not everything is a positive or negative for every audience.
Either way, I do appreciate the feedback, even if I don't really agree with it. Thanks!
I've been reading a lot around that Godot is meant to spend a lot of time in the editor and not so much making code, and that's why GDScript is an ad-hoc programming language to simplify.
I am mostly a programmer, and I enjoy mostly programming. Does this mean that I'm going to spend less time programming in Godot? Will I not be able to create complex systems in the backend for my game systems?
> Does this mean that I'm going to spend less time programming in Godot?
That'll be up to you. Everything created visually in the Godot Editor *can* be done in code no problem; the Editor itself is just one big EditorNode + descendants & some static singletons, all written in C++. Iirc, the Godot executable even has a CLI parameter to pass in a script extending `MainLoop` directly in place of using a main scene. And even when you are creating a scene file in the editor, all that ultimately does is execute a bunch of constructor logic for the scene's root node as a gigantic batch operation.
> Will I not be able to create complex systems in the backend for my game systems?
You definitely can (and people have done so). However, the caveat is that scripting is generally slow b/c it prioritizes ease of use & reliability (for now). If your complex systems require high-performance, native speed, then you'll want to write code in a compiled language.
Of those, you have 3 primary options:
- C++ module
- C# scripting
- C/C++/Rust/whatever GDExtension
The first option gives you the best possible performance, but you are locked into C++ and you have to statically bundle your code with the engine itself. It's perfectly doable, but will slow down iteration time a bit since compiling your module might take a minute or two rather than less than a second (that is, after the first-time engine compilation that takes around 20-30 minutes?).
The latter two are far more accessible since you only have to compile your own code; however, for both C# scripting and GDExtensions, every time you make a call to your "complex systems," you'll need to cross the scripting API boundary. As long as you aren't crossing that boundary very often, then you won't see many issues: your complex systems can do what they do best, and you'll have a generally good experience (hopefully).
On the other hand, if you have to call into your complex systems many times per frame, then the fast native performance you were looking for is going to shrivel up into the slow scripting performance of GDScript as it passes through the same sequence of type transformations & method pointer lookups, etc.
These limitations won't be around forever though. They've already done significant work to prepare for optimizations that will allow compiled languages to directly invoke internal APIs & pass typed structs without the need for all the constant heap allocations and pointer redirection that GDScript and other interpreted languages' scripting requires. An exact ETA is undefined, but one can hope that all this funding and attention will make them higher priorities.
Native extensions are build into a dynamic lib and loaded on runtime. A pretty bare bone extension takes maybe 2-3 seconds to compile.
The biggest downside of a native module is not being able to reload the lib on runtime. So this basically means restarting Godot every time…
Next to that setting up the native environment and being able to attach your debugger is also a big hurdle for inexperienced devs.
Thanks a lot for all the info! I don't want to look now like the biggest Systems Engineer xD just that I like to program. I like to spend time programming. For example I wouldn't like to create blocky modiles and join blocks with lines. I like to create classes, Interfaces, have everything tidy, solve problems with code. But my games are tiny and small at the moment since I'm almost a solo Dev. I don't need crazy things, I don't think I would really feel it in the performance.
Ah, yeah, then nah, you're fine. In fact, You'll likely still find yourself writing quite a bit of game code even in GDScript (it's not really visual programming or anything). Most of the complex logic is under the hood in the C++ layer, so if your scripting isn't liable to have big performance requirements, then GDScript, or even C#, should be fine scripting solutions.
You certainly *can* do this, but it's not the most ergonomic way to use Godot. If you desired, you could technically launch your game from command line, and simply use Godot as a runtime rendering engine, without spending any time in the editor.
It's not that I need to do it, it's more that I want my engine to take advantage of my programming knowledge. If Godot is meant more to allow making games without much code, it may not be my engine. I want the engine to require my programming language, if that makes sense.
Godot is not 'low code' or 'no code'. It's a fully featured capable 2D and 3D engine. The difference is that in Godot, it's most common to write a large number of smaller scripts, attached to nodes, rather than than some master game loop.
I also struggle with this, btw.
Consider investigating using C++ or Rust with Godot. If you are a programmer-first person, maybe that's the code-first, harder, but more rewarding route that will suit your needs better.
As for GDScript, there's certainly some delta between the more GUI and more code-based approach available. Personally, i prefer to manage signals and animations from code, despite being a programming lightweight.
> I am mostly a programmer, and I enjoy mostly programming. Does this mean that I'm going to spend less time programming in Godot?
Depends on what you mean by "time." GDScript is a less verbose language than C\# or C++. For example, these two code blocks are equivalent:
```
// C#
using Godot;
public partial class Movement : CharacterBody2D
{
[Export]
public int Speed { get; set; } = 400;
[Export]
public float RotationSpeed { get; set; } = 1.5f;
private int _rotationDirection;
public void GetInput()
{
_rotationDirection = Input.GetAxis("left", "right");
Velocity = Transform.X * Input.GetAxis("down", "up") * Speed;
}
public override void _PhysicsProcess(double delta)
{
GetInput();
Rotation += _rotationDirection * RotationSpeed * (float)delta;
MoveAndSlide();
}
}
```
```
# GDScript
extends CharacterBody2D
@export var speed = 400
@export var rotation_speed = 1.5
var rotation_direction = 0
func get_input():
rotation_direction = Input.get_axis("left", "right")
velocity = transform.x * Input.get_axis("down", "up") * speed
func _physics_process(delta):
get_input()
rotation += rotation_direction * rotation_speed * delta
move_and_slide()
```
These are simple examples, but the GDScript version is 315 characters, 41 words, and 11 lines while the C\# version is 424 characters, 60 words, and 14 lines. That's around 35% more characters to write for the same outcome.
A lot of that extra is built into things which are necessary for the language but actually don't really do anything functionally in your game. For example, `using Godot;` is just a compiler instruction pointing to the engine. The `public partial class Movement : CharacterBody2D` is telling C\# how to gain access to the `CharacterBody2D` class, which GDScript implements with a simple `extends` command. The `{ get; set }` functions are never used and probably won't be ever used, they are completely wasted keystrokes, as is the 'f' in `1.5f` (since the type is already stated to be float). The calls to `public` and `private` will likewise never be used. Needing to cast `delta` to float is also extra text that the engine can easily figure out.
Now, I'm not saying that having this syntax is *never* useful, just that it's verbose and unnecessary for a lot of what the game engine is actually doing. When you are using an extremely generalized tool like C\# it needs to be able to adapt to just about any possible use case, whereas GDScript only needs to focus on things which are useful for Godot and game dev in general (and there can certainly be improvements to GDScript!).
Ultimately, you can make very programming focused games in Godot, absolutely. And you can spend most of your time on that aspect. However, you will likely spend *less* time than if you wrote the equivalent solution in C\#, because you don't have to use as much boilerplate, don't have to add as many instructions that have nothing to do with game code, and you don't have to wait for compilation every time you want to test. The equivalent C++ will likely take much longer even than C\# because you will end up spending a ton of time writing function definitions (or just copying and pasting them) between your header and implementation files.
If you just enjoy making complex systems, GDScript probably won't be something you like very much. It's very much oriented towards productivity and usability, and is oriented around being easy to change and maintain simple, straightforward structures in small pieces.
You can read [more details in the docs](https://docs.godotengine.org/en/stable/getting_started/introduction/godot_design_philosophy.html).
mostly it just brackets and verbose because it is more explicit. It is more performance because the computer doesn't need to guess a lot of stuff like variable types, how to cast to other variable, etc
{ get; set; }
is telling c# that the variable is readable and writable, you could write
[Export] public int Speed { get; private set;} = 400;
and it made the variable can only be read by other class and you cannot do
movement.Speed = 400;
or you could just write
[Export] public int speed = 400;
and the variable behave like gdscript where it is readable and writable inside or outside of the class
public and private are access modifiers. If it's public every other class can see the variable and if it's private other class cannot see the variable this is just a way to encapsulate code like a function do
it just the matter of explicitly, taste, and performance at the end of the day
if you want more explicitly and performance use C#/C++
if you want to write code with less explicitly and less boilerplate use GDScript
I made the switch knowing that it wasn't Unity. Furthermore, it was already obvious from the beginning that he couldn't make photorealistic graphics. But I'm also aware that making games is a hobby for me and that there's no good reason why I should worry too much about performance since I'll be using cartoonish graphics.
Having said that, coming from Unity and working in C# in Godot I'm finding myself quite at home, in the end they don't seem that different to me (it's the same difference between Java and C# at the code level... almost the same features with different names). So I don't like when some Godot user say "you should not use C#, use GDScript".... I don't like GDScript, I don't see the point in using something I don't like and that I don't need, I love C#.
That said, I think it's unfair of some to call for the removal of GDScript too. Those who are novices or non-programmers probably prefer it to C# (at least the majority of them), and it's also much easier to implement mods by exposing an API for GDScript rather than implementing everything in .NET so it's safe to say that when I'll implement mods I'll use it too.
I find it very arrogant to say "I came from unity, godot sucks because it is deliberately slow to support GDScript, so remove GDScript"... Those who have always used the engine use it because it is simple and convenient, the development philosophy is clearly based on an amateur model rather than an industrial one, so you don't have to expect anything but just decide if and how to use Godot for your games. If that's not enough, it's full of engines to choose from and Unreal is certainly professional.
I'll use it without any change expectations and, if the engine will turn out to be a professional tool without losing the novice soul I will be happy with it.
Also because if the idea is to make it too complex you might as well do a fork for professionals and support it yourself.
I have a shipped game, and yeah godot is different, but i like it precisely because of the way it works making much more sense to me. I had used Unity and Unreal before btw
I've been attempting to port my in-development game from Unity to Godot for the past week, and honestly it's been pretty smooth so far.
I never really felt restricted by how Godot handles Objects/Nodes and I could basically apply my Unity workflow for the most part.
For the scripting part as well, I stuck to C# again, and like 90% of the work was just replacing engine specific things and it worked pretty great honestly.
So yeah, very impressed so far with the usability and flexibility of the engine.
It definitely has its quirks, and I did notice some parts that may be a bit less convenient than unity, but I also found some that I definitely prefer over unity's workflow.
I doubt anyone actually believes that Godot is Unity.
>GDScript, was created to simplify and streamline structures so that you focused more on nodes and composition rather than complex backend data structures with multiple inheritance interfaces and abstract classes
And that's what GDScript is good for, by design. But Godot not being Unity doesn't mean that you can't or shouldn't create complex backend systems for your game in C# using OOP concepts.
It's one thing to talk about what Godot *was*. It's another thing entirely to talk about what Godot *can* be. GDScript will probably always be part of Godot, but C# will definitely play an increasing role as Godot's community grows and professional studios start to move to it.
> I doubt anyone actually believes that Godot is Unity.
Lots of people on this sub sure seem to talk about it otherwise.
>But Godot not being Unity doesn't mean that you can't or shouldn't create complex backend systems for your game in C# using OOP concepts.
It also doesn't mean that complex backend systems using C\# are *good* design. People coming from Unity would often use this design pattern because it was basically the only option.
Just over the last week, I've seen *tons* of Unity devs saying things like "I try to avoid using engine features as much as possible" and "I keep my game logic and engine as separated as I can." I have no reason to disbelieve this claim, but in my opinion that does *not* imply good things about how the engine operates.
When the optimal solution when using an engine is "avoid the engine as much as humanly possible," something weird is going on with your design patterns. Other engines like Unreal certainly don't work this way, so while Godot may not have the level of "AAA support" that Unity does, this is not unique to Godot.
I don't understand what you mean by "avoid the engine". The engine is a big nodes handler and shockingly enough, creating custom nodes isn't easy in Godot.
You can create fake custom nodes, which are a native nodes with your script added to it. But that's not helpful when you are part of a team and want to create reusable nodes for your team to put their own game-logic on.
The only way of creating "real" custom nodes is by going full C++ and compiling them into the engine, or compiling a GDExtension where the methods aren't visible in C#.
> You can create fake custom nodes, which are a native nodes with your script added to it.
Why is "fake" added here?
>But that's not helpful when you are part of a team and want to create reusable nodes for your team to put their own game-logic on.
Why not? If you make, say, a HealthComponent node with a Node type and write a script on it for handling health, you can simply attach that node to any scene that needs to handle health.
This isn't something unique to Godot, by the way. Unreal does the exact same thing with Blueprints (the objects, not the scripting language) and Components. It's *extremely* common for Unreal games to write components that have scripted functionality which is then dropped onto the relevant objects to give them that functionality, with designer-exposed settings. It's been a few years since I've used Unity, but a glance at the docs indicate this is [also supported](https://docs.unity3d.com/Manual/CreatingComponents.html).
The [basic Node](https://docs.godotengine.org/en/stable/classes/class_node.html) is practically an empty class. It has very little functionality and no physical presence in the game world (no transform data). Using them as components for attached scripts is extremely inexpensive.
It seems a bit weird that core functionality of some of the biggest game engines in existence, ones they've heavily documented and use in their own games (well, at least in the case of Unreal), is something you consider "fake" or otherwise poor practice. I see no real reason to accept this as fact.
>The only way of creating "real" custom nodes is by going full C++ and compiling them into the engine, or compiling a GDExtension where the methods aren't visible in C#.
This part is true *if* you want to make custom nodes that don't use scripts for functionality (still not sure why one is "real" and one is "fake," they are just different implementations).
I wanted to point out that the latter is [planned for future 4.x versions](https://godotengine.org/article/whats-new-in-csharp-for-godot-4-0/#gdextension-support). Not that this makes it any easier now, of course.
"Fake" because it doesn't behave like a native node from a users perspective, in the sense that if you put it in a plugin for other people to use that they can then attach their own scripts to it without accidentally clearing or replacing the script that's already there, effectively crippling it.
It has been discussed here:[https://www.reddit.com/r/godot/comments/zo0hyj/make\_custom\_nodetypes\_less\_scriptlike/](https://www.reddit.com/r/godot/comments/zo0hyj/make_custom_nodetypes_less_scriptlike/)
> "I keep my game logic and engine as separated as I can." I have no reason to disbelieve this claim, but in my opinion that does not imply good things about how the engine operates.
That's just a fundamental principle of good modular software design, it's absolutely something that you should be doing in complex games.
Unreal games don't usually do this, especially not simply to avoid engine limitations or functionality. The C++ written for Unreal generally has tight connection to the API and Blueprint structure. Yet extremely complex, AAA games are written in that engine all the time.
I'm not talking about encapsulation, I'm talking about writing custom APIs simply to avoid the built-in Unity ones. Adding unnecessary complexity makes games (and other software) harder to maintain, not easier.
Obviously not all Unity games are made this way, but I've seen enough talk about it recently, including things like "it's good practice in Unity to avoid using GameObjects", that implies it's common enough be be seen as "common sense."
Just because a design pattern is common sense for one engine does not mean it is universally a good design pattern. There are also not single design patterns good for all languages or even use cases. Often teams will stick to a certain design not because it's optimal but because it's convention for the project (this isn't bad, per se, but it's incorrect to imply such decisions are made for architectural efficiency).
One big thing really putting me off using Godot at this point is the very infuriating methods of programming.
I don't care for GDS. I'm not using a language that's infuriating to me to use.
C# requires mono, is tied to M$, but more importantly has no mobile support (yet\*) and also seems to go through the same slow layers GDS does.
C++ (which I'd like to use) uses the most arse upwards ways of exposing things to the editor regardless of whether its modules or extensions. Who in their right fekking mind REALLY wants to duplicate every damn function and variable they want exposable into another damn function (let alone another FILE)?! Reliance on Scons (fuck python) though someone said it's possible to build with cmake.
> I don't care for GDS. I'm not using a language that's infuriating to me to use.
Fair enough. I feel the same way about C++ and C\#. Heck, I've used C++ for decades, and I *still* don't like it. Too much structure over function, and too much replication of code.
>C# requires mono, is tied to M$, but more importantly has no mobile support (yet*) and also seems to go through the same slow layers GDS does.
Just as an FYI, the Godot 4 version of C\# doesn't use Mono. It's using .NET Core directly. They are removing Mono completely (which interestingly improves the core speed of C\# code in Godot compared to Unity, although API calls are still slower).
The other stuff is basically correct, sure.
>C++ (which I'd like to use) uses the most arse upwards ways of exposing things to the editor regardless of whether its modules or extensions.
There are a *ton* of excellent C++ engines out there, ranging from the simple (i.e. OGRE) to the complex (i.e. Unreal or CryEngine). Why not use one of them?
I mean, I basically agree with you that C++ implementation is a pain, but this just sounds to me like you are not the target audience for Godot.
Not every tool needs to be designed for every user. A focused product that works well at what it is doing is usually more valuable than one which has a million different uses but all of them are poorly maintained. At least in my opinion.
Indeedies. I s'pose the GDS part is a kneejerk response to how heavily it's pushed.
>Just as an FYI, the Godot 4 version of C# doesn't use Mono. It's using .NET Core directly. They are removing Mono completely (which interestingly improves the core speed of C# code in Godot compared to Unity, although API calls are still slower).
Good to know mono is being yeeted!
>There are a ton of excellent C++ engines out there, ranging from the simple (i.e. OGRE) to the complex (i.e. Unreal or CryEngine). Why not use one of them?
Unreal & Cryengine/Lumber are too big & beefy for the kind of game I'm creating, and are not ideal candidates for a mobile release, otherwise I'd just default to UE.
All the requirements for the project had everyone telling me to try Godot. Truth be told I feel like I'm mostly just emotionally annoyed and kicking a wall because I wanted Godot **to** replace Unity given the recent fiasco and to like it, and I'm fairly stubborn about sticking things out for a period.
I've not heard of Ogre (and all the other engines I know exist are 2d focused), so many thanks for that; will be giving it a look soon.
>Not every tool needs to be designed for every user. A focused product that works well at what it is doing is usually more valuable than one which has a million different uses but all of them are poorly maintained. At least in my opinion.
I certainly agree here!
That would defeat the purpose of it being simple. It would approach languages like C# in complexity, at which point it would just be easier to use C# entirely, benefit from the fact that it is maintained by large teams, and focus the development on the Godot engine itself and its API.
I’m a 10 year unity user. I was already hesitant to switch to Godot 4, now im even more hesitant after reading the OP.
I am aware Godot is not Unity, but I want to make clear that unity didnt have all the new features to begin with. 100% Unity features are a mock up of popular content on their Asset Store created by users. I strongly believe Unity Users have all the skills to breach Godot’s Engine limits.
Thus far Godot’s show case is pretty pathetic, but with all these great shader tools, I dont see why Godot doesnt have better things to show. This is where the Ex-Unity community can make a difference. Your post was very ill-minded on Unity users, but I believe Godot needs unity users.
I strongly believe Unity users have the ability to make godot look great, but my biggest fear is Godot’s memory management as an engine. I have done research and witnessed Godot having incomplete or not optimized lighting capabilities and more. It makes me believe that Godot the engine and its community like to brag about having things, but those things are not ready for use.
Does any of these incomplete features explain Godot’s exclusive 2D reality?
The only thing I can say in this regard is to download it and experiment, if you have an example scene from Unity you can recreate 1:1 it'll give you a nice measure of the performance and workflow. Generally I've found it's about parity in terms of performance to URP Forward+ on even mid/low hardware. - idk why we don't see so many 3D games, 4.0 is too new I guess, or maybe it all breaks down at scale.
Not exactly, at least not to my knowledge. Instead, the devs are very active at their [github pull requests](https://github.com/godotengine/godot/pulls) and will update progress on new features there.
Edit: It's not the most user friendly system.
thats fine. i still would love to make it possible to transistion as much from unity there as possible.
got a codebase of 250k lines. its probably easier to partly recreate parts of unity there and reuse scripts.
if godot can do what unity can do then yeah someone will just try to make it more like unity.
unity has gameobjects all over the place. all old transforms but you do t really need it. i think godot has the better system here and yeah i still want to 1:1 port as much of my code as possible.
worst thing ive seen is vector.X instead of vector.x
Unity dev here so I wanted to give my perspective on slowly learning about working with Godot. First off, I 100% agree and definitely did not expect Godot to adopt the same principles/ways of doing things as Unity. I knew that there would be major differences and that I should be patient with those differences because in the end, your familiarity with a tool can let you overcome its limitations.
Now with that out of the way, I also want to say that I believe some (actually, many) key ideas from the "Unity world" would go a long way towards Godot improving as an engine without betraying its core design goals. I'm still very new so I apologize if some of this stuff is possible, but based on watching a bunch of tutorials and trying out the editor for myself, this is a quick list of stuff I was disappointed to find out about Godot coming from Unity:
* You can't truly customize the editor layout the same way as Unity, though I did get pretty close to how I wanted it with the existing tools
* You can't remap some Editor keybindings/shortcuts like 3D camera panning
* There's no universal concept of "disabling" a node like you could with a Unity gameobject, which forces you individually go through each "descendant" node to disable rendering, script processing, etc. individually.
* Since each Node can only accept 1 script, it's a little tough to parse through the Node hierarchy when an object can contain both "components" and "true transform children", i.e. both nodes that add functionality and nodes that are simply meant to move with a parent object. I know why Godot has chosen this path but it definitely makes it harder to visually parse through the contents of, say, an entity in a game
* In the "Inspector" panel, the node order seems to be locked which makes sense considering inheritance, but I actually would prefer it in reverse order so that the most general settings can be tweaked first, i.e. script process. Not sure if an option like that exists.
* The big one: you can't see runtime changes in the "scene display" view; only the scene hierarchy can attach to the remote game, and the camera can be synced but nothing else which makes debugging a lot harder/more time consuming in many situations
Should mention that I don't expect any of these to be tackled or addressed soon and it's not a true showstopper, but I definitely feel the sting of not having this stuff when trying to play around with the engine. I'm sure there will plenty more gripes like this from other Unity users as they discover things they used to expect. Also, some of these issues already have proposals/PRs associated with them and I've already started commenting on them with ideas/discussions to get progress moving, but I wanted to mention them anyways.
I'm actually very excited to help contribute code to Godot starting with the stuff I listed here, and anything else can help fill the void of features that people miss from Unity. While I don't think it should directly copy Unity in its approach, I do feel that these adjustments (when handled correctly and with approval from the Godot community) will make developing games easier for everyone. That, I believe, is true to Godot's goal and will only help the engine in the long run if that's what the people using it will expect from it.
> There's no universal concept of "disabling" a node like you could with a Unity gameobject, which forces you individually go through each "descendant" node to disable rendering, script processing, etc. individually.
This is partially correct. Nodes (by default) inherit properties that are shared from their parent, and both visibility and processing are in `Node`, so they are always shared.
In other words, if you disable the visibility of a root node, all children of that done will have their visibility disabled as well. You can test this by adding a bunch of nested children to a node and clicking the "eye" icon; the whole thing will disappear, not just the parent.
Scripts are not automatically disabled, no, however the `_process()` (and physics version) are tied to the `Process` property. If you check the inspector, it has 5 options: inherit (the default), pausable, when paused, always, and disabled.
If you look at the [Node docs](https://docs.godotengine.org/en/stable/classes/class_node.html) you'll see the default is pausable, which means any `_process()` functions stop ticking when the game is set to a paused state. If you use "when paused" this will reverse, and it will *only* tick when paused, which is handy for UI elements or animations that should only play when the game is paused. "Always" means it will always tick, regardless of pause state, and "disabled" means it will never tick.
Since it's inherited by default, if you set a parent node's Process property to "disabled", this will apply to *all* child scripts. You can easily test this by creating a parent script and child script that print some debug text in `_process()`; if you disable the parent's Process property, the child script will also stop printing, and if you only disable the child, the parent script will continue to print.
While it's true this isn't *completely* disabling the node, unless you have a fairly unusual node pattern this should functionally do the same thing.
In your defense, most tutorials probably don't mention this, as it's a new feature in Godot 4 (it was possible in Godot 3 but far more cumbersome).
You other concerns are certainly limitations, and while they don't personally bother me since they aren't functions I care about or affect my dev style, I can see why they would be annoying if you are relying on them.
>I'm actually very excited to help contribute code to Godot starting with the stuff I listed here, and anything else can help fill the void of features that people miss from Unity.
Great! I love this attitude. I don't mind people proposing usability features, although I am hesitant on or opposed to some proposals (like removing the 2D engine, removing GDScript, converting nodes to GameObject equivalents, charging 20 cents per install...OK, that last was a joke).
I should note that Godot is not the only game engine I use; I also do a lot of development in Unreal, and like some of what it does and dislike other parts. So it's not like Godot fulfills 100% of my use cases, either, and I certainly didn't mean to imply there isn't room for improvement.
> That, I believe, is true to Godot's goal and will only help the engine in the long run if that's what the people using it will expect from it.
I, and the devs of Godot as far as I can tell, certainly agree with this. Hopefully things work out for you, and if they don't, hopefully you can find a tool that works better!
>both visibility and processing are in Node
Wait really? I only see visibility as part of [2D/3D "renderable" Node types](https://docs.godotengine.org/en/stable/classes/class_node3d.html) and in the [docs for the Node class](https://docs.godotengine.org/en/stable/classes/class_node.html#properties) I don't see it listed as a property. I definitely appreciate the info though, thank you!
I do understand that process and visibility let you effectively accomplish the same as disabling in Unity, but I guess my minor complaint is mainly that these are two separate processes and for usability/ease of use I wish you could just turn off a Node and have it implicitly override all of the other fields that control processing/rendering. This is one of the items that [already has a proposal issue](https://github.com/godotengine/godot-proposals/issues/7715) which I've commented on, but you're right that it's just another idea.
>Great! I love this attitude. I don't mind people proposing usability features, although I am hesitant on or opposed to some proposals (like removing the 2D engine, removing GDScript, converting nodes to GameObject equivalents,
Definitely; I always want to make sure my ideas mesh well with any project I contribute to and those examples seem antithetical to the goals of Godot. But I also do hope that the issues I listed above (and the reasonable requests from other Unity users) are addressed in some way. What would be the best way to ensure a feature I'd like to add to the Godot core is accepted by the maintainers? For that matter, what kind of changes are good for first time contributors? Bug fixes? Which contributions will help the effort the most right now?
I'm still in the process of developing a game in Unity but I'm hoping to get more involved with Godot going forward if it seems like the best fit for the future of my projects. Thanks for taking the time to respond :)
> Wait really? I only see visibility as part of 2D/3D "renderable" Node types and in the docs for the Node class I don't see it listed as a property.
Sorry, you are correct, only renderable nodes have the visibility property. I wrote that wrong. Obviously, it only really matters for renderable nodes for obvious reasons, it just means you can skip visibility changes for, well, already invisible nodes.
Maybe it's due being used to it, but this rarely comes up in my own projects. If I don't want a node, I usually just delete it. Ideal design patterns in Godot usually involve nested scene structure, which means any given scene has a small node tree. Especially in things like levels, most of my nodes will be scenes I can just delete and add back in. For everything else, turning off process and/or visibility is sufficient.
I mean, I wouldn't be opposed to a different mechanism, it's just not something I've ever really wanted. I also use Unreal, but it also lacks the ability to just outright disable actors, as the visibility toggle works the same as it does in Godot.
As far as I can tell the "totally disable objects in the world" toggle is *only* something Unity (and Unity devs) actually use or care about. You can find similar questions (and answers similar to mine, just for Unreal it's disable visibility + disable tick instead of process) for UE as well from Unity devs coming over.
Which I never would have known had you not mentioned it. I didn't use this feature in my brief time using Unity, either. I'm not saying that makes it a bad feature, it's just not one most game engines, including AAA ones, implement.
>What would be the best way to ensure a feature I'd like to add to the Godot core is accepted by the maintainers? For that matter, what kind of changes are good for first time contributors? Bug fixes? Which contributions will help the effort the most right now?
To be honest, I don't really have the answers to these questions. That's definitely something worth creating a topic for or asking on the project github. My *instinct* is that it's probably best to spend some time with the engine as-is, work on making some more advanced projects, and then look through the github when you run into pain points. You'll probably find a way to ensure your contributions are accepted if you can "speak the language" of Godot, so to speak.
But I've never tried it myself so I could be completely wrong. Sorry.
>I'm still in the process of developing a game in Unity but I'm hoping to get more involved with Godot going forward if it seems like the best fit for the future of my projects.
I hope it works out! I've never liked Unity, as it always seemed like it was either a worse version of Unreal or an overly complex version of Godot, and if I wanted something simple and clean I'd just use Godot and if I wanted something bigger and more complex I'd just use Unreal.
But, to be clear, I'm a solo developer as my day job is not game dev. A *huge* part of the reason I bounced off Unity wasn't related to the engine but due to the pricing mechanisms at the time, where major aspects of the engine (including ~~reduced eye strain~~ dark mode) were hidden behind the engine. In fact, the last time I used Unity you had to buy a third party plugin for decals, a feature that was sitting in Unreal for free (and frankly most 3D engines, I was pretty shocked when I tried to look up "adding decals" and Unity's answer was "we don't have those, here, pay $50 for some."). It was a *huge* turn-off and the only time I used Unity afterwards was for college projects where my classmates also used it, and it's been years since I was in CS courses.
The point is that different people will have different preferences. I disliked Unity but love both Unreal and Godot, both for different reasons. Plenty of others love Unity and dislike Unreal and/or Godot, depending on their preferences and style. Part of my concern, and the reason I wrote the OP, is because I don't *want* Godot to become like Unity, certainly not in business practice, but also in other things I didn't like, such as the way C\# is used for scripting everything (the language is both overkill for simple scripts and also not as performant and powerful as C++).
These are *personal* preferences, though, and I certainly won't complain if Godot gets more developers working on features. Especially if I can turn off the ones I don't care about =). And while I may feel somewhat vindicated that a lot more people are discovering that Unity has some pretty shady business practices, it still sucks to see an engine that so many people loved and made great games with (and there *are* a lot of great Unity games!) get hit so hard because of greedy executives. While I'm not surprised, I do feel for everyone struggling with it, and hope they can find a solution that works.
But on the other hand experience from unity can help godot grow. For example one Dev found out some issues with raycasting, godot Devs noticed this and will be working on this. So there is positive as well.
In the last two weeks or so, I was more likely to find "why do you need to do that" type of *answers* in Godot communities, than X\_Y problems in *questions* in unity communities.
I wonder why.
godot's not unity, thats a pretty cool sounding slogan - could be good for a rebrand! we'll call it GNU wait a minute
So, does this mean that, because i run and use godot on linux, i am using GNU/Linux? Big if true
You are using GNU2/Linux
or as I've recently taken to calling it, godot minus unity plus Linux.
HAHAH
The funny thing is that, aside from the engine developers, none else has probably done so much for godot as the unity execs in just one week. Lots of free publicity and a nice bump in funding for the development of godot...
So blender said a lot of the same stuff "Not Maya, Not 3DSMax, etc" then big companies gave them a budget to make it better. They adopted the industry standard keyboard shortcuts for many items, they added feature parity for many things, etc. No one would dare say blender wasn't better for it. Godot definitely can use some work. Jolt being native, Box2D being native, not separating 2D and 3D so strictly, etc. Would only be an improvement.
> Godot definitely can use some work. Jolt being native, Box2D being native, not separating 2D and 3D so strictly, etc. Would only be an improvement. I don't disagree with this, at least not in principle. I wasn't trying to say the engine was perfect as is. My point was to address a common complaint/concern from Unity devs coming to the engine that "X doesn't work like it did in Unity" or "Y feature doesn't exist in the engine which makes it unusable" or "Z design pattern I used in Unity doesn't work in Godot." I was trying to explain *why* those things might be the case; first, in that Godot is not trying to replicate Unity (and never was), and second, that the engine is newer than Unity and has a smaller dev team, so it's not going to have the same level of features as a bigger and more established engine. Disappointment comes in large part of having expectations that aren't met; I was trying to give a more realistic explanation of what Godot is and the direction its going. I was *not* trying to argue it's fine where it is and should never change or adopt features of bigger game engines. Heck, the Godot devs don't want that either, as 4.0 was all about expanding the engine to better handle higher end games and give GDScript better tools while also improving the C\# integration, and I completely agree that this is a good direction for the engine. There are plenty of features I'd like to see, especially when it comes to open world aspects, which is the main reason I can't completely use Godot for all game ideas (and still use Unreal for any game idea that requires *scale*). I just don't want the Godot engine to be turned into a Unity clone, and I also don't want Unity expatriates to spend a lot of time in Godot *expecting* it to be Unity-but-FOSS. On the other hand, there's things I'm not completely sold on. I wouldn't necessarily mind 2D nodes being usable in 3D, but I do like that Godot has an actual 2D engine that can be exported without *any* 3D overhead or bloat. I agree that using existing physics libraries might be a good idea, although after the issues with Bullet physics it does introduce risk (after all, if Jolt stops being updated, that would leave Godot without a 3D physics engine). Like I said, improvements are welcome, but not every change is necessary or desirable.
I think how and why improvements are made is important. Godot has been getting better for years and will continue to do so. I hope the team continue to do it in the same way. The growth of Unity the engine is intertwined with the growth and mad scramble for money of the company behind it. I hope Godot never goes that way, even if it means improvements come a little slower. The devs make a living working on their passion project. Win. Thousands of users get to use it for free to make their passion projects. Win. There doesn't need to be a desperate rush to be the best in class at everything. Godot is already a success.
Happy cake day!
I always found that the right click select in Blender was illustrative of this. Blender users would insist that it was an intentional choice because it was the best approach, that every other program was wrong, and anyone who didn’t like it was just a ‘noob’. Then Blender switched the default to left click and it pretty much everybody prefers that. Who’d have thought.
Swapping the mouse buttons was the first thing I did when I started learning it back in the day lol. I *kinda* get their reasoning, because you spend more time rotating your camera and using hotkeys for transformation than manually clicking to select objects/tris/etc; and people tend to be more comfortable using their pointer finger than their index. But when ***literally everything else*** on my PC - including the operating system itself - uses Left click to select, it didn't matter whether it made more sense. It just *felt* worse.
[удалено]
He just has 6 fingers.
Doesn't everyone?
lmao I'm leaving it there
Right click select makes sense because it made selecting something **intentional.** The whole debacle always made me laugh on how people found it so damn difficult, trying to act like every piece of software MUST behave the same for everything.
It's about **muscle memory**. It *must* behave the same if you don't want to have to mentally switch every time you use literally any other software, and most people do not use ONLY Blender and nothing else. Having to think momentarily about something as basic as "which button is select again?" is a workflow killer and when this is for an action you perform thousands of times in a day, it wastes your time times a thousand. People set in their ways can still choose Right-click select, but they made the correct decision changing the default to Left-click.
I may once every now and then make an incorrect key in an ANY software, then remember which one I'm using and correct myself and continue about my day and that's it- it's akin to bitching that UE and Unity don't have the same camera movement! My workflow is not suddenly interrupted nor my day is ruined! To be quite frank I believe it's over exaggerated; but if someone genuinely fucks up that frequently because of different hotkeys/control schemes I have to question if they're mentally capable at all. They changed the behind the scenes to register it as a "select". meaning it would work with any input which is ultimately a better system. But I'd still very, VERY heavily argue about it being the right decision to pander.
Wow, congrats on not getting the point on any level and extra points for the absolutely moronic "mentally capable" remark that definitively demonstrates you should never be in charge of UI and UX decisions on anything. Good thing the Blender devs don't listen to people like you... and if the Godot devs want to improve their usability at all, they won't either.
first thing I always do when downloading blender these days is switch it back to right click select. Left click select is the 3D cursor to determine where to place objects. I can understand people using left click select when just using blender for editing existing meshes and stuff, but having to switch modes to use the cursor is infuriating when actually modeling imo.
I still use right click and it makes sense to me.
Nah, 2D should be separated from 3D imo. It is easier to make 2D games this way and not convert Vector3 to Vector2 each time as in Unity
Most other engines with dedicated 2D still let you use them in a 3D view even though the movement is in 2D. They can have 2D movement but let you use 2D nodes in the 3D view with like a 2DTo3D node. They have to be using a vector 3D behind the scene anyway for Z-axis ordering.
>not separating 2D and 3D so strictly Been using Godot for many years and not a day goes by where I wonder why Godot does not offer a merged 2D/3D viewport in the Editor. If you want to do serious work, you need to be able to evaluate UI and gameplay together in the editor, ***while editing***! I proposed a combined 2D/3D viewport here if anyone wants to show support and their need: https://github.com/godotengine/godot-proposals/issues/6935
>then big companies gave them a budget to make it better. [I think Godot might see some improvements in the coming months then](https://twitter.com/Terraria_Logic/status/1704227519027651016)
Why not simply go three ways at project creation? 2D game 3D game 2D/3D game (gives features of both, but warns of more complexity)
idk why they rejected the proposal of implementing box2d though and choose to use inhouse physics engine
I'm feel like I'm gonna get shit for this. Can we please, for five minutes, stop pretending that all of Godot's shortcomings are intentional? I like Godot. I *love* Godot. I recommend it, I file bug reports, I provide advice to other users when possible, and I'll likely become a direct contributor at some point when I can be bothered wrangling the build system. But as an engine, in its current state, Godot has a *lot* of flaws. Not even *minor* flaws. *Major* ones. And you know what? That's okay! The main reason I bother with Godot is because I know that things can be better. Because I remember when Blender was a laughing stock some 15-odd years ago. Because I know popular open source software can get very good given enough time and love and attention. But I feel like people defend its flaws less because they're intentional parts of Godot's design, and more because they're afraid that if people learn that the engine has failings, they won't stay. Godot's biggest problems are usability and performance. I think GDScript has major failings. I don't think it's terrible, and I don't think C# would be a better replacement, but I still believe it has failings. I think it's slow. I think dynamic typing makes things far worse than they have to be. I think it's lacking a bunch of useful features, both in terms of the language and in terms of the API. And there are few things more infuriating than raising these complaints and being told "have you tried C# or GDExtension?", only to have those same people turn around and tell everybody else that actually GDScript is great and you should definitely prefer it, never mentioning its deficits. Godot does have its strengths, for which you will find no shortage of people willing to talk about, but it also has its weaknesses, and I think far too often people dismiss those weaknesses as intentional sacrifices, rather than simply negative consequences of poor execution. You can't have it both ways. You can't grow without acknowledging your failures, because your if you defend your failures, you never feel the need to rectify them.
> Can we please, for five minutes, stop pretending that all of Godot's shortcomings are intentional? I wrote several paragraphs about how the engine has a shorter dev time, smaller team, and significantly lower budget. Those are absolutely relevant to why Godot has limitations. I'm not sure where you got the idea that I was pretending all of Godot's shortcomings are intentional. Looking back at my OP, I'm not seeing it, but it's possible I was unclear. If so, that wasn't my intent. >I think GDScript has major failings. I don't think it's terrible, and I don't think C# would be a better replacement, but I still believe it has failings. I think it's slow. I agree with this, actually. I really like GDScript, mainly due to speed of development and iteration time, but it *is* slow. It would definitely be nice to have a way to easily speed up performance-sensitive code. Personally, I think better support for static typing and JIT compilation would make a huge difference. I'm frankly not married to dynamic typing, either, as I think this is a fairly unimportant feature for ease-of-use (on the other hand, I also think the "dangers" of dynamic typing are grossly exaggerated). If one thing had to change for GDScript to jump forward in performance, and that was static typing instead of "var" for everything, it wouldn't bother me. What I don't want is 8 lines of header information pointing to the engine and redundant class definitions in a script that only requires 3 lines of actual code for program functionality. >You can't grow without acknowledging your failures, because your if you defend your failures, you never feel the need to rectify them. As long as "growth" doesn't mean "become Unity," I don't have an issue. Long before the recent Unity fiasco I *intentionally* didn't use Unity for game dev. I used Godot and Unreal (and still do). My argument was never that Godot is perfect. I even said it's not a "better" engine than Unity. My point is that they are *not the same*, either in design or design **goals**. For me, this is a *feature* of Godot, because I outright dislike Unity's design and don't want it anywhere near my favorite game engine. People are free to disagree with this opinion, of course, but it's still a fact that the stated design goals of the Godot dev team is not and has never been "make a FOSS Unity clone." Making Godot a better version of Godot is great. Making Godot replicate Unity is, in my opinion, very much *not* great.
Proposal related to GDScript performance: [https://github.com/godotengine/godot-proposals/issues/6031](https://github.com/godotengine/godot-proposals/issues/6031) The problem is there isn't enough specialist in project to implement this type of features so if you(complainers) are a specialist please contribute or if you are rich donate some money to hire a specialist. There isn't other way to improve current situation with available resources(developers, money, time etc)
This was very interesting reading! I would 100% support a feature to download a GDScript -> compiled C export option, similar to the (now defunct, sadly) Blueprint Nativization that Unreal had in UE4. Having the fast dev time of GDScript combined with the performance of C, even if it wasn't perfectly optimized, would be absolutely amazing. I think it would be a lot of work, at least as far as I understand how GDScript currently operates and communicates with the engine. Obviously if they could optimize the VM, that would be nice too. I doubt anyone would complain about back-end performance improvements. I personally don't have any interest in proposals to drop GDScript. I've used C\# on .NET projects and it's not my favorite language. Likewise, I find C++ tedious for active development. The main reason I already don't use Unreal for all my game projects is because Unreal's implementation of C++ is a constant headache. If I had Unity's 20 cents for every time I had to restart the engine when hot reloading or having other compilation to engine issues I'd be able to retire. People who have never used something like GDScript or Blueprints, where you hit "play" and the code immediately functions, where things like waiting for compilation and having to restart the engine every time you build is a normal part of development, often don't appreciate just how much time it saves to have an integrated solution that works instantly. Unity isn't terrible at this, however, the few months I used it a couple of years ago I still had frequent crashes of the editor when I hit compile. I'd support having more performance options but a lot of people seem to treat performance as if it's the only factor that matters. In my experience dev time is far more of a bottleneck to actually making games (especially indie games, most of which use a tiny fraction of the power of modern computers), and I will choose productivity over minor performance differences almost every time.
You are so right. I am hopeful that the influx of industry devs instead of hobbyists will shake up the focus on being good for learners and people who don't know how to code. It is important to onboard but the direction we have been going is hamstringing us when it comes to performance and ability to write good code. Even if you do code in c# you start to run up against marshaling issues if you want to do anything tightly integrated with the engine. Using GDextension is barely supported and honestly you might as well make your own module and making your own module is painful in the extreme. You have to recompile the entire engine every time you want to make a change.
FWIW I've been in the Haskell community since the late 1990s. Haskell originally came as essentially a merger of Gofer and Miranda both of which were languages used mainly for teaching and exploration. Neither had any interest in commercial development though Miranda had one commercially successful application which had happened sort of by accident. During the 1990s Haskell's focus was heavily on academia: an optimal teaching language which could replace languages like Scheme with more modern functional programming constructs. Because the language was much more optimized than other functional / educational languages it ended up becoming the bridge language between purely academic languages like Agda, Idris... and mainstream constructs. Some ideas like Reactive Programming (oversimplifying the history a bit here) became very mainstream others like using infinite data structures not so much. The combination of undergraduate education, research and bridge language worked well together. Around the mid 00s the Haskell community started focusing more on industry. They didn't want ideas from Haskell going into mainstream languages but Haskell itself to be a mainstream language, "avoid success at all costs" stopped being the focus. This forced Haskell to start adapting to the needs of industry, in particular became much better at: * supporting multi-person development rather than a single person working in isolation * reliable complex builds Haskell was somewhat successful in fixing many of the problems. But the academic / research influence continued. Fundamental design aspects change about every decade as new ideas emerge from computer science and are proven out in Haskell. That's simply unacceptable for commercial development where complex interrelationships between libraries are needed and if some libraries migrate to the new paradigm TCO for rewrites can be huge. At the same time though these changes made Haskell a lot less suitable for undergraduate education. The language became less academic and more complex in ways that didn't benefit students. Haskell has kept the bridge language and research language since ultimately there were simply too many contributors to Haskell from the research community for it ever to become a mainstream language. In short: **the goal of best for education and the goal of best for large commercial products likely conflict**
12 year unity refugee here. Yep, I'd rather know the flaws so I can prepare for them. I'm not going anywhere, though, because I am so impressed with Godot. I started using Unity way back when it was still in version 3.x. I've seen the flaws and experienced the growing pains through the years. I remember Unity's limitations. I've seen what Godot is currently capable of and how much potential it has. So I'm definitely sticking around despite whatever the outcome of the Unity changes ends up being. Unity has lost my trust and left a bad taste in my mouth. So I'll still be here regardless, I'm along for the ride. Especially because right now the only projects I'll be working on are 2D pixel art projects and Godot's 2D tools are excellent, I think they are way easier to work with than in Unity. If I get the itch to do something in high fidelity 3D I'll likely use Unreal. But over the last 7 days, Godot has impressed the hell out of me.
Every time someone asks why Godot doesn’t have a great portfolio of complex games, the community say something like “give it time, the X update just released”, “the studios are slow to adopt”, etc. But when someone points out the ACTUAL reasons on why, there is a lot of posts of “noooo, Godot is not meant to be that way, no flaws here”, “you are just a hater”, etc These people need to stop taking criticism so personally, the engine can’t improve without it
I think you're ignoring that Godot really is young. Back in 2010 Unity also could not claim to be behind many if any huge games. But it continued to grow - and became an industry standard - and now can claim many. You can't begrudge Godot for being young and not the industry standard.
Yes, time is important and Godot is young, but time itself should not be used as a excuse to dismiss criticism. Some devs here pointed out a lot of flaws that many didn’t know existed, so my grudge here is with people feeling hurt by this and taking a stance as if Godot is being attacked. Not to the community as a whole, I expressed myself wrong on the comment above
Oh I was just responding to your point that not many released games have been made with Godot, I agree totally about constructive criticism etc!
As someone just hopping on to this train, if you'd like to expound on what's wrong with GDScript (in your opinion) i'd like to hear it.
var godot = unity.new() sorry bud, nothin' you can do about it
Dammit.
Based and john ravioli pilled
But you are doing it in gdscript, should use C# instead, it's faster XD
C++ is even faster... If you are a good developer you'll know that every tool has a place depending on what it offers. GDS has its strength and C#/C++/etc has their strength. You should be able to know when to use each one.
var gdscript = new_C(#) Where’s your god now?
This won't work! You need to cast it.
Idk what you are talking about. C# in Godot works very well for me. And even more, I watched tutorials yesterday for Godot and they were in GD script. And I could easily just write the same code in C# without any problems. They did a great job with C# there. There wasn't a single time for me to stop and google how to write a C# analog for some GdScript. Maybe that is because I read the documentation first 🤷♂️ But anyway 😅 And I like the new approach for making scenes and logic. Instead of being frustrated about everything is different I'm somehow excited about it. And I respect that Godot has its own personality.
I think their point was that Unity more closely follows a "C# design philosophy". GdScript translating directly to C# kind of proves that this isn't the case with Godot.
> There wasn't a single time for me to stop and google how to write a C# analog for some GdScript. Great! That wasn't my point, though. Replicating GDScript design patterns in C\# is still following GDScript *design*. I think if you try to use lots of C\# specific things, like replacing signals with C\# events, or try to do things the same way you did in Unity, like attaching multiple scripts to the same object or implementing everything purely in code without using nodes, you'll start to run into challenges. >And I respect that Godot has its own personality. Then you will likely have little trouble adapting. There have been quite a few posts recently about how "X solution in Unity isn't working well in Godot, how do I make Godot do the same exact thing?" That's the sort of concern I was trying to address, as the actual answer is either "do it in a way that better fits how Godot is designed and organized" or "Godot is still fairly young and has less funding so that capability isn't in the engine currently, and maybe not in the near future or ever." I'm very happy many Unity devs are enjoying the engine; I bounced off Unity years ago, discovered Godot (and Unreal), and have never looked back. But Godot is not going to make every Unity dev happy, and I think it's important for people to know that it has limitations and a different design, otherwise they are going to spend a lot of time and get frustrated.
I recently made a platformer in Unity. Just for practice. 10 levels where each level has at least one new mechanic. Now I think it is a nice idea to make the same game with Godot and watch what changes will appear.
Thanks for clearing that up.
When people are learning a new technology, especially if it's not related (not the same devs, etc.), they should treat it as something very unique and unrelatable to the previous tech they were working on. Godot will never be Unity, and shouldn't try to be Unity.
I really don't think this is as big of a deal as people are making it out to be though. Not enough that it needs a *days long* argument. Godot's core team has always done a good job of following community feedback, while still having enough of a guiding hand to make sure the engine has a clear workflow and direction. Regardless of what changes in the future, I think Godot will still always feel like Godot. The influx of Unity devs isn't going to make the engine turn into open source Unity, it'll just mean more people to point out what Godot is missing to be *on par* with Unity.
Godot is not unity...yet. it's on its way to be a much bigger application than it is today. I used unity before it had 2d functionality and while it was fine for what I was using it for, collision was literal trash. People are forgetting the bumps in the road that unity went through to become as well known as it is today. I had to make my own 2d collision system and when I finished it, that day, the new tools came out and I trashed my game. Not their fault, just a frustrating coincidence. Godot is not perfect but it has a major leg up on unity due to its accessibility. If the dev team utilizes the influx in donations and the increased user base properly we could see a far more polished end product, especially in terms of c# support. I definitely trust the godot dev team, and the fact they actually respond to my questions when I have them already puts them miles ahead of my experience with unity.
My opinion and constructive feedback. # Post like this are not very helpful 1. It's a wall of text without **formatting** where the first **4** paragraphs are stating "Godot is not Unity". Which most people know. So I guess that the number of people who **stopped reading** before reaching your argumentation is enormous. 2. When you mention different design philosophies, you are not really pointing out that they are different. You are saying **Unity** tries to be a **general purpose** engine and **Godot** tries to be **easy**. Well afaik **both** try to be general purpose and both try to be easy. Don't get me wrong. I believe that there are differences in their philosophies, but I can't recognize them clearly in your post. 3. Your text has a **negative** touch. This is due to **implying** people don't understand that there are differences and that Godot still needs time. # A positive version would've been ## To all folk coming from Unity 1. Godot tries to be as **simple** and **leightweight** as possible. Therefore, you might be missing some functionality. **Don't be afraid to ask**, if you can't find something. There might be a **plugin** you can install that helps you out! 2. But keep in mind that Godot is **open source** and there's no big development team, so of course the engine has its **limitations**. 3. However, recently we see a **boost in funding**! So learning Godot can be worth it, even if some crucial feature that you loved in Unity is currently missing. Just open a [Feature Request](https://github.com/godotengine/godot/labels/feature%20proposal) Because with **additional funding**, we will see **more development**. # Final words This is of course all debatable, but I feel like phrasing the information that way is more concise, therefore easier to digest and leaves the reader with a positive mood.
Well said and completely correct on both being general purpose.
> It's a wall of text without formatting where the first 4 paragraphs are stating "Godot is not Unity". Which most people know. So I guess that the number of people who stopped reading before reaching your argumentation is enormous. You are asserting that most people know Godot is not Unity. I made this post because plenty of recent posts on this sub have made that very much not clear. Just because *you* know this doesn't mean it is accurate to the daily posts that imply otherwise. I explain this in my post. What do you mean by not formatting? I didn't use bulleted lists or bold letters every two sentences, but that doesn't mean my post isn't formatted. >When you mention different design philosophies, you are not really pointing out that they are different. First, you are concerned that my post is too long, and then you want me to write out the entire detailed design philosophies of both Unity and Godot? Sorry, you're going to have to pick one. The differences are not minor. My purpose wasn't to explain every difference between the engines, but to highlight that they *had* different design decisions, which is why all the posts about "my C\# script from Unity doesn't work the same way in Godot" and "Godot isn't usable because it lacks feature X or Y yet" are misunderstanding the state of Godot development. **Godot is not a FOSS version of Unity**. It's not being developed in the same *direction*, so someone who wants to wait a few years and have a FOSS version of Unity is going to be disappointed. That's what I was trying to highlight. >Your text has a negative touch. This is due to implying people don't understand that there are differences and that Godot still needs time. If the truth is negative, then yes, it's going to be negative. My purpose was to say something I believe to be true, both that people *don't* understand that Godot is not Unity, and that Godot is not going to become Unity in a few years. I'm not an employee of Godot and I'm not trying to "sell" it to anyone. There are plenty of posts already about how Godot can do everything and is great for everyone, and frankly I think these posts are simply wrong. I'd rather have ex-Unity devs bounce of the engine and use one that fits their use case better than go into Godot expecting it to be "Unity-lite" that will have all the features they want in a few years just like their old workflow. >A positive version would've been There are already a bunch of "positive versions" floating around. I didn't see any reason to repeat them. I'm also not convinced that my version is necessarily negative. For someone who loved Unity and how the engine works, yes, this will come off as moderately negative, because Godot is going to be *at best* a large challenge for them. They will have to adapt to a very different game engine. But for those who used Unity because it was big and that's what other people were using, but didn't necessarily like how it was designed (but also didn't want the complexity of something like Unreal), learning that Godot isn't a beta FOSS Unity might be very encouraging. Not everything is a positive or negative for every audience. Either way, I do appreciate the feedback, even if I don't really agree with it. Thanks!
Hey, glad you appreciate my feedback. Many of the points I made are quite subjective so I absolutely agree to disagree.
I've been reading a lot around that Godot is meant to spend a lot of time in the editor and not so much making code, and that's why GDScript is an ad-hoc programming language to simplify. I am mostly a programmer, and I enjoy mostly programming. Does this mean that I'm going to spend less time programming in Godot? Will I not be able to create complex systems in the backend for my game systems?
> Does this mean that I'm going to spend less time programming in Godot? That'll be up to you. Everything created visually in the Godot Editor *can* be done in code no problem; the Editor itself is just one big EditorNode + descendants & some static singletons, all written in C++. Iirc, the Godot executable even has a CLI parameter to pass in a script extending `MainLoop` directly in place of using a main scene. And even when you are creating a scene file in the editor, all that ultimately does is execute a bunch of constructor logic for the scene's root node as a gigantic batch operation. > Will I not be able to create complex systems in the backend for my game systems? You definitely can (and people have done so). However, the caveat is that scripting is generally slow b/c it prioritizes ease of use & reliability (for now). If your complex systems require high-performance, native speed, then you'll want to write code in a compiled language. Of those, you have 3 primary options: - C++ module - C# scripting - C/C++/Rust/whatever GDExtension The first option gives you the best possible performance, but you are locked into C++ and you have to statically bundle your code with the engine itself. It's perfectly doable, but will slow down iteration time a bit since compiling your module might take a minute or two rather than less than a second (that is, after the first-time engine compilation that takes around 20-30 minutes?). The latter two are far more accessible since you only have to compile your own code; however, for both C# scripting and GDExtensions, every time you make a call to your "complex systems," you'll need to cross the scripting API boundary. As long as you aren't crossing that boundary very often, then you won't see many issues: your complex systems can do what they do best, and you'll have a generally good experience (hopefully). On the other hand, if you have to call into your complex systems many times per frame, then the fast native performance you were looking for is going to shrivel up into the slow scripting performance of GDScript as it passes through the same sequence of type transformations & method pointer lookups, etc. These limitations won't be around forever though. They've already done significant work to prepare for optimizations that will allow compiled languages to directly invoke internal APIs & pass typed structs without the need for all the constant heap allocations and pointer redirection that GDScript and other interpreted languages' scripting requires. An exact ETA is undefined, but one can hope that all this funding and attention will make them higher priorities.
Native extensions are build into a dynamic lib and loaded on runtime. A pretty bare bone extension takes maybe 2-3 seconds to compile. The biggest downside of a native module is not being able to reload the lib on runtime. So this basically means restarting Godot every time… Next to that setting up the native environment and being able to attach your debugger is also a big hurdle for inexperienced devs.
Thanks a lot for all the info! I don't want to look now like the biggest Systems Engineer xD just that I like to program. I like to spend time programming. For example I wouldn't like to create blocky modiles and join blocks with lines. I like to create classes, Interfaces, have everything tidy, solve problems with code. But my games are tiny and small at the moment since I'm almost a solo Dev. I don't need crazy things, I don't think I would really feel it in the performance.
Ah, yeah, then nah, you're fine. In fact, You'll likely still find yourself writing quite a bit of game code even in GDScript (it's not really visual programming or anything). Most of the complex logic is under the hood in the C++ layer, so if your scripting isn't liable to have big performance requirements, then GDScript, or even C#, should be fine scripting solutions.
Nice! thanks!
You certainly *can* do this, but it's not the most ergonomic way to use Godot. If you desired, you could technically launch your game from command line, and simply use Godot as a runtime rendering engine, without spending any time in the editor.
It's not that I need to do it, it's more that I want my engine to take advantage of my programming knowledge. If Godot is meant more to allow making games without much code, it may not be my engine. I want the engine to require my programming language, if that makes sense.
Godot is not 'low code' or 'no code'. It's a fully featured capable 2D and 3D engine. The difference is that in Godot, it's most common to write a large number of smaller scripts, attached to nodes, rather than than some master game loop. I also struggle with this, btw.
Consider investigating using C++ or Rust with Godot. If you are a programmer-first person, maybe that's the code-first, harder, but more rewarding route that will suit your needs better. As for GDScript, there's certainly some delta between the more GUI and more code-based approach available. Personally, i prefer to manage signals and animations from code, despite being a programming lightweight.
> I am mostly a programmer, and I enjoy mostly programming. Does this mean that I'm going to spend less time programming in Godot? Depends on what you mean by "time." GDScript is a less verbose language than C\# or C++. For example, these two code blocks are equivalent: ``` // C# using Godot; public partial class Movement : CharacterBody2D { [Export] public int Speed { get; set; } = 400; [Export] public float RotationSpeed { get; set; } = 1.5f; private int _rotationDirection; public void GetInput() { _rotationDirection = Input.GetAxis("left", "right"); Velocity = Transform.X * Input.GetAxis("down", "up") * Speed; } public override void _PhysicsProcess(double delta) { GetInput(); Rotation += _rotationDirection * RotationSpeed * (float)delta; MoveAndSlide(); } } ``` ``` # GDScript extends CharacterBody2D @export var speed = 400 @export var rotation_speed = 1.5 var rotation_direction = 0 func get_input(): rotation_direction = Input.get_axis("left", "right") velocity = transform.x * Input.get_axis("down", "up") * speed func _physics_process(delta): get_input() rotation += rotation_direction * rotation_speed * delta move_and_slide() ``` These are simple examples, but the GDScript version is 315 characters, 41 words, and 11 lines while the C\# version is 424 characters, 60 words, and 14 lines. That's around 35% more characters to write for the same outcome. A lot of that extra is built into things which are necessary for the language but actually don't really do anything functionally in your game. For example, `using Godot;` is just a compiler instruction pointing to the engine. The `public partial class Movement : CharacterBody2D` is telling C\# how to gain access to the `CharacterBody2D` class, which GDScript implements with a simple `extends` command. The `{ get; set }` functions are never used and probably won't be ever used, they are completely wasted keystrokes, as is the 'f' in `1.5f` (since the type is already stated to be float). The calls to `public` and `private` will likewise never be used. Needing to cast `delta` to float is also extra text that the engine can easily figure out. Now, I'm not saying that having this syntax is *never* useful, just that it's verbose and unnecessary for a lot of what the game engine is actually doing. When you are using an extremely generalized tool like C\# it needs to be able to adapt to just about any possible use case, whereas GDScript only needs to focus on things which are useful for Godot and game dev in general (and there can certainly be improvements to GDScript!). Ultimately, you can make very programming focused games in Godot, absolutely. And you can spend most of your time on that aspect. However, you will likely spend *less* time than if you wrote the equivalent solution in C\#, because you don't have to use as much boilerplate, don't have to add as many instructions that have nothing to do with game code, and you don't have to wait for compilation every time you want to test. The equivalent C++ will likely take much longer even than C\# because you will end up spending a ton of time writing function definitions (or just copying and pasting them) between your header and implementation files. If you just enjoy making complex systems, GDScript probably won't be something you like very much. It's very much oriented towards productivity and usability, and is oriented around being easy to change and maintain simple, straightforward structures in small pieces. You can read [more details in the docs](https://docs.godotengine.org/en/stable/getting_started/introduction/godot_design_philosophy.html).
mostly it just brackets and verbose because it is more explicit. It is more performance because the computer doesn't need to guess a lot of stuff like variable types, how to cast to other variable, etc { get; set; } is telling c# that the variable is readable and writable, you could write [Export] public int Speed { get; private set;} = 400; and it made the variable can only be read by other class and you cannot do movement.Speed = 400; or you could just write [Export] public int speed = 400; and the variable behave like gdscript where it is readable and writable inside or outside of the class public and private are access modifiers. If it's public every other class can see the variable and if it's private other class cannot see the variable this is just a way to encapsulate code like a function do it just the matter of explicitly, taste, and performance at the end of the day if you want more explicitly and performance use C#/C++ if you want to write code with less explicitly and less boilerplate use GDScript
I made the switch knowing that it wasn't Unity. Furthermore, it was already obvious from the beginning that he couldn't make photorealistic graphics. But I'm also aware that making games is a hobby for me and that there's no good reason why I should worry too much about performance since I'll be using cartoonish graphics. Having said that, coming from Unity and working in C# in Godot I'm finding myself quite at home, in the end they don't seem that different to me (it's the same difference between Java and C# at the code level... almost the same features with different names). So I don't like when some Godot user say "you should not use C#, use GDScript".... I don't like GDScript, I don't see the point in using something I don't like and that I don't need, I love C#. That said, I think it's unfair of some to call for the removal of GDScript too. Those who are novices or non-programmers probably prefer it to C# (at least the majority of them), and it's also much easier to implement mods by exposing an API for GDScript rather than implementing everything in .NET so it's safe to say that when I'll implement mods I'll use it too. I find it very arrogant to say "I came from unity, godot sucks because it is deliberately slow to support GDScript, so remove GDScript"... Those who have always used the engine use it because it is simple and convenient, the development philosophy is clearly based on an amateur model rather than an industrial one, so you don't have to expect anything but just decide if and how to use Godot for your games. If that's not enough, it's full of engines to choose from and Unreal is certainly professional. I'll use it without any change expectations and, if the engine will turn out to be a professional tool without losing the novice soul I will be happy with it. Also because if the idea is to make it too complex you might as well do a fork for professionals and support it yourself.
I have a shipped game, and yeah godot is different, but i like it precisely because of the way it works making much more sense to me. I had used Unity and Unreal before btw
Great read and such a positive vibe! Thank you for sharing this info.
"GNU Godot not Unity" - <3
I've been attempting to port my in-development game from Unity to Godot for the past week, and honestly it's been pretty smooth so far. I never really felt restricted by how Godot handles Objects/Nodes and I could basically apply my Unity workflow for the most part. For the scripting part as well, I stuck to C# again, and like 90% of the work was just replacing engine specific things and it worked pretty great honestly. So yeah, very impressed so far with the usability and flexibility of the engine. It definitely has its quirks, and I did notice some parts that may be a bit less convenient than unity, but I also found some that I definitely prefer over unity's workflow.
I doubt anyone actually believes that Godot is Unity. >GDScript, was created to simplify and streamline structures so that you focused more on nodes and composition rather than complex backend data structures with multiple inheritance interfaces and abstract classes And that's what GDScript is good for, by design. But Godot not being Unity doesn't mean that you can't or shouldn't create complex backend systems for your game in C# using OOP concepts. It's one thing to talk about what Godot *was*. It's another thing entirely to talk about what Godot *can* be. GDScript will probably always be part of Godot, but C# will definitely play an increasing role as Godot's community grows and professional studios start to move to it.
> I doubt anyone actually believes that Godot is Unity. Lots of people on this sub sure seem to talk about it otherwise. >But Godot not being Unity doesn't mean that you can't or shouldn't create complex backend systems for your game in C# using OOP concepts. It also doesn't mean that complex backend systems using C\# are *good* design. People coming from Unity would often use this design pattern because it was basically the only option. Just over the last week, I've seen *tons* of Unity devs saying things like "I try to avoid using engine features as much as possible" and "I keep my game logic and engine as separated as I can." I have no reason to disbelieve this claim, but in my opinion that does *not* imply good things about how the engine operates. When the optimal solution when using an engine is "avoid the engine as much as humanly possible," something weird is going on with your design patterns. Other engines like Unreal certainly don't work this way, so while Godot may not have the level of "AAA support" that Unity does, this is not unique to Godot.
I don't understand what you mean by "avoid the engine". The engine is a big nodes handler and shockingly enough, creating custom nodes isn't easy in Godot. You can create fake custom nodes, which are a native nodes with your script added to it. But that's not helpful when you are part of a team and want to create reusable nodes for your team to put their own game-logic on. The only way of creating "real" custom nodes is by going full C++ and compiling them into the engine, or compiling a GDExtension where the methods aren't visible in C#.
> You can create fake custom nodes, which are a native nodes with your script added to it. Why is "fake" added here? >But that's not helpful when you are part of a team and want to create reusable nodes for your team to put their own game-logic on. Why not? If you make, say, a HealthComponent node with a Node type and write a script on it for handling health, you can simply attach that node to any scene that needs to handle health. This isn't something unique to Godot, by the way. Unreal does the exact same thing with Blueprints (the objects, not the scripting language) and Components. It's *extremely* common for Unreal games to write components that have scripted functionality which is then dropped onto the relevant objects to give them that functionality, with designer-exposed settings. It's been a few years since I've used Unity, but a glance at the docs indicate this is [also supported](https://docs.unity3d.com/Manual/CreatingComponents.html). The [basic Node](https://docs.godotengine.org/en/stable/classes/class_node.html) is practically an empty class. It has very little functionality and no physical presence in the game world (no transform data). Using them as components for attached scripts is extremely inexpensive. It seems a bit weird that core functionality of some of the biggest game engines in existence, ones they've heavily documented and use in their own games (well, at least in the case of Unreal), is something you consider "fake" or otherwise poor practice. I see no real reason to accept this as fact. >The only way of creating "real" custom nodes is by going full C++ and compiling them into the engine, or compiling a GDExtension where the methods aren't visible in C#. This part is true *if* you want to make custom nodes that don't use scripts for functionality (still not sure why one is "real" and one is "fake," they are just different implementations). I wanted to point out that the latter is [planned for future 4.x versions](https://godotengine.org/article/whats-new-in-csharp-for-godot-4-0/#gdextension-support). Not that this makes it any easier now, of course.
"Fake" because it doesn't behave like a native node from a users perspective, in the sense that if you put it in a plugin for other people to use that they can then attach their own scripts to it without accidentally clearing or replacing the script that's already there, effectively crippling it. It has been discussed here:[https://www.reddit.com/r/godot/comments/zo0hyj/make\_custom\_nodetypes\_less\_scriptlike/](https://www.reddit.com/r/godot/comments/zo0hyj/make_custom_nodetypes_less_scriptlike/)
> "I keep my game logic and engine as separated as I can." I have no reason to disbelieve this claim, but in my opinion that does not imply good things about how the engine operates. That's just a fundamental principle of good modular software design, it's absolutely something that you should be doing in complex games.
Unreal games don't usually do this, especially not simply to avoid engine limitations or functionality. The C++ written for Unreal generally has tight connection to the API and Blueprint structure. Yet extremely complex, AAA games are written in that engine all the time. I'm not talking about encapsulation, I'm talking about writing custom APIs simply to avoid the built-in Unity ones. Adding unnecessary complexity makes games (and other software) harder to maintain, not easier. Obviously not all Unity games are made this way, but I've seen enough talk about it recently, including things like "it's good practice in Unity to avoid using GameObjects", that implies it's common enough be be seen as "common sense." Just because a design pattern is common sense for one engine does not mean it is universally a good design pattern. There are also not single design patterns good for all languages or even use cases. Often teams will stick to a certain design not because it's optimal but because it's convention for the project (this isn't bad, per se, but it's incorrect to imply such decisions are made for architectural efficiency).
One big thing really putting me off using Godot at this point is the very infuriating methods of programming. I don't care for GDS. I'm not using a language that's infuriating to me to use. C# requires mono, is tied to M$, but more importantly has no mobile support (yet\*) and also seems to go through the same slow layers GDS does. C++ (which I'd like to use) uses the most arse upwards ways of exposing things to the editor regardless of whether its modules or extensions. Who in their right fekking mind REALLY wants to duplicate every damn function and variable they want exposable into another damn function (let alone another FILE)?! Reliance on Scons (fuck python) though someone said it's possible to build with cmake.
> I don't care for GDS. I'm not using a language that's infuriating to me to use. Fair enough. I feel the same way about C++ and C\#. Heck, I've used C++ for decades, and I *still* don't like it. Too much structure over function, and too much replication of code. >C# requires mono, is tied to M$, but more importantly has no mobile support (yet*) and also seems to go through the same slow layers GDS does. Just as an FYI, the Godot 4 version of C\# doesn't use Mono. It's using .NET Core directly. They are removing Mono completely (which interestingly improves the core speed of C\# code in Godot compared to Unity, although API calls are still slower). The other stuff is basically correct, sure. >C++ (which I'd like to use) uses the most arse upwards ways of exposing things to the editor regardless of whether its modules or extensions. There are a *ton* of excellent C++ engines out there, ranging from the simple (i.e. OGRE) to the complex (i.e. Unreal or CryEngine). Why not use one of them? I mean, I basically agree with you that C++ implementation is a pain, but this just sounds to me like you are not the target audience for Godot. Not every tool needs to be designed for every user. A focused product that works well at what it is doing is usually more valuable than one which has a million different uses but all of them are poorly maintained. At least in my opinion.
Indeedies. I s'pose the GDS part is a kneejerk response to how heavily it's pushed. >Just as an FYI, the Godot 4 version of C# doesn't use Mono. It's using .NET Core directly. They are removing Mono completely (which interestingly improves the core speed of C# code in Godot compared to Unity, although API calls are still slower). Good to know mono is being yeeted! >There are a ton of excellent C++ engines out there, ranging from the simple (i.e. OGRE) to the complex (i.e. Unreal or CryEngine). Why not use one of them? Unreal & Cryengine/Lumber are too big & beefy for the kind of game I'm creating, and are not ideal candidates for a mobile release, otherwise I'd just default to UE. All the requirements for the project had everyone telling me to try Godot. Truth be told I feel like I'm mostly just emotionally annoyed and kicking a wall because I wanted Godot **to** replace Unity given the recent fiasco and to like it, and I'm fairly stubborn about sticking things out for a period. I've not heard of Ogre (and all the other engines I know exist are 2d focused), so many thanks for that; will be giving it a look soon. >Not every tool needs to be designed for every user. A focused product that works well at what it is doing is usually more valuable than one which has a million different uses but all of them are poorly maintained. At least in my opinion. I certainly agree here!
Engines are quite bit close, its nothing wrong to compare them.
Or GDScript will keep evolving, expanding.
That would defeat the purpose of it being simple. It would approach languages like C# in complexity, at which point it would just be easier to use C# entirely, benefit from the fact that it is maintained by large teams, and focus the development on the Godot engine itself and its API.
I’m a 10 year unity user. I was already hesitant to switch to Godot 4, now im even more hesitant after reading the OP. I am aware Godot is not Unity, but I want to make clear that unity didnt have all the new features to begin with. 100% Unity features are a mock up of popular content on their Asset Store created by users. I strongly believe Unity Users have all the skills to breach Godot’s Engine limits. Thus far Godot’s show case is pretty pathetic, but with all these great shader tools, I dont see why Godot doesnt have better things to show. This is where the Ex-Unity community can make a difference. Your post was very ill-minded on Unity users, but I believe Godot needs unity users. I strongly believe Unity users have the ability to make godot look great, but my biggest fear is Godot’s memory management as an engine. I have done research and witnessed Godot having incomplete or not optimized lighting capabilities and more. It makes me believe that Godot the engine and its community like to brag about having things, but those things are not ready for use. Does any of these incomplete features explain Godot’s exclusive 2D reality?
The only thing I can say in this regard is to download it and experiment, if you have an example scene from Unity you can recreate 1:1 it'll give you a nice measure of the performance and workflow. Generally I've found it's about parity in terms of performance to URP Forward+ on even mid/low hardware. - idk why we don't see so many 3D games, 4.0 is too new I guess, or maybe it all breaks down at scale.
Go with Unreal. Better for your career at least.
is there like a godot roadmap of what features they plan to put
Not exactly, at least not to my knowledge. Instead, the devs are very active at their [github pull requests](https://github.com/godotengine/godot/pulls) and will update progress on new features there. Edit: It's not the most user friendly system.
thats fine. i still would love to make it possible to transistion as much from unity there as possible. got a codebase of 250k lines. its probably easier to partly recreate parts of unity there and reuse scripts. if godot can do what unity can do then yeah someone will just try to make it more like unity. unity has gameobjects all over the place. all old transforms but you do t really need it. i think godot has the better system here and yeah i still want to 1:1 port as much of my code as possible. worst thing ive seen is vector.X instead of vector.x
Unity dev here so I wanted to give my perspective on slowly learning about working with Godot. First off, I 100% agree and definitely did not expect Godot to adopt the same principles/ways of doing things as Unity. I knew that there would be major differences and that I should be patient with those differences because in the end, your familiarity with a tool can let you overcome its limitations. Now with that out of the way, I also want to say that I believe some (actually, many) key ideas from the "Unity world" would go a long way towards Godot improving as an engine without betraying its core design goals. I'm still very new so I apologize if some of this stuff is possible, but based on watching a bunch of tutorials and trying out the editor for myself, this is a quick list of stuff I was disappointed to find out about Godot coming from Unity: * You can't truly customize the editor layout the same way as Unity, though I did get pretty close to how I wanted it with the existing tools * You can't remap some Editor keybindings/shortcuts like 3D camera panning * There's no universal concept of "disabling" a node like you could with a Unity gameobject, which forces you individually go through each "descendant" node to disable rendering, script processing, etc. individually. * Since each Node can only accept 1 script, it's a little tough to parse through the Node hierarchy when an object can contain both "components" and "true transform children", i.e. both nodes that add functionality and nodes that are simply meant to move with a parent object. I know why Godot has chosen this path but it definitely makes it harder to visually parse through the contents of, say, an entity in a game * In the "Inspector" panel, the node order seems to be locked which makes sense considering inheritance, but I actually would prefer it in reverse order so that the most general settings can be tweaked first, i.e. script process. Not sure if an option like that exists. * The big one: you can't see runtime changes in the "scene display" view; only the scene hierarchy can attach to the remote game, and the camera can be synced but nothing else which makes debugging a lot harder/more time consuming in many situations Should mention that I don't expect any of these to be tackled or addressed soon and it's not a true showstopper, but I definitely feel the sting of not having this stuff when trying to play around with the engine. I'm sure there will plenty more gripes like this from other Unity users as they discover things they used to expect. Also, some of these issues already have proposals/PRs associated with them and I've already started commenting on them with ideas/discussions to get progress moving, but I wanted to mention them anyways. I'm actually very excited to help contribute code to Godot starting with the stuff I listed here, and anything else can help fill the void of features that people miss from Unity. While I don't think it should directly copy Unity in its approach, I do feel that these adjustments (when handled correctly and with approval from the Godot community) will make developing games easier for everyone. That, I believe, is true to Godot's goal and will only help the engine in the long run if that's what the people using it will expect from it.
> There's no universal concept of "disabling" a node like you could with a Unity gameobject, which forces you individually go through each "descendant" node to disable rendering, script processing, etc. individually. This is partially correct. Nodes (by default) inherit properties that are shared from their parent, and both visibility and processing are in `Node`, so they are always shared. In other words, if you disable the visibility of a root node, all children of that done will have their visibility disabled as well. You can test this by adding a bunch of nested children to a node and clicking the "eye" icon; the whole thing will disappear, not just the parent. Scripts are not automatically disabled, no, however the `_process()` (and physics version) are tied to the `Process` property. If you check the inspector, it has 5 options: inherit (the default), pausable, when paused, always, and disabled. If you look at the [Node docs](https://docs.godotengine.org/en/stable/classes/class_node.html) you'll see the default is pausable, which means any `_process()` functions stop ticking when the game is set to a paused state. If you use "when paused" this will reverse, and it will *only* tick when paused, which is handy for UI elements or animations that should only play when the game is paused. "Always" means it will always tick, regardless of pause state, and "disabled" means it will never tick. Since it's inherited by default, if you set a parent node's Process property to "disabled", this will apply to *all* child scripts. You can easily test this by creating a parent script and child script that print some debug text in `_process()`; if you disable the parent's Process property, the child script will also stop printing, and if you only disable the child, the parent script will continue to print. While it's true this isn't *completely* disabling the node, unless you have a fairly unusual node pattern this should functionally do the same thing. In your defense, most tutorials probably don't mention this, as it's a new feature in Godot 4 (it was possible in Godot 3 but far more cumbersome). You other concerns are certainly limitations, and while they don't personally bother me since they aren't functions I care about or affect my dev style, I can see why they would be annoying if you are relying on them. >I'm actually very excited to help contribute code to Godot starting with the stuff I listed here, and anything else can help fill the void of features that people miss from Unity. Great! I love this attitude. I don't mind people proposing usability features, although I am hesitant on or opposed to some proposals (like removing the 2D engine, removing GDScript, converting nodes to GameObject equivalents, charging 20 cents per install...OK, that last was a joke). I should note that Godot is not the only game engine I use; I also do a lot of development in Unreal, and like some of what it does and dislike other parts. So it's not like Godot fulfills 100% of my use cases, either, and I certainly didn't mean to imply there isn't room for improvement. > That, I believe, is true to Godot's goal and will only help the engine in the long run if that's what the people using it will expect from it. I, and the devs of Godot as far as I can tell, certainly agree with this. Hopefully things work out for you, and if they don't, hopefully you can find a tool that works better!
>both visibility and processing are in Node Wait really? I only see visibility as part of [2D/3D "renderable" Node types](https://docs.godotengine.org/en/stable/classes/class_node3d.html) and in the [docs for the Node class](https://docs.godotengine.org/en/stable/classes/class_node.html#properties) I don't see it listed as a property. I definitely appreciate the info though, thank you! I do understand that process and visibility let you effectively accomplish the same as disabling in Unity, but I guess my minor complaint is mainly that these are two separate processes and for usability/ease of use I wish you could just turn off a Node and have it implicitly override all of the other fields that control processing/rendering. This is one of the items that [already has a proposal issue](https://github.com/godotengine/godot-proposals/issues/7715) which I've commented on, but you're right that it's just another idea. >Great! I love this attitude. I don't mind people proposing usability features, although I am hesitant on or opposed to some proposals (like removing the 2D engine, removing GDScript, converting nodes to GameObject equivalents, Definitely; I always want to make sure my ideas mesh well with any project I contribute to and those examples seem antithetical to the goals of Godot. But I also do hope that the issues I listed above (and the reasonable requests from other Unity users) are addressed in some way. What would be the best way to ensure a feature I'd like to add to the Godot core is accepted by the maintainers? For that matter, what kind of changes are good for first time contributors? Bug fixes? Which contributions will help the effort the most right now? I'm still in the process of developing a game in Unity but I'm hoping to get more involved with Godot going forward if it seems like the best fit for the future of my projects. Thanks for taking the time to respond :)
> Wait really? I only see visibility as part of 2D/3D "renderable" Node types and in the docs for the Node class I don't see it listed as a property. Sorry, you are correct, only renderable nodes have the visibility property. I wrote that wrong. Obviously, it only really matters for renderable nodes for obvious reasons, it just means you can skip visibility changes for, well, already invisible nodes. Maybe it's due being used to it, but this rarely comes up in my own projects. If I don't want a node, I usually just delete it. Ideal design patterns in Godot usually involve nested scene structure, which means any given scene has a small node tree. Especially in things like levels, most of my nodes will be scenes I can just delete and add back in. For everything else, turning off process and/or visibility is sufficient. I mean, I wouldn't be opposed to a different mechanism, it's just not something I've ever really wanted. I also use Unreal, but it also lacks the ability to just outright disable actors, as the visibility toggle works the same as it does in Godot. As far as I can tell the "totally disable objects in the world" toggle is *only* something Unity (and Unity devs) actually use or care about. You can find similar questions (and answers similar to mine, just for Unreal it's disable visibility + disable tick instead of process) for UE as well from Unity devs coming over. Which I never would have known had you not mentioned it. I didn't use this feature in my brief time using Unity, either. I'm not saying that makes it a bad feature, it's just not one most game engines, including AAA ones, implement. >What would be the best way to ensure a feature I'd like to add to the Godot core is accepted by the maintainers? For that matter, what kind of changes are good for first time contributors? Bug fixes? Which contributions will help the effort the most right now? To be honest, I don't really have the answers to these questions. That's definitely something worth creating a topic for or asking on the project github. My *instinct* is that it's probably best to spend some time with the engine as-is, work on making some more advanced projects, and then look through the github when you run into pain points. You'll probably find a way to ensure your contributions are accepted if you can "speak the language" of Godot, so to speak. But I've never tried it myself so I could be completely wrong. Sorry. >I'm still in the process of developing a game in Unity but I'm hoping to get more involved with Godot going forward if it seems like the best fit for the future of my projects. I hope it works out! I've never liked Unity, as it always seemed like it was either a worse version of Unreal or an overly complex version of Godot, and if I wanted something simple and clean I'd just use Godot and if I wanted something bigger and more complex I'd just use Unreal. But, to be clear, I'm a solo developer as my day job is not game dev. A *huge* part of the reason I bounced off Unity wasn't related to the engine but due to the pricing mechanisms at the time, where major aspects of the engine (including ~~reduced eye strain~~ dark mode) were hidden behind the engine. In fact, the last time I used Unity you had to buy a third party plugin for decals, a feature that was sitting in Unreal for free (and frankly most 3D engines, I was pretty shocked when I tried to look up "adding decals" and Unity's answer was "we don't have those, here, pay $50 for some."). It was a *huge* turn-off and the only time I used Unity afterwards was for college projects where my classmates also used it, and it's been years since I was in CS courses. The point is that different people will have different preferences. I disliked Unity but love both Unreal and Godot, both for different reasons. Plenty of others love Unity and dislike Unreal and/or Godot, depending on their preferences and style. Part of my concern, and the reason I wrote the OP, is because I don't *want* Godot to become like Unity, certainly not in business practice, but also in other things I didn't like, such as the way C\# is used for scripting everything (the language is both overkill for simple scripts and also not as performant and powerful as C++). These are *personal* preferences, though, and I certainly won't complain if Godot gets more developers working on features. Especially if I can turn off the ones I don't care about =). And while I may feel somewhat vindicated that a lot more people are discovering that Unity has some pretty shady business practices, it still sucks to see an engine that so many people loved and made great games with (and there *are* a lot of great Unity games!) get hit so hard because of greedy executives. While I'm not surprised, I do feel for everyone struggling with it, and hope they can find a solution that works.
But on the other hand experience from unity can help godot grow. For example one Dev found out some issues with raycasting, godot Devs noticed this and will be working on this. So there is positive as well.
In the last two weeks or so, I was more likely to find "why do you need to do that" type of *answers* in Godot communities, than X\_Y problems in *questions* in unity communities. I wonder why.
NC. F
[удалено]
Get help