This issue is meant to consolidate the discussion around the Scripting API.

It might be a bit early for an actual implementation to come out of this, however, starting a discussion around API design and goals should provide benefits when impl time comes.

On a discussion in gitter we threw around some ideas

@torkleyy mentioned he would like to have an alternative to the classic scripting approach. One of the ideas proposed was to have flexible scripting files that could be used as config files.

I already toyed with an idea for an alternative to the classic scripting approach. I wondered if we could just have pretty flexible config files, like we plan already for entities and other stuff of the engine. I mean, this does not conflict with scripting, but I think it would be worth to experiment with it, because looking at most scripts, these could be easily transformed into a YAML/JSON/whatever file. Additionally, these files would nicely integrate into GUI (you could probably generate a GUI dialog by some scheme) and tooling, the user is able to define custom ones (like configs for items, weapons, levels, ...). I still have to think about this idea some more, but I think it'd be worth trying it out. That said, I'm open for other ideas or for hearing situations in which you would additionally want a scripting language. I'm going to write up the advantages of this approach in a few days.

With an example

// some_script.pseudo

class MySuperItem extends Item {
    fn getTex() = "items/super_item";
    fn getBlah() = "Blah";
}

fn on_init() {
    register_item(MySuperItem);
}

Or, as config:

# super_item.yml
name: MySuperItem
tex: items/super_item
blah: Blah

@Xaeroxe and @lschmierer Discussed some ideas involving accesing components from a scripting language. Briefly mentioned is the feasablity of running the scripting system in parallel as an actual System.
However this seems impractial due to the way specs enforces SystemData correctness on a type level.

There are a lot of things that need to be addressed, however, I think we should start with:

• Are we going for a traditional scripting api, or with something newer?
• How important is it getting the scripts to run in parallel?