(Concept) GScript

I’ve been thinking about this one question for years… How hard would it be for the developers of GDevelop to create a custom scripting language, separate from JavaScript and the events system, using the underlying functionality set by the event system?

I think everyone has the same question, wouldn’t it be a ton of work to remap every action to work as something you can type? Usually, you’d be right. However, I realized something when I copied an action, and formatted the JSON.

Take for example the play a sound action.
Screenshot 2026-10-08 at 8.39.35 PM

This looks like you’d have to make some new interpretation of this, except I learned every action has a short, simple name.

This is the beautified JSON of a PlaySound action:

It has an internal name of “PlaySound”.

{
  "000kind": "GDEVELOP_EventsAndInstructions_CLIPBOARD_KIND-jsBdHbLy912y8Rc",
  "content": {
    "eventsList": [],
    "eventsCount": 0,
    "actionsList": [
      {
        "type": {
          "value": "PlaySound"
        },
        "parameters": [
          "",
          "freesound_community-trying-to-open-a-locked-door-104302.mp3",
          "no",
          "60",
          "1"
        ]
      }
    ],
    "actionsCount": 1,
    "conditionsList": [],
    "conditionsCount": 0
  }
}

This slightly differs from how it transpiles to JavaScript:

gdjs.evtTools.sound.playSound(runtimeScene, "doorclose.wav", false, 60, 1);

Theres all sorts of small differences. Different cases, “PlaySound” instead of “playSound”, “no” instead of “false”.

GDevelop already has it’s own internal system, that could simply be used just like this:

// pseudo code
PlaySound("doorclose.wav", no, 60, 1);

And with GDevelop’s expression system, can be expanded on.

// pseudo code
PlaySound("doorclose.wav", no, RandomInRange(50, 60), RandomFloatInRange(0.8, 1.2));

Already using things deeply familiar to GDevelop event system and JavaScript programmers.

I admit while this does seem quite similar to JavaScript, in practice, programming a GDevelop game in JavaScript never ends up looking this simple.

So am I wrong here? Any thoughts to add?

I also wish that these scripts would be put into files such as script.gs, NOT as blocks in the event editor.

Oooo this seems very interesting

Thank you for the likes everyone!

I realized something, with the close parity between GScript and the event system, I realized it might even be possible to translate visual scripting into GScript, and GScript into visual script.
(from now on I will be referring to the events system as “visual scripting”.)

It seems unnecessary to me.

what are you talking about…?
i think it would be the most necessary thing to add to gdevelop…of all time.

I think he means unnecessary in the sense that a lot of people coming to Gdevelop wants a no-code game engine, and have no idea how to code. Spending time creating a whole new code script would be time consuming when the time could be spent making the engine more efficient and have more features?

While it’s a good idea and I’m sure would be helpful to developers, I’m not sure it is necessary.

i know not everybody shares the same opinion on javascript, but javascript is an incredibly difficult language to program in, especially for beginners.

I must say that gdevelop’s visual scripting is a poor introduction to programming for beginners, merely because there is nowhere else to go after the fact, you cant level up your skills, and keep what is familiar with gdevelop.

GScript alongside gdevelop’s visual scripting would give a direct path to strengthen coding capabilites and skills, and would make learning incredibly intuitive and natural with the ability to translate GScript into visual scripting, and vice versa. You could write a visual script, and see how your events map to functions inside GScript.

I think it would be an incredibly powerful tool for learning, and development. People wanting visual scripting is purely a lack of knowledge, or something not being intuitive to them. I believe this would fix all of these issues, and create a stronger generation of game developers and programmers.

P.S. And every extension would automatically work inside GScript too, as theyre laid out exactly the same as native conditions and actions.

…This would make me switch back if I didn’t have so much progress in Godot.

As someone obsessed with GDScript, I definitely support a text language.

If I were to come back and this became real, I would definitely using GScript in my projects.