reduz
commented
6 years ago GDScript is so simple, so small, so maintainable and hassle free in general (just works)… that it's difficult to justify anything else or any modification as better.
On Thu, Mar 29, 2018, 10:58 Juan Garcia notifications@github.com wrote:
TL;DR
Expose the GDScript VM and re-implement GDScript source to bytecode compiler (tooling) in GDScript itself in a different git repository. Motivation
GDScript is one of the best features of Godot. It let's you quickly run the editor, start coding and have a simple prototype in minutes. This is extremely useful for those who want to work in a multi-platform game but do not know how or are not willing to setup and maintain a cross platform C++ tool chain.
However, there is a trade-of for such convenience: there is only one language to choose from, and adding new features sometimes divides the community on if it is or not needed and how it should be implemented. For example, things like optional typing, which it might seem a minor thing, will never be implemented in a way that everybody will agree, while other languages features might be to great interest of only a few people and just skipped. All this just adds to the complexity of what it is just a huge difficult task to improve and maintain a community driven game engine. And the maintainers have been doing a great job on do it all that, with a great community that has also made great contributions.
But I think that all this can be improved, and maybe it can now be a great time for doing so. Proposal
If the GDScript module get refactored in way that its VM gets exposed to the editor with the ability to use scripts in bytecode formats, interesting things can be done with it.
This can have many interesting advantages, and we should also consider its possible disadvantages. Bellow are just some ideas, and not conclusions. Possible advantages
-
GDScript can be rewritten in GDScript itself, to produce bytecode output. This could enhance its maintenance as there are many people interested in GDScript that want to contribute but, for any reasons, can't do so in C++.
GDScript can have it's own repository, adding additional maintenance improvement to the current state. The main Godot repository can clone from an stable version or, better yet, download the bytecode compiled tooling during build time, so that the default release is still as simple as user friendly as ever.
New independent languages can be created by other developers and outside Godot. This can be from simple DSL, GDScript unofficial extensions, or other full languages. Those could be provided to the editor through plugins.
The scripting backend (the VM module) can be improved, optimized, bug fixed and extended without having to worry about other things like syntax, keywords, etc., and also tokenizing, parsing, etc.
For better or not, close source libraries can also be created this way. When this might sound insulting in an open source community (and not been a fan myself of proprietary solutions), this could be a new way to open new lines of contribution for those willing to provide commercial solutions with bundled library assets.
The main Godot repository will be freed of maintaining GDScript, which will help on ease the amount of issues and PRs, which are now way too many.
GDScript can evolve past the problem of breaking compatibility by providing multiple versions if the game developers needs them.
New build tools could be made. For example a 'require' or @Grab like per file dependency management, or a DSL build script.
Possible disadvantages
-
If GDScript is moved to a new repository, the main repository must be kept in sync somehow by pointing to an specific commit or release. In which case GDScript becomes a dependency. This could also be done by downloading the GDScript tooling when the editor first starts up.
GDScript tooling must be bootstrapped, as we have the chicken-egg compiler problem. This should be OK if we keep the first compiled version in the GDScript tooling in the git repository, and subsequent versions as build artifacts. The first compiled tooling to be kept in the git repository must be able to compile itself and it have to be developed in a version of Godot with embedded GDScript (as it is now). Maybe first developing a self-interpreter https://en.wikipedia.org/wiki/Meta-circular_evaluator can be a temporary option for testing.
Many incompatible, unpolished and with unclear features GDScript forks may spawn, but hey, this is the bazaar.
The nodes will have to point to the bytecode compiled classes files instead of the *.gd files when referring scripts. Maybe this can be handled the way the the collada files are handled now by using import files, so that the bycode files can be .gitignore'd and the source committed.
This will need more coordination than other more usual features PRs, as at least 2 developers, ideally contributors, should work on it, one on the C++ part of the VM APIs and editor exposure, and other in the GDScript tooling (source to bytecode compiling).
Conclusion
Even with all the disadvantages, I think that implementing this proposal would have a positive impact in the future of Godot. It would be great to see how other Godot users and the developers see this proposal, either if accepted or rejected, see what new ideas, info, etc. can be discussed before any of us attempt to come up with a implementation and a PR.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/17846, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z2xljkspJUzI24zBVoVUGCssBl5P2ks5tjSDMgaJpZM4TAvXP .
karroffel
ghost
groud
Sslaxx
vnen
efornara
juan-garcia-m
TL;DR
Expose the GDScript VM and re-implement GDScript source to bytecode compiler (tooling) in GDScript itself in a different git repository.
Motivation
GDScript is one of the best features of Godot. It let's you quickly run the editor, start coding and have a simple prototype in minutes. This is extremely useful for those who want to work in a multi-platform game but do not know how or are not willing to setup and maintain a cross platform C++ tool chain.
However, there is a trade-of for such convenience: there is only one language to choose from, and adding new features sometimes divides the community on if it is or not needed and how it should be implemented. For example, things like optional typing, which it might seem a minor thing, will never be implemented in a way that everybody will agree, while other languages features might be to great interest of only a few people and just skipped. All this just adds to the complexity of what it is just a huge difficult task to improve and maintain a community driven game engine. And the maintainers have been doing a great job on do it all that, with a great community that has also made great contributions.
But I think that all this can be improved, and maybe it can now be a great time for doing so.
Proposal
If the GDScript module get refactored in way that its VM gets exposed to the editor with the ability to use scripts in bytecode formats, interesting things can be done with it.
This can have many interesting advantages, and we should also consider its possible disadvantages. Bellow are just some ideas, and not conclusions.
Possible advantages
GDScript can be rewritten in GDScript itself, to produce bytecode output. This could enhance its maintenance as there are many people interested in GDScript that want to contribute but, for any reasons, can't do so in C++.
GDScript can have it's own repository, adding additional maintenance improvement to the current state. The main Godot repository can clone from an stable version or, better yet, download the bytecode compiled tooling during build time, so that the default release is still as simple as user friendly as ever.
New independent languages can be created by other developers and outside Godot. This can be from simple DSL, GDScript unofficial extensions, or other full languages. Those could be provided to the editor through plugins.
The scripting backend (the VM module) can be improved, optimized, bug fixed and extended without having to worry about other things like syntax, keywords, etc., and also tokenizing, parsing, etc.
For better or not, close source libraries can also be created this way. When this might sound insulting in an open source community (and not been a fan myself of proprietary solutions), this could be a new way to open new lines of contribution for those willing to provide commercial solutions with bundled library assets.
The main Godot repository will be freed of maintaining GDScript, which will help on ease the amount of issues and PRs, which are now way too many.
GDScript can evolve past the problem of breaking compatibility by providing multiple versions if the game developers needs them.
New build tools could be made. For example a 'require' or
@Grablike per file dependency management, or a DSL build script.Possible disadvantages
If GDScript is moved to a new repository, the main repository must be kept in sync somehow by pointing to an specific commit or release. In which case GDScript becomes a dependency. This could also be done by downloading the GDScript tooling when the editor first starts up.
GDScript tooling must be bootstrapped, as we have the chicken-egg compiler problem. This should be OK if we keep the first compiled version in the GDScript tooling in the git repository, and subsequent versions as build artifacts. The first compiled tooling to be kept in the git repository must be able to compile itself and it have to be developed in a version of Godot with embedded GDScript (as it is now). Maybe first developing a self-interpreter can be a temporary option for testing.
Many incompatible, unpolished and with unclear features GDScript forks may spawn, but hey, this is the bazaar.
The nodes will have to point to the bytecode compiled classes files instead of the *.gd files when referring scripts. Maybe this can be handled the way the the collada files are handled now by using import files, so that the bycode files can be .gitignore'd and the source committed.
This will need more coordination than other more usual features PRs, as at least 2 developers, ideally contributors, should work on it, one on the C++ part of the VM APIs and editor exposure, and other in the GDScript tooling (source to bytecode compiling).
Conclusion
Even with all the disadvantages, I think that implementing this proposal would have a positive impact in the future of Godot. It would be great to see how other Godot users and the developers see this proposal, either if accepted or rejected, see what new ideas, info, etc. can be discussed before any of us attempt to come up with a implementation and a PR.