Honestly, the language changes are pretty minor between 3 and 4, but the api has been completely rewritten. The information in the documentation about conversion is embarrassingly shallow. Then again, I think it would be easier to list the things that haven't changed.

My favorite project is a morass of hundreds of errors after the basic conversion. It would probably be easier to start from scratch on another platform than get it working. It would require about the same amount of relearning.

Of course there's no reason anyone has to move to 4, if you don't mind being left behind.

Well every framework or engine changes their API. Try running an Unreal 3 project in Unreal 4 and see what happens.

Also, the main bottleneck when developing games is you not the computer. In GDScript I am at least twice as fast (or probably much more) than if I did it in C# or C++.

Yes, C++ runs faster, but a game that is never finished doesn't run at all.

    My only complaint with GDScript is lack of multiple inheritance.

    Otherwise; you're making a videogame, who cares if its the perfect langauge, platform support and community is far more important. I would prefer Lua tho, but even that has its flaws (arrays startingat 1)

    After I saw the mess the conversion made, I decided to start an entirely different project. It reminded me of Unity, except with Unity, it was like that about every month or so when they did an update.

    Yeah, the auto-updater doesn't work. Every Godot 3 project I've opened in Godot 4 became horribly corrupted. But if you start fresh it mostly works.

    9 months later

    It’s all about the idioms.

    🙄Ok… the title sounded good in my head anyway.

    I keep hearing how GDScript is almost like Python… then I learn GDScript has no exceptions. Exceptions aren’t bad or good; the thing is, Python is idiomatically very RAII-centric. RAII USUALLY requires something rather exception-like. So, most Python idioms don’t necessarily work. I could allocate then initialize, internally… or I can use a factory externally and get much the same effect, but how do I do this in a way that’s obvious to other GDScript developers? Godot isn’t big enough to have GDScript idioms well documented in the wild outside Godot forums, so they really need to be driven home hard in the docs that DO exist. I see some evidence that returning a dictionary to convey an error may be a “popular” convention, but I’m unsure if this is real, or something ChatGPT is hallucinating? This unfortunately seems a bit more dangerous in a dynamically typed language. Nothing wrong with dynamic typing, but strong types, even if they are optional, can offer some nice guardrails, like knowing I’m looking at an error status rather than a value. I understand that dictionaries provide nice clear string names for things, but they are at least an order of magnitude slower than an array with enum indices ERROR_IDX, VALUE_IDX, or even a purpose-built ValueOrError class. All these are possible to do in almost any language, but any semblance of a standard return an error or value idiom in GDScript seems muddy at best.

    I happen to like exceptions in this context as they are much less ambiguous. I don’t mind Go’s error value type, but without type inference, this is an accident waiting to happen. I like templates or other generics as they enable a more expressive type system, but GDScript’s doesn’t seem well developed enough for templates to bring anything to the table.

    GDScript seems like a perfectly reasonable and capable little language, even if it lacks a few creature comforts… but it seems to be missing the boat a bit in well-established and documented standard conventions. Please point me at some more rigorous documentation?

    Thanks,

    -Loren

    IceBergyn Its easier to find and convert code from internet, on C# itself, java, c++, c, rust, etc.

    No, it's not. Not really. C, Java, C++, C# and Rust may all look very similar, but they are profoundly different languages when it comes to some of their core concepts. "Converting" code from one to the other is not easier or harder than converting it to GDScript, unless you just copy the source code , which may syntactically work fine, but can get you into massive troubles like memory leaks or performance bottlenecks later, which are notoriously hard to find and fix.

    I'm a professional C++ developer and have used C++ (native and in the managed C++/CLI variety) for almost 20 years. And for Godot I still prefer doing scripts in GDScript (strictly typed) over C#, because I find it easier to switch to something completely different than to the syntactically similar but internally still very different C# (and I did not want to bother with installing .NET on my Linux machine) . If I need maximum performance, I'll use C++ via GDExtensions, but to be honest, so far I haven't written a game where that was even necessary. Performance issues tend to come from badly written code more than from the language used.

    I'm currently converting an old game which I wrote completely in C++ without any engine support (just using the SDL for sound and graphics) to a Godot project, "translating" most of the C++ code into GDScript for the game logic and it works like a charm. Even things like bitshifts, bitwise & etc.

    2 months later

    Stop being C# andy. I hate python because of the indented formatting, and gdscript explicitly inherited this garbage. But still its better than python.

    Im no codeChad, but back in the day the gold standard of game dev was C, assembly -> RCT. You could run that baby smoothly on your lame old ass fathers bootlegged binbows95 machines.

    I like gdscript because it doesnt require them curly brackets or any other fluff that just wastes keystrokes. And it dont complain if you mess up types, it will still compile and wont throw errors, even tho something is not working as it should

      a month later

      kuligs2

      kuligs2 gdscript explicitly inherited this garbage. But still its better than python.

      In the latest version of Godot, you can use spaces or indents. However, it must be consistent throughout the script so you cannot just switch to a indent or vise-versa in the middle of the script.

      duane

      duane Personally, I prefer lua, but a lot of people hate it.

      Lua is awesome and idk why people hate it

      IceBergyn 1) Its easier to find and convert code from internet, on C# itself, java, c++, c, rust, etc.

      i feel like this has to do with the fact that GDscript is still a very new coding language, not to mention that it's not a general purpose coding language, so yeah there's gonna be less learning resources

      IceBergyn 4) Performance: You may not beleave, but gdscript is very very slow, the reason your game even works is because godot is fast, not your scripts, C# itself is slow and its 4x times faster then gdscript, the fast way would be c++ that can get more then 10x times faster then gdscript, that itself made me giveup on it.

      i personally never felt like it was being slow for my projects, but i understand if you felt like it was slow, especially if you've been coding in a faster language, I myself am a GDscript fanboy simply because the syntax is so easy to grasp hehe

      IceBergyn 5) That changes in functions names, class names every new version make code hard to mantain and update.

      Okay this i kinda agree with actually, porting your projects from Godot 3 to Godot 4 is it's own challenge, there was a function named yield() in Godot 3 but they changed it to await() in Godot 4, and for some reason the kinematicbody2D is now Characterbody2D, these changes may seem simple but they're more confusing for people less experienced in the GDscript

      IceBergyn I am sure there are more reasons, but I already giveup on this so for me it dosent matters, if you find more reasons just add a comment.

      It's completely if you dislike GDscript, it's all subjective after all, you should code in the language that YOU yourself vibe with better

      IceBergyn To be honest, there is only one reason to keep using gdscript: laziness to setup an c# and convert your scripts.

      I'm still using GDscript because Godot has been easy to learn and has everything i need for my own projects, I really have no reason to switch to C#, but It's cool if you wanna do that

        buzzbuzz20xx the more i work with godot and gdscript, the more im starting to think - i could make a desktop app with this. You got all the UI components, you got all the input events.. I havent played with godot accessing files on pc directly but i think its all you need to create desktop apps with it.

        Last desktop app i wrote was in .NET using no t the winforms but the next thing i forgot whats its called, its not UWP, something xml.. it was a pain.. In godot its easy peasy

        • Toxe replied to this.
          2 months later

          kuligs2 the more i work with godot and gdscript, the more im starting to think - i could make a desktop app with this

          Yes, you totally can. https://godotengine.org/showcase/pixelorama/

          In fact Godot has a really nice UI system and I have at least three or four different GUI desktop programs in mind that I'd like to do with Godot.

            Toxe not against godot but about the product you linked

            kuligs2 That is a huge and heavy tablet. But I don't understand what you dislike about Pixelorama. I think it looks pretty cool. Kinda looks like libresprite in dark mode.

            IceBergyn 4) Performance: You may not beleave, but gdscript is very very slow, the reason your game even works is because godot is fast, not your scripts, C# itself is slow and its 4x times faster then gdscript, the fast way would be c++ that can get more then 10x times faster then gdscript, that itself made me giveup on it.

            Just if you're still around, where are the numbers ? What is/was the code you used ?

            For the record, dynamic data structure are a catastrophe and should be avoid as much as possible, especially for huge number of items and in loop. It's convenient for a few dozens but not very much more.

            While I was playing with OpenGL tutorial by Nehe, porting C code to Perl (pretty similar to GDScript and also interpreted), the stars samples was terribly slow using such data structure (100 times slower), switching to pre-allocated array like in C, approx. same FPS value (1-5 difference top) ! It was in 2004-205 using integrated Intel GPU card of an Acer 5310. Many code samples ran at a similar speed, noting it was not for benchmarking purpose.