Note: this questions is along the lines of “if we had our own fresh game engine”

Are scripting languages for a game engine still relevant with hot-reload? What about embedding wasm? Why still have a scripting language for your engine?

Extremely

On 9/6/2019 at 5:59 PM, Plotnus said:

Are scripting languages for a game engine still relevant with hot-reload? What about embedding wasm? Why still have a scripting language for your engine?

A problem i'm starting to think about: how do i formally describe all those things that are there to load, display, make sound, their properties, positions, dependencies and interactions etc.pp. That'll probably be some sort of markup language, or integrated scripting language, something the computer can be easily convinced to understand as well as for an average human be easy to type in.

But that is only one aspect i think ...

The purpose of game scripting is not to be lazy about compiling when making core components, because that only leaves a slow and buggy hard-coded mess without type-safety when people can commit code that won't even compile. Scripting is for the tiny code that's loaded dynamically with a level or asset when needed to save instruction cache and provide a safe plug-in system for rarely executed code like dialogues and cinematic events where text makes more sense than signals being sent through nodes (doors and elevators).

Example code using a scripting language from my previous project:

npc "A good day to you.";
player "A good day to you too." {
  "How are you this morning?":
    npc "I am very well, thanks for asking.";
  "I like swords.":
    npc "What are you, an npc or something?";
}

First, note the simplicity of the syntax.  That's a nice benefit of using a scripting language, but no big deal.  Also note that the script runs in its own "thread" that runs parallel with the game.  This is actually more like a coroutine, which means that I can do without thread synchronization.  That's another benefit.

But the main benefit of using this scripting language is this: if the player quits the game at any time, the game is auto-saved.  And if the game is auto-saved while a script is running, the state of the script is auto-saved along with the rest of the game state.  In other words, if the player is in the middle of a conversation when the game is saved, then the state of the conversation is also saved.  That's very powerful, and there's no way to get a similar effect in a traditional programming language.  The equivalent in C++ would be an unreadable mess like this:

class this_one_conversation : public serializable {
public:
  bool run(int notification) {
    switch (this->state++) {
    case 0:
      find_entity("npc")->say("A good day to you.", this);
      return false;
    case 1:
      find_entity("player")->ask("A good day to you too.", this, "How are you?", "I like swords.");
      return false;
    case 2:
      if (notification == 0) {
        find_entity("npc")->say("I am fine, thanks for asking.", this);
      } else {
        find_entity("npc")->say("What are you, an npc or something?", this);
      }
    case 3:
      return true; // End conversation by returning true.
    }      
  }
  
  void serialize(serializer& ser) {
    ser(this->state);
  }
private:
  int state = 0;
};

A scripting language is there to separate data from the code.

If you have, let's say, a conversation like above, you can hardcode all the dialogue in the code, and that will work. But then, any time you want to change a line of dialogue, you have to rebuild the whole engine/game. To avoid that, you make a separate file with all the text, which the engine loads at runtime. That way you separated your data from your code, and you can change your data without touching the code (and without rebuilding the engine).

It's similar with scripts. This way, your scripts become data instead of being code. So if you have a scripted conversation, you can change the rules that are in the script without needing to rebuild the entire engine. You can even completely swap it with another script without touching the engine at all. There's also all the other benefits, like the scripts being easier to edit by team members that are not programmers, and also easier to find than being "buried somewhere in the code". And if the team is working on more than one project at the same time, they can use the same build of the engine for all projects, with separate scripts and data, that makes engine maintenance a bit easier.