While JSON is undeniably useful, and in many cases can do an adequate job as a resource for basic text, it’s not always appropriate. Issues mainly stem from needing to pre-process and post-process the text into and out of JSON form. At minimum, this requires wrapping the text in [" and "] during design, then pulling out the 0th element after loading. However, text often contains newlines and quote characters that require escaping and un-escaping. If the text is frequently edited, such as with narrative heavy games, then the design-time pre-processing side can become unwieldy and, at best, is an extra step in the design cycle, which really benefits from being as rapid as possible.
It seems like a dedicated text resource type would be frequently useful. It also seems like it would be fairly straightforward: implemented in parity with the JSON resource type, but without parsing the JSON and with putting the result into a string instead of a structure.
I’d be willing to give this implementation a try, but I want to see what others, especially the developers, think of the idea.
If i well understand, it would be useful that the possibility to manage text files (creating or adding - deleting - inserting of strings lines, etc.) is created in GDevelop.
An extension or a comportement could be created with GD to do that?
So, manipulating text files would be easy to manipulate and of course, very useful to GDevelop games creators.
What do you think of that?
BUT i wonder what you care to output or more likely to what?
Like example of use case?
For what i could use resource that holds purely text in gdevelop?
@Amigo54, I think that an extension could be great if one could get it to work, but the system is not really designed around text file resources, so it’s hard to imagine that an extension could easily fill this gap. This seems like the kind of thing that warrants updating the engine to include it.
@ZeroX4, a few examples come to mind for when text file resources would be more appropriate than JSON resource. They fall into a few camps:
Pre-generated text files in a format other than JSON. Perhaps some editor’s output is in xml, or some other format. Perhaps the text file comes from an external source, such as a long dictionary of words, or geographical data. Converting such files to JSON isn’t necessarily hard, but it can become cumbersome, especially if a file from an editor needs to be tweaked a lot over the course of development. Every tweak requires re-conversion to JSON.
Ascii / text based files that rely on characters that are restricted in JSON, such as newlines JSON doesn’t allow strings to include newlines. Instead, the string needs “\n” wherever a new line should be. If text resources are designed around both manual editing and multiple lines, then this can get tricky. For instance, imagine a level format that is a grid of characters in a text file: “#” characters are walls, “.” characters are floors, “$” characters are mobs, etc. Such a grid is visually easy to edit when every row is on its own line. However, that isn’t possible with JSON. Thus, updating level data requires updating the original text file, then converting it into a JSON format, which turns the grid into a single long string with “\n” to separate rows. Another example would be a scripting language, which would require writing the source code, then converting the content of the source code file into a JSON compatible string in a JSON array to store it as a JSON resource in GDevelop.
I didn’t that you can do this (see your picture) in GD for formatting the strings in variables (the character "")
Are they another parsing characters like that?
@ZeroX4. Ok, I think I understand what you are asking.
In my particular situation I’ve implemented an interface for yarn scripting. It’s similar to GDevelop’s built-in system, except that it allows for running multiple yarn branches concurrently (among other things), which lets this interface be viable for multiplayer games. Running multiple yarn branches concurrently is not possible with GDevelop’s built-in yarn system. Also, I’ve used this 2.0 version of bondage.js, instead of the older bondage.js version GDevelop’s built-in system uses, so there is support for more advanced yarn features.
Bondage.js natively supports both the standard yarn text format, and JSON-based yarn scripts (which is how GDevelop supports them), but the editor I’m using is the Visual Studio Code extension for yarn spinner scripting. It’s the only feasable option AFAIK (GDevelop’s yarn editor isn’t really set up for project-wide yarn management). This VS-Code extension does not allow saving or loading yarn scripts as JSON. It only supports yarn’s standard text format. Currently, I’ve set up a node.js transpiling script that iterates over all yarn files in the resources folder and converts each to the JSON format (saving the results to separate files). However, needing to re-run this transpiling script after every change is cumbersome and, since I’m planning to use this as a teaching tool, I’d like to remove this transpiling step for my student’s sakes.
That’s my current situation. I hope this answers your question. Loading text file resources directly in GDevelop would let me bypass the transpiling step that is currently required to integrate changes to yarn scripts into the game.
