What we're using it for primary is to offer scriptable e.g. visually scriptable pipelines for everything from building the project up to the render system. I like the idea of going forward not just for design tools but also some convenience for programmers as well.
My baddest experience was the C#/NodeJS “build pipeline” in my former job, that had some components written in batch script. There was an error one day in the script, a typical weekend commit, which then broke everything and debugging a 500 line batch script isn't that fun anyways. I know there are other system, which we also used partially, but all of them requiere maintaining plain scripts. That's why I really quickly decided for our hobby project to go for a solution that has the really minimum of configuration in a JSON file and everything else is implicit logic.
However, this is why I wrote our Hecate tool which right now is a really good solution if you follow the rules. The next step is to offer visually scriptable build pipeline with a bunch of predefined nodes and an extensible node library. And we decided to go for our Meta Language, which is plain simplified way of writing code. Something like
if eql x 1
.call "System.Console.WriteLine" "Hello World"
is parsed into a node code graph of different nodes which offer some error checking. Except for the function identifier in this example, everything is plain generic and could be transposed into C# to be added to our C# based tools and/or C++ to be integrated into the engine code base or whatever language you want it for. Additional error checking needs to be made from the specific code generator when it reads the graph.
We will then have a bunch of JSON files which build the extensible visual node library. Those files define how many and which input connectors a node has, the output connectors and they also allow for defining Meta. Those visual node graphs are then read and their Meta code is collected and chained into the input stream for the Meta Language parser to form the final node graph which is then passed to the code generator.
Our Alchemy text processor already allows to preprocess text streams and offers not only macros but also import derectives that work somehow similar to C++ includes so we don't have to add this to the language. (We make use of it for JSON files as well, as Alchemy also has support for comments)
As Hecate makes use of NPM and theirfore allows for package.json files being present in a code module, I seized the peerDependencies field to have Hecate look for plugin modules when building. So one can specify a code module on a known path so Hecate is able to lookup the package and then it automatically adds it to the build even if it isn't specified somewhere but the package specifies one of the modules currently contained in the build. I wanted to use this for having our visual editing tool spawn a custom Hecate instance to hook into the build pipeline but it also works for code generated custom build steps.
Long story short ?
