Hi, I love Gdevelop, I would like you to add these things. Mod support, This would be very good, make mods, and then upload them in for example Gamebanana etc. Translate Support, This would be very good, make your game international, It could be done with an extension that adds the following conditions, If the country is “Country”. this is all, bye
Hello!
Both of these things exist today.
For translation support, you would just need to set up your own “Choose your language/country/etc” screen at the start of the game, and store the selected country as a variable.
Then you use that variable as a condition for any of your text objects (or graphical assets) in the game, and update the text or object based off the selected country.
This is how the majority of game engines do it, as they have no way to detect the “Country” of a user.
For “mod support”, there’s no such thing as generic mods, but you can easily set up events in your game to support some type of json file, and set up a button that loads a json file using the FileSystem events. All games have unique formats for mods, and adapt them in different ways, so this is similar to how something like Steam Workshop works. You could do some more advanced mods with GDMod from Arthuro: GitHub - arthuro555/gdmod: A mod loader and modding API for GDevelop games.
I don’t know how other game engines handles it, but most platforms provide some ways of detecting the user’s preferred language. For Linux, you can check the LANG environment variable, and on the browser, you can use Navigator.language.
As well, the handling of the localized resource is often through a framework rather than simple conditions. For example, in Android, the developer will provide the different language resources in different directories. Android will then handle the loading of the correct language and the fallback to the default if a localized resource is not found.
Personally, I think that for text strings, this can be easily handled in an extension. For graphics and audio, this can be a little more tricky.
1 Like
Totally valid, but most game engines don’t access a lot of system variables, and just leave it up to a user to select languages at start/settings.
In unity and defold, you have to set up your own localization code/logic (although some people have built out unity add-ons for sale that prebuilds this code for you)
Resource wise, in GDevelop it really would just be an condition for the language and then loading your respective resources.
Heck, you could likely just skip the condition and set up your resources to have a language at the end of a name. Loading up a dialogue file from yarn? Instead of manually selecting the file in full, you’d just build the filename by doing ToString(“dialogue” + GlobalVariablr(selectedlanguage) +".json"). If a user selects english, you’d set the global variable to us-en, and it’d load dialogueus-en.json so long as you have it added in resources.
Same could be done for audio, I think. Same can definitely be done for graphics, but you’d want it to be set up as a sprite object, and have your different versions as different animations with the same name, just with the language at the end. Then you do similar to the above when you change animations or at the start of the scene. (I do this today but for button prompts based off detected controller type)
1 Like
I think that text strings are easy to handle. It shouldn’t be too hard to build an extension that can…
- Auto determine language. (Action: Auto-set language)
- Allow the user to override the detected language (Action: Set language to ____)
- Retrieve a text string based on the current language or the default language if no translated string was found (Expression: I18n.getText(“string1”)).
For graphics, the approach you’ve proposed sounds workable, though it may be a little messy if there are a huge number of supported languages. The string concatenation method would give problems if not every language has a corresponding resource (…some may need to fallback to the default), but since the animation name is just a string, an expression like I18n.getText(“anim1”) would solve the issue.
Resources like the json file for yarn and audio files seems more tricky, as the field for these files don’t seem to accept an expression (…using “ToString(“dialogue” + GlobalVariablr(selectedlanguage) +”.json")" gives an error “This resource does not exist in the game”).
We can wrap every usage of resources in a set of conditions, but that could potentially add a lot of code and is prone to errors. Perhaps there are better ways of doing this; I must admit that I did not explore GDevelop in detail.
I see that Godot can remap resources based on the current language. That seems like a particularly clean way of handling things; the developer can create the game without worrying about different languages, then add in localization support when everything is done through a set of remaps without changing any code. I doubt this can be done in GDevelop through an extension, and it may require quite a lot of work in the core.
Personally, I’m using GDevelop only for teaching coding, so localization isn’t something I’m concern about, but I suspect that this may be important for some.
1 Like
I did some digging, and this part is already covered, luckily. TheGemDev and MauryDev actually built a Language extension for this which adds an expression to pull it, and it’s in the engine’s user extension list. You’d just use that to set the default language into a global language variable, then could let the user select/override as needed.
Good call, I was thinking the dialogue resource field could be manipulated like a Scene name field could, but it cannot. Although this can be worked around by using the “Load dialogue from a scene variable” event.
You could store your Yarn JSONs as a global variable, then transition them to a scene variable using similar logic to what I mentioned above (Global structure variable named “Dialogue”, children variables for each language. So at the start of the scene, you would do "Change the string of scene variable “Dialogue”: Set to GlobalVariableString(Dialogue[ToString(GlobalVariable(Language))]) and it’ll load whatever selected language.
Yeah, that localization option in Godot is nice and relatively unique (at least for a non-paid addon). It seems like it was added by a community contributor rather than their core members, too, which is interesting.
Without being able to make resources accessible via expressions, I’d agree, I’m not sure of a way to make this work via an extension. You could abstract it (Update the language extension to also have a condition that is “If Language/Language Variable is set to XYZ” and then you could branch your events) but that’s just making it so you don’t have to access the global variable directly. Not sure that’s really a huge simplification for folks.
@Emicraft As mod support already has an in-engine method (as I mentioned above) and a contributor made method (GDmod), I’m going to update the title of this thread to focus on the one that can’t be fully accomodated, specifically Simplifying Localization support. As with any feature request, there’s no guarantee anything will be built, but hopefully this will get more eyes on it since it’s not a generic title.