Oh, thank you!
I would love to hear more about what you were trying to do with your project before. Was it more similar to the declarative coding part, the automatic multiplayer part, or something else? Part of why I'm doing this is to explore the design space of how games should be made and I'm interested to hear what problems, issues, pet peeves, "bugbears" etc that other people think are worth solving.
I've actually just recently been through this myself. I'm also building something for kids to build games in. But much more opinionated than Easel. It's interesting to me that Easel looks declarative but is imperative.
I've actually gone with a 100% declarative approach. Basically you define effects, which are executed in response to certain interactions. There's a comprehensive targeting system. But the best part is this is all type-safe using TypeScript, the declarative structure is enforced. That means even when you chain effects, nested effects are able to access (incl. autocomplete) the targets of parent effects etc. Whilst this provides a super nice experience to consume, it's definitely non-trivial to build this system.
Oh yes, handling interactions and dependencies and what is affected by what. I did a lot of React development (as in the frontend web framework) before making Easel and was quite inspired by how it hooks to change. The way you give it a little routine, it says what it depends on, and then it just fully re-executes that whole routine when the dependencies change. So in Easel when you say `with Health { ... }` it makes a behaviour that re-executes every time the Health changes. But, if it just reran the behaviour, then you'd end up with it adding a new sprite (for example) every time it re-executes, until you've got hundreds of them. So the other trick is the Easel compiler assigns an implicit ID to things like sprites so that it will replace rather than add the second time around. It's built into the programming language so you don't see it (most of the time). It actually took me 2 years to come up with that, which is both cool and depressing when I can explain it in one paragraph.
I found https://easel.games/docs/learn/language/functions/ids#implic... which suggests they are structure-based, at least, though loops aren't mentioned.
Great documentation, by the by!
It's been a while. But I believe what caused me the most headache while trying to build something like this was handling the interactions between different elements. Declaring which objects were affected by "attacks" or could be "player interactive" or "affected by player but not by NPC". Really this boiled down to proper inheritance. But I found myself so deep and tangled a fresh reset would have been better. Then determining if the object itself or an "objective manager" should perform the calculation each cycle.. etc
It was messy. I ended up having NPC, Item, Attack classes and for each a NPC Manager, Item Manager, and Attack Manager to calculate all their interactions and states.
That's why your project seems interesting because it seems to handle the heavy lifting of behaviors and "behind the scenes".