Cee's Funposts - A Type System for Scripting ECS
ceesstuff.github.io

cross-posted from: https://programming.dev/post/1086370

This time on my arbitrary blog: Entity component systems.

Also, highlight.js should degrade more gracefully without JS activated than last time. Note that I can’t process syntax highlighting in my build step, because I don’t have a build step.

  • TheCee@programming.devOP
    1·
    1 year ago

    I’ll split this up…

    For inspiration, I recommend looking at bevy.

    I did, it’s just that I do not consider programming in Rust scripting. Scripting is kind of a vague term, I admit, but to me, it has to fullfill roughly the following criteria:

    • fast to no compilation time
    • doesn’t need big SDK or setup that was required to build the engine
    • can be handed over to some graphics designer, level designer or admin

    So, for example:

    • Is Unity/Godot C# scripting? If I feel generous, probably not, though.
    • Is Bevy or Fyrox hot reloading scripting? Nah.
    • Is Scala command line “scripting” scripting. Uh-uh.
    • Is GDScript scripting? Yes, most likely.
    • Is [muh Lisp] scripting? Possibly.
    • Is Blueprint scripting? Yes.

    So, basically the only option that remains are embedded interpreters. More or less. With this in mind…

    This comes as a surprise to me. I think scripting capabilities would be incredibly useful, especially if you can hot reload the scripts during development time. For core engine functionality, this might be less relevant, but for the gameplay itself it could be really nice.

    As far as I understand, studios employ ECS for two reasons:

    • enhanced flexibility
    • enhanced performance for huge numbers of entities in components (this seems to be the case 99% of all times)

    So with the second use case in mind, an embedded interpreter seems kind of off the table. Even an embedded compiler might be off the table most of the times, although I’m not sure how tight performance requirements are. You’d practically have to implement what this thing promises, for a rather specific use case. So unless some major player puts money behind it I don’t see that happen.

    EDIT: I should add, I’m purely speculating about performance. But breaking a cache line to load an interpreter context several times sounds kind of meh.

    • TehPers@beehaw.org
      1·
      1 year ago

      I do not consider programming in Rust scripting.

      I don’t think most people do to be honest, I was providing it as reference because it’s a strongly typed ECS. One of the other challenges with scripts is they often don’t have static type checkers since they’re intended to be executed right away. mypy and TypeScript have helped tremendously with Python and JavaScript, but they’re still extra steps that need to be executed before you can run your code.

      an embedded interpreter seems kind of off the table.

      An embedded interpreter can still be highly performant, assuming it has a decent JIT compiler. Sending data between the host and the interpreter would be a concern, but it might be possible to allow the script to share memory with the host and directly access the components (while holding locks on those components’ storages). I tried experimenting with this a while back using WASI, but unfortunately the runtimes I played with (wasmer + wasmtime) weren’t yet mature enough from my experience to be realistically useful, and I couldn’t figure out how to get the modules to share memory with each other.

      I know there are people playing around with scripting capabilities in bevy though, so I’m sure this will be possible at some point. The other challenge, of course, is having a scheduler that’s flexible enough to handle dynamically added/removed systems, and systems which execute runtime-specified queries.

      Edit: I should add that a large part of the performance of an ECS comes from the ability of an ECS runtime to parallelize the systems. If your interpreter can execute the systems in parallel, then you still get to keep that benefit as long as your scheduler knows which systems are safe to run in parallel.