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:

27

This wouldn’t be too hard to make. Just have a Program class which adds functionality for out-of-Godot usage, with a virtual static func Main(args: Array[String]) -> void method. Like this:

extends Program # Abstract class which adds _main method, allows running of scripts

# Equivalent to C#: static void Main(string[] args)
# Or Java: public static void Main(String[] args)
static func _main(args: Array[String]) -> void: 
    print("Hello, World!")
    for i in args:
        print(i)
    # Etc, etc...
28

gdscript has many built in features that are absolute pain to do in other languages.
Abstracts, super(), option to enforce strict typing.

I’ve read here complaints that class_name is weird… but modules concept is somehow not weird to you? Think of class_name as module and its the same thing.

Lua support for oop is just garbage, most LSP implementations are half broken, or rely on annotations, the oop itself is just esoteric nightmare of metatable spaghetti (no wonder language servers choke on it).

GDScript as standalone main strength would be its simplicity and intuitiveness. I don’t guess how things work, they work as you expect in oop dynamic. The code is simple, straightforward, compare that to python with its 20 ways to do the same thing.

I unironically would rather use gdscript for os programs, some grep, io whatever. It’s nicer to write and read.

1 Like
29

It’s called GDExtension.

30

I cannot think of a single modern language that doesn’t support these very easily out of the box. :slight_smile:

1 Like
31

Zig - no oop
Odin - no classes/oop
Lua - fake oop through metatables that you have to setup yourself and pray it works with your toolchain
Nim - wonky oop, you need macros to make it work in an intuitive way
Python - oop out of the box, but things like abstract are implemented as a module on top of the language features, they are not first class abc — Abstract Base Classes — Python 3.14.2 documentation

These are few examples from the top of my head, did you not know of these or?

Wait forgot to add the smiley at the end
:slight_smile:

32

You’re specifically picking out languages that aren’t object oriented. What’s the point in this? You’re comparing tools that are made for different jobs.

Also you’re quite childish, that just adds to it.

33

Tools are not made for “different jobs”, you can write OOP in C, and model it in many of which i posted with hacky ways if you want there are libraries for that, languages are not defined by jobs but by what they can do. Those are modern languages that lack oop, or have a philosophy of “well we provided some basic stuff DIY if you want”.

Those are modern languages no? Rust and Go don’t have oop, modern languages too.

You condescendingly created this argument with your “i dont know any modern language that doesn’t support oop”, when i show you example of such languages you instantly deflect as if it wasn’t your intent and its actually me who is childish. Im not no, you just get the same treatment you give. You behave condescendingly for no reason, start unproductive argument based on a vague statement, and when i play to your tune but actually provide arguments you resort to insults.

What does it add to exactly?

34

GDScript is an OOP language. You made the argument that other languages (which most people would assume other OOP languages) don’t support OOP features that GDScript does, which is simply false. Every OOP language I know supports those features I mentioned.

There are different tools for different jobs, I’m not sure what point you’re trying to make with that.

Furthermore, I’m not sure what was condescending in what I said, I can’t really do much about how you interpret another users answer.

35

You made the argument that other languages (which most people would assume other OOP languages) don’t support OOP features that GDScript does, which is simply false.

Can you quote me on that?

36

Here you mentioned this. As I said, most people would likely assume that you’re talking about other OOP languages not supporting these things. Because why would a non-oop language support oop features?

37

I provided examples in that post - Lua and Python. Two most widely used interpreted languages, which would be closest to GDScript in terms of perception and use. I don’t know what most people would assume based on my post, with my opinion piece. You are the only one who read into to the point where your conclusion was that i claim there are no oop languages that support it. You start an argument based on that, and here we are wasting time.

38

It makes no sense to compare non-oop languages to oop languages based on their oop capabilities.

39

It makes no sense to compare non-oop languages to oop languages based on their oop capabilities.

You should have started with this. Then i would say - agree to disagree with your opinion.
There is a lot of sense in my opinion to compare languages not only based on the concepts/philosophy they move towards. Lots of things to consider - ecosystem, infrastructure, ease of use, platform support, licensing/ownership, devkit/sdk support on specific platforms, compatibility and so on.

Just because a language does support oop out of the box doesn’t mean that it’s the best choice, even if you need some oop features. If you can hack around it, the other factors can outweight the oop concerns. There are many factors involved in selection of the right language and environment, and many “suboptimal” choices are made all the time because one factor blocks the other.

For example i would gladly use GDScript for many system tasks instead of python because of its cleaner syntax. Despite the fact that python has massive ecosystem.