Making GDScript a Standalone Programming Language

General
21

Now, for example, what does a database management framework with the help of Orm have to do with Godo?

It has to do with Godot if the user is using GDScript, because if they’re using GDScript, they’re using Godot. If they weren’t using Godot, they’d use something other than GDScript.

For Gdscript, it should be something like this, or a library compatible with the Android theme, for the general UI, the example will be similar.

I don’t understand what this means.

I feel that you are taking the issue in a completely different way, just because you are against this idea, the existence of a package manager for each language.

I want to be clear that I’m not against this idea for some personal or religious reason; it just doesn’t make sense to me because GDScript’s whole purpose is to serve Godot and software development using Godot. If you like the way the language is written, you can use Python for non-Godot development, and the vast majority of it will be the same. If you are using Godot, then you can use GDScript or one of many GDExtension-supported languages to benefit from their collection of libraries. GDScript’s reason for existing is to provide a language that’s tailor-made to Godot’s structure and allows quick iteration on Godot programs.

Does the Godot team expect us to use Python for even the simplest books needed for game and software design or to build it from scratch?

You’re probably encouraged to use GDExtension in these cases. Nothing’s stopping you from creating a GDScript library, though.

It’s really weird to need an external API for anything.

It’s not. Python uses external APIs for interfacing with most things. That’s what Python (and other language) packages are: code that has been written which allows that language and its environment to access other services and APIs.

I doubt [Python] could be as good as Gdscript

What specifically in GDScript do you think is superior to Python? Are you sure those are things in GDScript itself, and not in Godot as a whole?

I still feel that Gdscript needs an independent system for development, I mean direct access to it.

Here you go. This is direct access to GDScript’s source code.

In bash and management, Gdscript libraries are really necessary

You’re free to develop them as you see necessary. Again, nothing should be stopping you, unless there is some specific aspect of the OS that GDScript can’t access - in which case, you may want to open a proposal for that level of access to be granted to GDScript/Godot.

22

GDscript was a mistake, it is a major negative for Godot and you want to expand its footprint. If it helps the development of the godot engine, all good.

But nobody in their right mind would use GDscript unless they have to.

3 Likes
23

That is actually what I am looking for. A language like GDScript (I fool around with Wren, see https://wren.io), standalone, to embed into C/C++ and in my case into Dart programs. As a proof of concept it would probably be funny, to integrate it via the bean scripting framework into the JVM. But I guess that would be a little bit overkill.

No idea if “stanalone” helps the GDEngine, but as a nice language, I would prefer it over JavaScript any time!

24

Personally, I have a few ideas. Although I haven’t used GDScript extensively, I assume it’s a relatively simple language, which gives it some educational value—especially in terms of learning how to script for games. Another idea I’m exploring is hot-reloading. I think having an independent interpreter that can be integrated into my own tools would be incredibly helpful for development.

1 Like
25

It is a full fledged oo language with Python like syntax but (optional?) static typing and some interesting concepts like signals. Basically a high level language with build in Observer Design Pattern. Or call it “call back queues”?

26

Can’t help but answer if someone asks for “my thoughts” about a topic I’m currently deeply involved in. :slight_smile:

My background is with Unity, not Godot, so pepper my thoughts with salt. In fact, I have an absolute disdain not for GDScript but for the fact that they thought it necessary to invent another “like X” tightly integrated language.

I read the article about why GDScript was created, and it totally gave me the “not invented here syndrome” vibes. Nobody expects “scripting” to be high-performance, cheese.

And as a matter of fact it wasn’t until last year (2024) that Godot Steam release count for the first time was higher than PyGame (±150 / 19%). Proving that Python is wholly suitable to make small games even without being able to reach for a high-level, high-performance language which Godot even provides two choices for.

I think that already sums up my thoughts: “please don’t” … we don’t need another special-purpose mutation like Luau floating about out in the open for nobody to pick up.

What I would encourage however, and this is what I’m currently researching, is a common baseline scripting language for all major game engines. Tightly integrated of course, with a common core, and extensions (comparable with OpenGL).

But NOT as a standalone programming language. In that regard I’m with meorge - GDScript would merely be a “random mutation” of Python. Given Python’s weight and popularity GDScript would have no fighting chance to survive and thrive out in the open.

It’s only thanks to the similarities with Python that many developers come to terms with using GDScript in the first place. This helps to attract users from the outside because they may already know Python but their main goal is not to learn GDScript, it’s just a tool. They want to make games, and they will enjoy the (safe and reliable) hot reload sweetness neither Unity nor Unreal provide.

Now .. here’s the opportunity: if you could somehow convince Unity or Unreal, preferably both, to integrate GDScript as their native scripting backend - that would be downright awesome!

Because I strongly believe that we need an equal scripting backend in all game engines. Visual Scripting is a fad. Blueprints are way more useful, but just “binary files” speaks loud and clear why teams have their issues with it, let alone coming up with a “visual code style”.

Problem is, neither Unity nor Unreal would want to use another engine’s “special brew” language.

So if you could think GDScript not as standalone, but as an embedded game engine scripting solution and if it would be developed and distributed as a Unity package / Unreal plugin (ie not a source-level integration, no company buy-in necessary) - that might just work!

I’d still prefer Lua as the common baseline though. :wink: