I propose a new section next to “Global Variables” called “String Tokens”. This would be a catalog of key/value pairs where the keys are token names (probably restricted by object naming constraints) and the values are Strings.
Then anywhere in a GDevelop field that expects a String value you can “$TOKEN_NAME” (with auto-completion once you start typing after the $… and also warn if no token by the current name is defined) and at compile/preview/runtime it will substitute in the string value for that token.
These tokens should be backed by a simple JSON file, and a new action should be added that allows reading tokens from a JSON file which would override any existing tokens with the same name.
Here are some of the benefits this offers to GDevelop users:
- Less typo errors when using static strings (i.e. GameState = “idle” vs “Idle”)
- Create translation catalogs! (Text is defined using tokens, and you can load different language values using specific JSON)
- Macros? (Depending on when the substitution is done it could be possible to take commonly used complicated Strings like “PlayerState[GlobalVariableString(CurrentState)].Stats.Health” into a token like $PLAYER_HEALTH)
I know this is a little more low-level than GDevelop typically goes, but it could really help reduce errors and allow for a lot more abstration.
I see why one would like it and how it is useful, but I feel like this is all stuff that should already be possible with “better”/more flexible solutions. For example, the less typo error can be avoided by adopting a consistent naming style, or the translation catalogs could already be used with a specialized extension that loads JSON catalogs into global variables, and the currently loaded one in another, and an expression that gets the correct string from the catalog, or you can build with events based extensions smaller expression instead of using macros.