Or a signal that you’d rather not support the worst way to introduce type systems to frontend dev. While I’m not sure that applies to DHH, I am sure there are other devs that understand compromising all your goals to codepend on Node or even JS itself isn’t that much of a win and rather see support for better options.

Thanks!

Thanks.

Is this to rpm-based distros what Mint is to deb-based distros?

Now, you’re paying for the product, and you continue to be the product.

So this is what “neofeudalism” boils down to?

assuming you’re meaning that the interpreter is called ad-hoc basically and isn’t the entirety of the system.

That was my assumption. Basically, that interpreter would have to run small snippets here and there typically on an irregular base. Thanks for reminding, I should probably clarify that as well.

If your interpreter can execute the systems in parallel,

Well, the way I thought of it was that the interpreter gets called in the systems in the first place, so that might become a problem.

Maybe I’m misunderstanding what the system is, is click_handler in the post a system, and if so, do systems only declare a single component of an entity as their input?

The way I figured would make sense was that, in the engine/game itself, the BoundaryComponent would have an additional field for registered scripts or that there would be an additional component just for registered scripts, to keep components lean. Not sure if that actually worked out in reality.

Then there would be a system for clicking on boundaries that would call such a script, if available. It’s probably a poor example, but since that system doesn’t touch much else, only the boundary component gets passed into the script. That’s not supposed to be a rule, though. I probably should clarify that on the post later on…

Makes sense, I guess. I really can’t comment on the wider implications with an ECS, though.

this case, would the components be combined into a list? Basically you’d have a BubbleComponent[] attached to the entity instead of just a BubbleComponent?

Yes.

I like the ideas presented in the article otherwise. I vaguely remember TypeScript having some sort of reflection support that Angular took advantage of or something. I wonder if that can be used to create a scriptable ECS like proposed in this article?

I don’t know, I’ve seen some outdated version of Angular only for a couple of hours in my job now. But I’m sure, those sweet layers of metaprogramming and DI will be a bliss to debug. Not.

The next example which seems to create two bubbles on the same entity is just as confusing to me. If I were to query for those bubbles, would I iterate over each of those bubbles in separate iterations, but all other components that are part of this query are the same?

No that would be crazy.

No, but seriously, the find operator is supposed to take only one type and not merge the types. ECS seems close enough to relational databases, but not that close.

Does this mean that each entity can have any number of components of a particular type in this implementation?

Yes. I vaguely remembered that some ECS can apparently do that. If not, you’d probably settle for a branch or an optional type instead.

Would each component also need its own ID to distinguish between two components of one type on the same entity?

I don’t see why, unless you’re planning to query and manipulate them later again.

Another option here is that instead of creating a BubbleComponent that’s part of the same entity as the BoundaryComponent, it might make more sense to create a new entity that’s at the same position as the BoundaryComponent’s entity, possibly using some kind of relative transformation to keep the bubble at the same position as the boundary.

The boundary is supposed to BE the position. So some rendering system would have rendered the speech bubble in the middle of the boundary. Maybe I should have called the boundary area instead…

This one I’m curious about. How common is the case when you need to operate with the entity directly, and is it worth the cost of duplicating the entity ID onto each component? In bevy’s case, you can query for the entity ID like you would a component using Entity, which I’ve found to be easy enough to do.

Maybe I worded that poorly. I’m also still not entirely sure about the terminology. This was exactly supposed to be an implementation detail.

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.

install minor cc update

compiler exploits undefined behavior as it always was technically allowed to

Checkmate, Cniles!

All those unit test that the devs didn’t bother to test on other platforms.

By visual, you mean node-based?