Just try, what is the worst that could happen? Hehe-- [sound of breaking bones and rupturing organs]
Just try, what is the worst that could happen? Hehe-- [sound of breaking bones and rupturing organs]
On second though, it doesn’t seem like a big improvement. Reminds me a bit of limbfeeders without limbs.
This, it would be less deep in the uncanny valley without eyes at all.
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.
Requested: A clown version of the Critters-posting-on-4chan meme, with a horn on the desk and a red nose put around the screen.
Good bot. In fact, this might be the only bot that’s actually useful. Until we get spelling a bot for a-and-e mistakes.
The way it works is if you place 2$ you get the chocolate flavored condoms, but if you instead put 2$ then you get the Asian condoms.
✅
[answer accepted]
Makes sense. At first I thought you have to turn your coin around.
Hmm, there are four kinds of merch but three knobs. How?
Sure seems that way. Now try chili.
Now all you need is a good list of “shorts”. Urban dict seems to have outgrown that purpose. Ideas?
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.
That guys’ as well.