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.
> 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
Is the ID computed based on the shape of the expression at runtime or on something else?
The implicit ID is just an auto-incremented number actually, it's not anything too special. That means, if you have a loop, the component has the same ID each time and gets replaced. That is a feature, not a bug. So this code snippet will keep replacing the text sprite with a new one, counting from 1 to 10:
for i in RangeInclusive(1, 10) {
TextSprite(i)
}
Yes, you found the right place in the documentation. Thanks, yes I worked very hard on the documentation!
Ah, so you don't do parallel with implicit IDs right now, I'm guessing. Or you do, but it has some interesting bugs as the IDs shift around? Or the scope of the auto-incrementing number is lower than "the entire program" so parallel works?
It sounds like you are asking, if auto-incrementing IDs are assigned in parallel at runtime, then order of execution of the threads must affect which ID gets assigned to what, and that must make some interesting bugs?
The IDs are assigned at compile time by the Easel compiler. So they don’t change in any way at runtime. Does that answer your question?
Actually, all iterations of the for loop have the same ID. This is the design. So the second iteration has the same ID as the first iteration, which means it replaces the sprite created by the first. The fifth iteration has the same ID as the fourth iteration, so it replaces the sprite. So all the iterations keep replacing the same sprite. And that is how you animate sprites!
If you are actually trying to make multiple sprites and not keep replacing them, what you do is you spawn a new entity to hold your extra sprite:
for i in Range(0,10) {
Subspawn {
TextSprite(i)
}
}
That code creates 10 sprites and achieves what I think you are thinking of.
