GDScript makes Redot dependent on the choices of the Godot project. #172
Comments
|
There is some truth in this. But for a while, the project must provide backward compatibility to attract developers. |
|
The later this is done, the later it is to change. After all, people will come if an engine is great, not because it is similar to what they want to leave. |
|
GDScript should be kept for as long as possible. Instead if needed an optional superset should be created that implements all the features not compatible with the current GDScript implementation over time. Making it easy for beginners to find learning resources and help online is a must for community growth. Godot did struggle a lot with that and renaming GDScript to something else would completely kill any resource/help someone unaware of the name change could get. And I figure its going to be a lot of people. |
|
Don't throw the baby out with the bathwater |
|
Try to think outside the scope of Godot, successful open-source projects are those that are good for everyone, not just for those who already have prior experience |
|
Think about people who already started a project and would think about moving it to Redot. I'll be honest guys. I'm ready to contribute in some form or another, but if there's no support for GDScript, there's no point for me to stay here. And I'm not the only one with an advanced project in GDScript. Don't forget this fork still has to prove itself and may die in a few weeks for what we know. |
|
I don’t think GDScript should be replaced before Redot makes its mark in the game engine circle. GDScript is a good language, and there are many GDScript tutorials on the market, which will allow everyone to learn Redot better. |
|
One of the main selling points of Godot is GDScript, Removing it would greatly disadvantage Redot's adoption and would be an idiotic move, that'd be done entirely for political reasons instead of functional reasons. |
|
This only my personal opinion but GDscript was/is a mistake from the very beginning that Godot made. I understand it's purpose and reasoning behind it but making your own programming language is a massive effort that resources that could be spend on other development. Not to mention that this language its dynamicly typed making is only viable for small/medium projects. You can already see madness hapening by Godot addding specialized types for better performance "Dictionary<int, ...>" simialr what JS is doing with Int32Array and stuff. This would/ could be avoided using static typed language. If anything Visual Scripting + any static typed language would make the most sense. If we would like to attract people and make engine stable and crash free then C# makes the most sense. Even Capcom in it's RE engine uses C++ only for engine and C# for gameplay. Additonally I would also express that Web export for C# is also equally important. Since a lot of Unity users could jump in and use Redot for GameJams and therefor adapt new engine in the future. Sorry to all GDscript users but this language should not be supoorted. I never used it and never will. It's too basic/slow for serious projecs. Again my personal opinion. |
The heck. I'm being genuine here. If all you're doing is just reskinning Godot, then that's all people will think of you: a reskin. There's no actual project here. That's why I believe the scripting language should branch. And, regardless of what you think of me, there's a genuine conversation going on here. If you keep this closed, it's just censorship of your community. |
However, GDScript is very attractive to some people who are starting to develop games from scratch, because its learning cost is lower than that of languages such as c# and c++. GDScript is also mainly built for those who are new to game development. Currently, GDScript is left to Redot to attract game developers. A plus point for noobs. But it is undeniable that GDScript also has many shortcomings, so we should first encourage everyone to use the GDScript+C# model or transition from GDScript to C# model to develop games. First use the two main languages GDScript and C#, and then depending on the development situation, we will see whether we should focus on C# or develop both together. In short, I still say the same thing: don’t give up GDScript until Redot makes its mark in the game engine world. |
Gdscript is even less noob friendly than Visual Scripting. Not to mention that each node could be backed by C# code which could be generated by C# generators and that would benefit from any optimization that are avialable for it. This is why I belive that Visual Scripting is a way better alternative for any new user. Plus having good Node Graph clasess would be used for any other features or systems like Behaviour Trees, Dialogs or custom solutions for any dev. Similar what Unity provides. |
|
GDScript is a super friendly language. I'm a senior dev and have been using it for years. It's frustrating only for its missing features, a problem that has been becoming less and less relevant with Godot 4. We should not actively remove features. If they die naturally due to a lack of interest, may it be. But let's not throw it willingly for personal opinions when it's used by a huge part of the community. |
|
Once you know one language, the others fall like dominos. They are all pretty much the same. Maybe it's because I am The Tech lead. Use whatever language you like it's all the same to me. |
|
Maybe this is an opportunity to introduce a better programming language in view of GDscript itself's poor features and community that cannot compete with mainstream languages. I think Redot should be natively compatible with GDscript and another mainstream language (such as Python which is similar to GDscript) |
I dont think redot should add python support. There is no need for another dynamic typed language. Like you said, gdscript is similar to python, so python users have no problem using that. Gdscript is at least "semi typesave" . |
|
I want to add my experience. I start to use godot since 3beta. now I'm still to 4.2.2 (why not 4.3 you ask? because my project is quite complex and I start to have crash. I star to use GDSCript to learn the game engine, then, because I was a beginner my code base result like a "spaghetti code". So I decided to choose the only other supported language , even is was not my preferred one:C#. After a while, maybe because I'm not so great in C#, I start to see my project running slow. After a while I find out the culprit: GC. In the meantime GDScript introduced the static typing as way to improve performance and to improve the code legibility. So I decided to set aside C# and convert my entire project into GDScrtipt again. The project star again to run fast as I expected. I agree GDScript lack tons of feature, so much that I use vscode. But I don't want to use C# for develop games. In my opinion any language that have GC is not the right one for game development. My project is a multiplayer game: client with authoritative server. I use database (sqlite) and so far I'm quite happy with GDScript. It lack some feature but I know Godot have plan to add some: export dictionary. I suggest before decide to throw away something to have a substitution already ready ta people like. What godot need is to be more clear for what it can do and in which way. a lot of things are not documented at all. So priority: fix bugs and update ALL the documentation. Then let people choose which language want to use for scripting. I do not suggest C++ because now (2024) we have much better alternatives ( I'm not referring to rust even if I like it a bit) but I was thinking to zig for example. For example. I use debian 11 as operating system. Not windows because I like my privacy the most. So my mindset is to optimize rather to "add latest new" in my things. I will use this fork if: there will be GDScript, the most important bugs will be fixed and the documentation will get some improvement. Otherwise Ill keep going wit the main stream. This is how I stand :) Have fun. I keep and eye open to this fork. |
Yes, thanks for the correction. According to the current overall situation, how to maintain and develop the engine's own functions through existing resources is the first issue that needs to be considered. Multi-language support maybe needed after the community is stabilized. |
|
Gdscript has always been a module in godot. As such it could simply be an optional feature |
|
GDScript is a woke language that lets variables change types at runtime. Redot should only allow languages with static typing to prevent users of the engine from encountering trans-type variables. |
|
I like GDScript being kept as it is a useful tool to attract new developers, like myself. It was a big reason I started using Godot, and kept using it. I'd be inclined to keep it, as it makes Redot accessible, and that is key to building support. I'd keep it until you can implement something else that is equally accessible or build tutorials for the alternative methods for Redot that are easily accessible. |
Just make it optional, if it isn't optional already. Whoever doesn't need it will turn it off, if no one needs it, it will die. Same applies to visual scripting. People do not stay "noobs" forever, so the engine shouldn't only target "noobs". |
|
I'm speaking as someone who's working on a potato laptop:
TL;DR
|
|
I believe that GDScript won't go away in the project but regardless I'll give my opinion. As @git2013vb said with the introduction of optional static typing and other features the language improved dramatically. Regardless of the discourse around it from developers I believe that if we had actual data we might be surprised on how many new developers it brought to the engine that maybe would've left if the main language was C# or something else. As a developer interested in low level coding I understand the point of view of the experienced devs, but we can't disregard the possibility of it actually being a big contributor to the success of the engine in terms of popularity. Yes, the language can be improved, and it probably will, but I believe it's an integral part of the engine. And probably should be. From my own experience, the language does its job. Most importantly, the language is a really good fit for the chaotic nature of game prototyping and game development and depending on the project it can be the only language, the main language (with parts that need optimization or missing language features done in C#/GDExtension/C++ Module/Other bindings) or just being glue code. You can also completely ignore it and use whatever you want, so... That's it. |
|
It's not in the cards to remove gdscript at the moment. However, we should divert all resources away from it. Upstream will maintain it. Godot has a terrible reputation for being a toy engine; you can easily start, but it's impossible to finish, because the entire experience is catered to beginners learning to code, while real developers languish and can't ship their game. Both engines need to pivot from this, but Redot can differentiate by doing it first. This engine could become a serious contender against Unity, but it needs to want to become that. That would entail ignoring everything to do with gdscript, the internal editor, GDphysics, and all the proprietary nonsense that will never be used by serious developers. There is a limited dev budget; it must be spent wisely. What do the game devs need?
If Redot focuses on any one of these pain points, it would immediately become the preferred branch for people who know what they're doing. Newbies will learn whatever they need to learn. A giant userbase, 98% of whom are doing tutorials, isn't what we should strive for. A smaller userbase that actually puts games on Steam and proves that this engine is a real tool is what we (and Godot) need. |
I agree that GDScript should be maintained by upstream. However, I heavily disagree on the C# front. If we're going to start talking about superiority then we're kinda derailing from the topic, BUT if we're going to, then any programming language with Garbage Collection should be automatically disqualified for being the a first class citizen. C# has a Garbage Collector. Then we should be talking about:
|
You can force static typing inside GDScripting by how you declare objects and function paramaters. Unlike hints in Python GDscript does force the type in the object and the code becomes faster. |
//Opinion It is a non-standard language that exists only in godot. Meaning your GDscript skills won't give yesterday's "noob" a job. That doesn't cater to non-beginner. Similar problem happens with visual scripting systems. They are non-standard and only exist in corresponding engines. Standard scripting language solutions are lua, javascript, python. Several games use C# for scripting, but this is more of a hack, as the language is quite verbose, and, for example, function cannot exist at top level. Type system is a huge plus, but then there's lacking control over deallocation which becomes a pain point in unity. I've also seen Ruby being used for scripts in rpgmaker. Ideal solution would be to use a language that is fairly standard and used elsewhere, but doesn't lock you into a specific platform. So skills used in the engine would remain useful outside of it. Could be a dialect. Something from TIOBE top 20, perhaps? Anyway, just some thoughts. |
As Mentioned before nowadays we have some languages that are fast (compiling/running/footprint) as C++ if not better, and they help developer in memory management. I ruled out C++ and similar for this simple reason. Not because is not well known. I used C++ too in '80.. But today using it again for any reasons will be a "crime" :). We are not forced to live in the past :). Learn something new - time allowed - don't ruin everyone brain. On the contrary. |
It's absolutely not impossible to finish serious games with just GDScript, and have them perform well.. There are plenty of successful games made with Godot that just use GDScript.
|
|
Use D-lang and lua |
Yeah I included it mostly for the sake of completeness and because its the language of the engine. But I'd prefer one of the others. |
Personally I think if we are not going with c/c++ then zig is the better choice. It plays really well with c/c++ . |
|
First - GDScript must stay while it's in Godot. Event if politic behind Godot is retarded I believe Redot must be bare minimum fully compatible with Godot and as bonus have it's own features on top. Breaking things is easy and there is zero point of making something different just for sake of it Second - I must admin that C# as my main lovely strongly typed language seems harder to work when you writing little script here and there. Scripting languages are there not for nothing and as engine script language it has integrations with engine and improving it So to sum Redot must be Godot+ in terms of capabilities and fully compatible, passing all the tests. Ideally every commit from Godot repo should be here as well. But regarding of scripting language I dont know, I'm definitely okay with GDScript and dont even see a problend of it's name staying same, saying that Redot depending on GDScipt for godot choices, but this whole project is a fork. At least until project is mature enough issued suggestion is destructive |
|
I for one would fully support just renaming the language for now and leaving the implementation alone. Say rename it to rdscript and allow it to load and parse both .gd and .rd files so it stays backwards compatible yet allows the ability to branch off in the future. Nothing changes in terms of what the user sees and expects. Tutorials remain valid and to the users it's like nothings even happened. only thing would be new projects use the .rd extension instead of .gd but I can't see it being too much of a hindrance unless just changing a file extension makes people scared like it's a completely new language |
|
There are far more better choices than GDscript. Especially that there are insustry languages that users then can transfer knowledge to. Lua or even JavaScript are far more better. Adding optional types to GDscript is a bad idea because if you need performance you should pick C# or even C++ if you need maxium bare metal. Using and then exposing well known language like Lua or JavaScript could add modding support to the engine for free. No to mention that JavaScript runs for free on web and Lua has an excellent JIT compiler. But all and all scripting language should be just that, a scripting language. No optional types, no typed alternatives, nothing too complex. When user becomes more proficient, then it should reach for more better equipted languages. |
|
I agree with you in that and lua or js was my first thoughts as well, but i actually somekind agree with creating own language which is tightly integrated with engine, I think it's just not there yet, gdscript pretty easy and I don't see problem aside from performance that can be improved with time |
Renaming would only confuse everyone unless there are enough difference and when it's existence questionable to begin with best way is just dont touch it and merge commits, let godot team do heavy lifting it doest harm if you don't want to use it - don't |
Yeah, and for those new people the vast amount of GDScript tutorials already written would be greatly helpful, don't you think? If we change the language, we'd have to build brand new base of tutorials and documentation, which is a lot of work that might not pay off. Instead we should leverage what's already there so that we can EEE Godot properly. |
|
I think its important to keep in mind that though people in charge of godot are toxic i don't remember anything like LGBT code, you definitely can come up with something, but when its a big and complex system like game engine there are rules and standards so in the end if bug fixed or feature released it should be accepted (that is if related to engine) |
i would love to use zig for game dev i used to be a unity game dev working with several small indie companies but i have been doing back end with Go for a while now and ever since i started using go and got used to the simplicity it's really hard to deal with all the C# and dotnet feature creep , zig in my opinion hits that exact sweat spot despite being fast and manually managed it feels fluid and the syntax is intuitive (love the generic and comptime implementations) even more so than Go and since zig is relatively new just like Rodot is , i think if it is chosen the two projects can benefit and influence each other a lot |
It seems like you're far too removed of reality, there are a ton of people that come JUST to make games, and GDScript is well suited for them. They probably aren't going to make games that need more optimization than what GDScript can provide for them.
You can already extend the engine with addons/plugins, C++ modules and GDExtensions!
GDScript type system makes a lot of sense in the world of game prototyping and early/mid development. I understand not liking dynamic typing, I don't like it much too. If you want to make everything in GDScript, you can. Godot gives you this flexibility, don't try to come and approach the community from a sense of technical superiority because I believe we're not down for that here. Edit: |
|
I agree we should keep GDScript the way it is and let Godot maintain it. It's a valuable tool that will greatly hinder the engine if it's changed, especially noobs coming over from Godot. If they try to do a thing in the engine and they can't with GDScript in Redot, they'll just go back to Godot to do the thing, not learn another way to do it specifically for us. I also agree that C# needs a lot of love. I'm down for the idea of Redot targeting C# and improving that aspect of the engine. It'll help people coming from Unity for easier transitions, and with C# being a more "standard" language, it'll make Redot itself seem more mature. GDScript has flaws, we all know that, but we can't just chuck it because fuck Godot. If we find better ways to do things with GDScript, we should push those changes upstream so all of the Godot communities can use it, and just keep our C# improvements to ourselves for the time being. I wouldn't mind having Redot become C# first and GDScript second |
|
just so you know where I'm coming from: I think inventing languages is a terrible idea, and gdscript is an extremely amateur example of that and was a terrible mistake. However, removing it now would be project suicide - would alienate the vast majority of the godot community that could potentially move over to redot, I'm strongly in favor of keeping it as is. Personally I'd just focus our efforts in other areas and just let gdscript improvements be driven by the godot project - but keep the language for the foreseeable future. |
|
The wealth of pre-existing GDScript tutorials coupled with the user friendly attractiveness of Godot/Redot to new game development people makes it imperative that GDScript is kept in Redot. I can't back up what I'm going to say with hard data but I am sure that the majority of game developers using Godot are hobbyists (like myself) who will probably never finish and release an AA or AAA commercial game (like I won't) and this is the majority of the Godot users. I'm not insulting anyone: I am literally describing myself. I understand that there are game developers using Godot/Redot who are capable of such game development, and Redot should facilitate their skills and ambitions, but not to the detriment of the bulk of the "market" which I believe is proud hobbyists. As it stands (and someone else mentioned above) using GDScript is optional if developers want to use a different language for whatever reason, so I don't see the problem. Renaming GDScript isn't necessary either. |
|
As we plan on maintaining compatibility as long as possible GDScript will remain an integral part of the engine. There are no plans to do any form of renaming of GDScript or the addition of new languages into the engine itself at this time |
and others
Tested versions
all
System information
n/a
Issue description
Redot still uses GDScript, which is maintained by the Godot Foundation. Any modifications to the standard is going to be reflected in documentation and tutorials about GDScript. Redot needs to at least fork the scripting language too.
Steps to reproduce
n/a
Minimal reproduction project (MRP)
n/a
The text was updated successfully, but these errors were encountered: