Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support storing Orchestration resources as text #263

Open
Naros opened this issue Apr 21, 2024 · 0 comments · May be fixed by #264
Open

Support storing Orchestration resources as text #263

Naros opened this issue Apr 21, 2024 · 0 comments · May be fixed by #264

Comments

@Naros
Copy link
Member

Naros commented Apr 21, 2024

Description

Orchestrator defaults to using binary-based formats for Orchestration resources; however, this has a drawback in that these tend to be hard on VCS systems and for the developers to know what changed across commits. For this reason alone, it would be helpful to store Orchestration resources as text resources rather than binary.

Implementation ideas

For Orchestrator 2.0 and likely 2.1, we want to allow users to continue using the binary formats by default, particularly if they have invested in that format's use in their games. To allow for this in a non-disruptive way, a new plug-in setting should be introduced that controls whether or not to use text or binary format by default. This can be changed in the ProjectSettings.

When set to use binary by default, users should notice no difference. The Create Script Dialog will default to using the .os extension, and the resources will be stored in binary format. If a user wants to export or save the script as a text-based .torch file, they can use the File > Save As menu option from the Orchestrator plug-in panel's main window.

The text-based format will use the same serialization technique that Godot utilizes for .tscn and .tres resources. While this format is somewhat verbose, it has a significantly smaller footprint than .xml and relatively smaller than .json or .yaml. The major downside to this is that there is a significant amount of parser logic copied from the Godot engine to support these formats, although maybe some discussion can be explored with Godot to make these available to GDExtension users.

Not only will this change require some refactor work and the new Loader/Saver implementations, a new editor export plug-in will be needed to convert resources during the export stage at a minimum from the text-based storage format to the binary format.

While this may be out of scope initially, this sets the stage for a new "export-only" format that contains a byte-code compiled version of the script, that has the best performance and optimizations for exported games.

@Naros Naros added this to the 2.1 milestone Apr 21, 2024
Naros added a commit to Naros/godot-orchestrator that referenced this issue Apr 21, 2024
@Naros Naros linked a pull request Apr 21, 2024 that will close this issue
3 tasks
Naros added a commit to Naros/godot-orchestrator that referenced this issue Apr 21, 2024
Naros added a commit to Naros/godot-orchestrator that referenced this issue May 1, 2024
Naros added a commit to Naros/godot-orchestrator that referenced this issue May 1, 2024
Naros added a commit to Naros/godot-orchestrator that referenced this issue May 1, 2024
Naros added a commit to Naros/godot-orchestrator that referenced this issue May 1, 2024
Naros added a commit to Naros/godot-orchestrator that referenced this issue May 13, 2024
Naros added a commit to Naros/godot-orchestrator that referenced this issue May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant