This, so much this that you’re basically paraphrasing the Godot original authors’ intent.
Cheers !
3 Likes
Super interesting, you just outlined what I did too. I’m using C# now, I had a look at GDScript initially but I think I will keep using C# because there’s plenty other things to learn and I want to stay in Rider. I wonder if I’ll end up there too though, I don’t feel like C# would slow me down? But I haven’t used Python before.
Coming from C# you’re happy with GDScript? Did you work with Python a lot before to help make you more comfortable? Curious about this because I only know C# and anything else is super weird atm.
Well, rider supports GDScript, so that’s not a reason to use C#.
GDScript is like Python in the way that C# is like Java. They were initially patterned after one another, but have long since diverged, and mainly only contain some syntactic similarities.
If you really love C# and have years of experience in it, it may be totally worth using it. @tibaverus is an example of someone who enjoys and excels at using Godot with C#.
I’ve used C# professionally for years. I’ve also used Java, Python, Ruby, C, C++ (and more) professionally over the last three decades. I love GDScript and encourage everyone to use it. Most of the reasons for using it in Godot 3.x are no longer valid in Godot 4.x. C# will not make your game code process faster anymore. The main feature that C# has is multiple-inheritance, and that can be worked around using composition instead of inheritance - and works better with Godot’s node system.
I have made a game in C# using Godot. It was fine, and definitely better than Unity and Unreal. But I had already used GDScript, and it was so frustrating in comparison that once I was done with he game, I never looked back. My two biggest complaints were how long it takes to load the editor, and how long it takes to compile when you want to test your project. It was like going from Agile development back to the Waterfall days to me.
If you haven’t yet, I recommend you take an hour to do the Your first 2D game — Godot Engine (stable) documentation in English in GDScript and get to know the language. I’m willing to bet that it will not be as daunting by the time you’re done.
I can also tell you from experience that learning GDScript will be less of a learning curve than learning how to use Godot in C#. There are a lot of caveats and gotchas that will get you in C# later down the road. For example, you cannot make web exports with C#. This will hopefully change in 4.7, but we were hoping to see it in 4.6 as well.
Also, if you’re going to use C#, it is much more of a lone wolf path. we will certainly help you out with it, but most of us are much better versed in helping with GDScript. I, for example, will often will pull full code examples from past projects or just code up new things for people in replies here. It’s just too much work for me to remember C# syntax, and the amount of time it takes just to open the C# (Mono) version of the editor means I don’t do it anymore to help people. Again, we’ll do what we can - and if you’re self-sufficient in C# it’s not such a big issue. But you should keep that in mind.
5 Likes
I did use a lot of Python before but that is weird as all I see are the differences.
Learning your second language is hard. I can recommend choosing a second language that is very different from your first one.
I have an unfair advantage when I discovered GDScript. It’s like my 6th Language I actually have written more than 1000 lines and I have programming experience of over 2 decades.
1 Like
The speed, the lightness. I came to Godot from Unity. Even not being an expert, Unity felt very bloated to me. Clunky installer, slooooooow editor, difficulty finding things among the mass of options. Then I tried Godot: download a single binary, run it, jump into the editor. It was a true breath of fresh air.
3 Likes
With the glTF vertex regression, I do have to rescind the stability point, actually.
That one just loaded me up with so much freaking rework that I now have to decide if I want to redo all my glTF models or all my post 4.6 changes…
Ah, but here we have an excellent example of something that Unity and Unreal do not. You can post a bug and the Godot team will address it. If a minor version change broke backwards compatibility, they will fix that. 4.5 → 4.6 is a minor version. And they just released the first dev version of 4.7. Plus they are working on patch version 4.6.1. So, if you were to report this bug now, you could see a bug fix quite quickly.
2 Likes
1 year and counting, apparently.
It’s a volunteer project, so if I was desperate I could just fix it myself.
But I definitely have to rescind my point, since if I’d done my UE style full regression testing, I’d have saved myself a ton of work redoing the models and animations for 4.6
I see that. I also see it has a completed PR ready for 4.7 and just needs another approval.
So I’d still recommend you log the bug as a breaking change. Then they can close it when they implement the fix, but it might get a second person to approve it because Calinou has already approved it.
2 Likes
Going against the grain...
First of all, it would be good if script names were created based on some pre-established guide. I'm quite particular about that and I have to constantly change names.
Another thing that bothers me is the issue of references between nodes/scenes. That is, the lack of adaptability to changes in the names and hierarchical structure of the nodes/scenes. In Godot, everything is nodes/scenes and everything is hierarchical. Great. But when you start, you usually don't choose the correct hierarchy or the correct names. You try, you change, you reorganize, you change again, you rethink everything. And after that, you see the disaster. It's your fault. You realize that the references stop working. I understand that's how the engine works, but it would be very helpful if the editor had some kind of mechanism to warn you that a reference no longer exists, or better yet, to suggest one based on a unique identifier or something similar. I know this is more of a user issue than an engine problem, but every little bit helps for beginners.
Does anyone miss these other "small" features?
As someone said: You can only criticize and improve what you use.
@migueldeblas your post is really hard to read.
2 Likes
They are snake_case versions of the node name you for which you are creating the script. So just change that before you attach a script. Problem solved.
Huh? I really couldn’t parse the actual issue you’re having. Everything, including Scenes have UIDs as of 4.6. And everything is referenced by them. You can cut and paste nodes. In fact I do it all the time. So I’m not getting the issue. Perhaps describing a particular instance would help.
1 Like
My favorite thing is the servers, like RenderingServer, RenderingDevice, PhysicsServer. If I need to do something that isn’t supported by the normal node types or that would be too slow using nodes, then I can often fall back to these.
This access makes a lot of things possible using regular gdscript/C# code that would otherwise require modifying the engine. Terrain is a good example.
I think he is talking about “refactoring”.
The idea that moving/renaming an item doesn’t change hard coded paths to them.
This can be problematic but is relatively minor an issue (imo).
UID’s definitely change the game but there still exists the ability to get a lost node path.
If @megueldblas reads this then see this proposal.
I have seen refactoring work splendidly on a Java IDE (I can’t remember which) and I have also recently seen it work less than spectacularly.
VSCode seems to do this well, but I haven’t tried a big project with interconnected imports/files yet.
I decided to see if I could switch engines because I was getting fed up of project corruption with UE, namely:
All my Material Function nodes corrupting in all my Materials.
All my Material Instances losing their Parents.
The high chance of crashes when connecting up pins to Material Functions (which could result in the above) or crashing when setting the Material Parents back again to their instances.
It reached the point where I was saving after every 2 or so changes in the hope of avoiding the above, you could load a project, connect the next Material Function nodes pin and instantly crash, and it would do it every time. However if you connected a different pin, then went back to the crashing pin, it usually worked okay, but project load times aren’t exactly quick so you were losing alot of time on reloading.
I should say this was on 5.3, so maybe these bugs have been sorted.
Also, Godot is so stable, I’ve had it crash twice, one time was my own doing as I’d accidentally made an infinite loop in code (I’d much prefer GDScript not to be an indented language) and the other time I have no idea why it crashed, but two times in weeks as opposed to potentially two times in seconds is nicer.
1 Like
I already wrote my favourite thing, but every time I get back to Unity and want to create a new file from a ScriptableObject I miss the way Godot handles this.
In Godot you can create new Resources directly in the inspector field of their exported properties.
3 Likes
Hello,
I’m new to game development, started in September with Unity for a self paced computer science class offered at my school.
Unity classroom license requests, platform switching from Windows to Linux, and justt Unity itself are causing too many problems. So I’m going to start my next 2D project in Godot so I can judge which game engine I like better.
After my first day I’ve noticed a few key things. Godot runs a lot better on the Linux system, projects load faster, and more UI customization, and switching scenes on press of a button is slightly easier.
8 Likes
I'm referring to this type of assignment:
@var collision = $Area2D/CollisionShape2D
If I change the node hierarchy or rename a node, it doesn't just refactor itself as it does in most IDEs; it doesn't show any errors or warnings. It only fails when the scene is run.
When a project has few scripts and few references between scenes/nodes, there's no problem. But when there are a large number of scripts and multiple, scattered references, resolving a name change or hierarchy reordering can be very tedious. I'm used to IDEs that allow intelligent changes to object and variable names and more complex refactoring.
1 Like
Yes. That's what I mean.