Making GDScript a Standalone Programming Language

[Pakrohk]

Introduction

I’ve been thinking about GDScript’s potential beyond Godot Engine, and I believe making it a standalone programming language could significantly benefit both the language and the engine ecosystem. I’d like to explore this idea with the community and hear your thoughts.

Current Situation

Right now, GDScript is tightly coupled with Godot Engine. While this integration provides excellent engine-specific features, it also:

• Limits the language’s growth potential
• Restricts the development community to Godot users
• Keeps learning resources primarily focused on game development
• Ties performance improvements to engine updates

Benefits of Making GDScript Standalone

For the Language:

1. Broader Development Community

   • More developers could contribute to language improvements
   • Performance optimizations could happen independently
   • Better tooling could be developed by the community

2. Expanded Use Cases

   • Could be used for general-purpose scripting
   • Potential use in other game engines or tools
   • Educational purposes (Python-like syntax with static typing)

3. More Learning Resources

   • Language tutorials separate from game development
   • More documentation and examples
   • Third-party books and courses

4. Independent Package Management System

   • A dedicated package manager similar to pip or cargo
   • Easy installation and management of third-party libraries
   • Central repository for GDScript packages
   • Standardized project structure and dependency management
   • Version control and conflict resolution for dependencies
   • Virtual environment management
   • Simplified code sharing between projects

For Godot:

1. Ecosystem Growth

   • More developers familiar with the language
   • Increased adoption of Godot due to GDScript expertise
   • More tools and libraries compatible with GDScript

2. Performance Benefits

   • Independent optimization efforts
   • Faster iteration on language features
   • Community-driven performance improvements

3. Better Language Evolution

   • Separate release cycle for language updates
   • More focused development of language features
   • Community feedback from diverse use cases

Technical Considerations

• Need to separate engine-specific APIs
• Maintaining compatibility with Godot
• Creating a standalone runtime
• Developing independent build tools

Questions for Discussion

1. What challenges do you see in making GDScript standalone?
2. How could we maintain the excellent Godot integration while supporting standalone use?
3. What features would you want to see in a standalone GDScript?
4. How could we structure the project to benefit both Godot and standalone users?

Possible Next Steps

1. Create a detailed technical proposal
2. Start a working group to explore feasibility
3. Begin prototyping basic standalone functionality
4. Develop a roadmap for separation

I believe this could be a win-win situation for both Godot and GDScript. What are your thoughts?

[Pakrohk]

understand your concerns about creating “yet another programming language”. Let me clarify some points about why making GDScript standalone could be beneficial, specifically for game development and 3D tools:

Technical Benefits of Standalone GDScript:

1. Better Plugin Development

   • Direct system API access without engine dependencies
   • Easier integration with external libraries
   • More flexible plugin architecture
   • Better developer tools and IDE support

2. Platform-Specific Optimizations

   • Custom platform export configurations
   • Native API bindings without engine overhead
   • Platform-specific features and optimizations
   • Better integration with platform-specific build systems

3. Specialized Game Development Features

   • Not competing with general-purpose languages
   • Focus on game-specific patterns and optimizations
   • Better GLSL integration and shader development
   • Hot-reloading without full engine recompilation

4. Community Development Model

   • Separate language improvements from engine updates
   • Faster iteration on game-specific features
   • Community can contribute without deep engine knowledge
   • More focused testing and optimization

Why It’s Different from General-Purpose Languages:

1. Game Development Focus

   • Built-in support for game math and physics types
   • Optimized for real-time performance
   • Better memory management for game objects
   • First-class support for game-specific patterns

2. 3D Tools Integration

   • Native support for 3D math operations
   • Better integration with graphics pipelines
   • Optimized for real-time 3D manipulation
   • Simplified shader development workflow

3. Development Workflow

   • Fast iteration without full compilation
   • Better hot-reload capabilities
   • Integrated profiling for game performance
   • Direct debugging of game logic

The goal isn’t to replace Python or JavaScript, but to create a better tool for game development and 3D applications. Standing alone would allow GDScript to evolve faster in this specific domain while maintaining its excellent Godot integration.

[duckbanditdan]

It’s an interesting idea. There are clear benefits as you outlined but also potential pitfalls.

Firstly, after all the work required to do this it might not be competitive.
GDScript Standalone would be competing with other standalone scripting languages for games, such as PyGame and various JavaScript/TypeScript libraries. I think it’s worth considering what GDScript can offer that others don’t. I wouldn’t be using GDScript myself if it wasn’t for the rapid iteration time it offers while working in Godot. It’s wonderful for this use case, but the static type support just isn’t strong enough right now for it to stand on its own for me personally. This isn’t important to everyone though, some prefer dynamic typing.

More importantly, Godot would lose control of the language. Right now, GDScript is built especially for Godot, and all features and changes are made with Godot in mind. The Godot IDE always keeps up with language changes because they are essentially tightly coupled. I don’t know if this would be a problem or not, but it could be of concern.

I think overall it would probably be beneficial, but I’m still a newcomer so I’d be interested to see what the long timers think. Beyond my thoughts above, I’ve barely explored the source and have no idea how much work would be involved.

[Pakrohk]

Just like you, I am waiting to see feedback from more experienced people in the Godot community.

[meorge]

The “technical benefits of standalone GDScript” you described sound to me like they’re all dependent to various extents on GDScript’s integration with the Godot, not things that would truly be independent.

If you removed Godot and Godot-specific features from GDScript, what you’d be left with would more or less just be a language with Python-like syntax but some differences, and at that point I feel like it’d be better to just use Python (or another mature standalone language) due to its large amount of existing support.

[gertkeno]

@meorge

If you removed Godot and Godot-specific features from GDScript, what you’d be left with would more or less just be a language with Python-like syntax but some differences

Similar thoughts here, best cast scenario would be a Luau situation, Pythonu by Godot. Extending a existing language to reap the benefits of it’s ecosystem rather than creating a new ecosystem; and most differences from python is stricter type checking. Adding Python support would be a massive undertaking, much harder than decoupling from the engine.

Check out some of the online Repls

GDScript Playground

[sonicfangameMaker]

I agree, that would make the possibilities to do with the language unlimited(almost)

[peltodev]

Yeah, I agree. The “Why It’s Different from General-Purpose Languages” is very weird too, some of these seem to be plain untrue. How is Godot’s variant memory management (?) special? Because it’s reference counted? Or the claim about high performance… And what game-specific patterns does GDScript support?

I don’t think GDScript has much potential as a standalone thing, it’s just not that good a language😅 Type system is ok at best, not very performant, code is annoying to split into multiple files, heavy reliance on singletons, super weird class system (every file is a class… which can declare inner classes?), …the list goes on. GDScript just isn’t designed for it.

I get why someone would want to use it for other things if they don’t know many other languages. However, I fail to see what GDScript has that other, more mature, languages don’t.

[wyattbiker]

As a standalone language meh … as others have described. But as @gertkeno mentioned a built in Python style REPL would be very handy. There is an expression eval in the debugger in the latest dev, but some sort of command line execution of gdscript would be amazing.

[Pakrohk]

I think there might have been a misunderstanding, or perhaps my intended meaning wasn’t fully clear. I’m not looking for a 100% separation of GDScript from Godot. Rather, I’m seeking a way for GDScript to have independent development, so that optimization, library additions, and new features don’t have to wait for new Godot releases.

This is similar to the challenge C# faces with its .NET dependency. As GDScript’s community grows, it might face similar limitations. We should allow the language to have its own libraries and contemporary development independent of the engine, while maintaining its integration with Godot.

[Pakrohk]

I’d like to clarify my intention more precisely. The goal isn’t to make GDScript usable everywhere - rather, it’s about not having to wait for game engine updates to enhance the language’s development capabilities. Having a dedicated interpreter or compiler for GDScript would significantly boost its development, especially while maintaining strong synchronization with the engine.

The key point is that with independent language tooling, we could have more robust runtime management systems and expand the library ecosystem for the engine. This approach would strengthen GDScript’s role within Godot rather than trying to make it a general-purpose language.

[alex2782]

Technical Benefits of Standalone GDScript:

• Optimized for real-time performance
• Better memory management for game objects
• etc.

I find it very difficult to imagine that “standalone” really improves all of these points.

Example: Godot → Core → OS → Time: _bind_methods() → This function releases many (not all) C++ functions for GdScript. Docs: class_time

GdScript is already very closely connected to the engine. If you want the highest performance, then you have no choice but to first program C / C++ / Assembler functions and then release the functions for GdScript in exactly the same way.

---

You can find more feedback here:

1. Proposal: GDVM / standalone GDScript · Issue #17846 · godotengine/godot · GitHub
2. Extract gdscript runtime as a individual interpreter? · Issue #20631 · godotengine/godot · GitHub
3. Standalone and embeddable version of GDScript (2.0)? · godotengine/godot-proposals · Discussion #6199 · GitHub

---

Running a script: Command line tutorial — Godot Engine (stable) documentation in English

The ability to run scripts is already included:
--headless
--script
(For me this is something like “standalone”)

[meorge]

How would making GDScript more “independent” help it be developed faster? As far as I know there’s already a team dedicated to working on GDScript that holds regular meetings and plans out what they’re going to work on for the language - what would change for them?

[Pakrohk]

Easier Contribution Path: Currently, contributing to GDScript requires understanding a large portion of Godot’s engine source code. With more independence, enthusiastic GDScript users could contribute to the language itself without needing deep engine knowledge.

Library Development Freedom: Let’s use an example - say there’s a library like Plasma Widget Lib (just an example) available for Python and JavaScript. Currently, if GDScript developers want to create similar functionality, they need to work through Python bindings. If GDScript were more independent, enthusiastic developers could create native libraries directly.

Community-Driven Ecosystem: This would enable more community contributions in areas like:

• Direct web framework implementations
• AI integrations developed by the community
• Native libraries built by GDScript enthusiasts instead of relying on foreign language bindings

The key difference is that passionate GDScript users could contribute to the ecosystem directly, rather than everything needing to go through engine integration or AssetLib APIs. This could create a more vibrant community of GDScript library developers.

[meorge]

Easier Contribution Path: Currently, contributing to GDScript requires understanding a large portion of Godot’s engine source code. With more independence, enthusiastic GDScript users could contribute to the language itself without needing deep engine knowledge.

From my own experience, this isn’t true. The code for GDScript is contained entirely within godot/modules/gdscript at master · godotengine/godot · GitHub, and the README there even says

GDScript is integrated into Godot as a module. Since modules are optional, this means that Godot may be built without GDScript and work perfectly fine without it!

So you do not need “deep engine knowledge” to make changes to GDScript right now, that you would not need if it was developed “independently”. Of course, you’d need to know how to navigate the GDScript code base, which can get pretty complex - but that’s the same regardless of how “independent” it is.

Library Development Freedom: … If GDScript were more independent, enthusiastic developers could create native libraries directly.

This is already possible, and people are already doing this. Dialogue Manager, Godot XR Tools, and godot-fft are all made with GDScript as it currently is. There just needs to be people interested in making more libraries for GDScript, in order for those libraries to exist.

Community-Driven Ecosystem: … The key difference is that passionate GDScript users could contribute to the ecosystem directly, rather than everything needing to go through engine integration or AssetLib APIs.

They already can. All three packages/libraries I noted up above can be downloaded from GitHub and installed without needing to go through Godot’s AssetLib. The AssetLib simply provides a more streamlined optional interface for getting assets and things.

The reason why there aren’t as many libraries available for GDScript is that GDScript is a domain-specific language, refined for Godot. Languages like Python, on the other hand, are built from the ground up for a wide variety of applications. Developers usually work on libraries when they have a need for them. So if they’re not using GDScript, then they don’t have a need for a GDScript library, and thus they won’t create it. In most cases, other mature languages like Python have solutions ready, so it makes much more sense for them to just use that instead.

If our end-goal was to have a scripting language in Godot with tons of library support, I think it would make more sense to just integrate Python, rather than try to get GDScript “up to speed” with it.

---

Also, please stop using ChatGPT to write your answers, and just use your own words instead. If we were interested in discussing this with an AI we’d go to the AI ourselves.

[duckbanditdan]

As much as this is an interesting idea, it looks like the cons outweight the pros here. Promoting GDScript’s use outside Godot could lead somewhere, but I think it would be a hard sell.

[Pakrohk]

@meorge

This is already possible, and people are already doing this.
… (I am a new user, I can only send two links, so instead of deleting one, I should not write any of them to be fair.)
are all made with GDScript as it currently is. There just needs to be people interested in making more libraries for GDScript, in order for those libraries to exist.

I think the reason why there are few libraries for Gdscript is that actually Gdscript libraries are not managed independently in a specific repository or at least the community does not have enough information about it and everything is summarized in the same AssetLib itself. That’s why even if there are special libraries or frameworks, it’s called Godot framework and not Gdscript, unfortunately we don’t even know a command line interface for Gdscript or even anything. Similar to Pip3 in Python or CarGo in Rust

@meorge

Also, please stop using ChatGPT to write your answers, and just use your own words instead. If we were interested in discussing this with an AI we’d go to the AI ourselves.

Regarding artificial intelligence, I just thought that it might be better conveyed that way.

@meorge

So if they’re not using GDScript, then they don’t have a need for a GDScript library, and thus they won’t create it. In most cases, other mature languages like Python have solutions ready, so it makes much more sense for them to just use that instead.

If we were thinking of integrating Python instead of Gdscript in Godot, just like a What if scenario, would Python be as suitable as Gdscript for personalizing and optimizing a language to run alongside Godot? Gdscript is now well optimized for making games and making graphic software (3D and 2D Design applications).

[Pakrohk]

I think the best suggestion is still the words of our good friend @gertkeno and I am open to similar suggestions and ideas.

[meorge]

I think the reason why there are few libraries for Gdscript is that actually Gdscript libraries are not managed independently in a specific repository

There is a collection of GDScript libraries here: GitHub - godotengine/awesome-godot: A curated list of free/libre plugins, scripts and add-ons for Godot However, “managed independently” and “in a specific repository” seem like they are contradictory.

That’s why even if there are special libraries or frameworks, it’s called Godot framework and not Gdscript

Because GDScript and Godot go hand-in-hand; GDScript is made for Godot, and thus any GDScript libraries are Godot libraries. If someone wanted to make something not involving Godot, they wouldn’t use GDScript. They’d use a language with similar features/benefits that was more suited to their task (likely Python).

Regarding artificial intelligence, I just thought that it might be better conveyed that way.

It does not. It ignores and/or “misunderstands” what we’re saying and requires us to re-explain ourselves. Thank you for ceasing its use.

…would Python be as suitable as Gdscript for personalizing and optimizing a language to run alongside Godot? Gdscript is now well optimized for making games and making graphic software (3D and 2D Design applications).

GDScript isn’t well-optimized for games and graphic design, per se; Godot is, and because GDScript is made to take advantage of and integrate with Godot, it provides a good interface to Godot’s good optimization.

Just syntax-wise, I think Python would be the best choice to attempt to integrate into Godot. It’s got tons of library support and resources available online for it, and of course the syntax is very similar to GDScript. I know, however, that Python wouldn’t have some of the syntactic sugar that GDScript has, such as accessing node paths like $Sprite2D or unique named nodes like %Label. There’d also have to be different syntax for declaring signals. I’m sure these are things that could be figured out given enough time, if people were able to get a Python module working in Godot.

[Pakrohk]

@meorge

Because GDScript and Godot go hand-in-hand; GDScript is made for Godot, and thus any GDScript libraries are Godot libraries. If someone wanted to make something not involving Godot, they wouldn’t use GDScript. They’d use a language with similar features/benefits that was more suited to their task (likely Python).

Are you sure you understood me correctly?! Now, for example, what does a database management framework with the help of Orm have to do with Godo? 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 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. It is necessary, because the concept of library and language framework are different from game engine assets.

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? Does that mean that if I want to have a strong market in my game, I should use Python instead of Gdscript? Or if I want to use the network of a digital currency directly, should I create it in addition to the language compatible with Enjin? It’s really weird to need an external API for anything.

@meorge

GDScript isn’t well-optimized for games and graphic design, per se; Godot is, and because GDScript is made to take advantage of and integrate with Godot, it provides a good interface to Godot’s good optimization.

Just syntax-wise, I think Python would be the best choice to attempt to integrate into Godot. It’s got tons of library support and resources available online for it, and of course the syntax is very similar to GDScript. I know, however, that Python wouldn’t have some of the syntactic sugar that GDScript has, such as accessing node paths like $Sprite2D or unique named nodes like %Label. There’d also have to be different syntax for declaring signals. I’m sure these are things that could be figured out given enough time, if people were able to get a Python module working in Godot.

Python’s long history has really meant that its community has a method for everything, but again, I doubt it could be as good as Gdscript, I still feel that Gdscript needs an independent system for development, I mean direct access to it. In bash and management, Gdscript libraries are really necessary, as well as a system for global environment management, I am a Linux user and it is really difficult for me to deal with Gdscript when my project is to be expanded (Godot’s attractiveness compared to others) Game engines have a feeling of greater compatibility with the system, which ruins that feeling for me.