To be honest, nobody uses the ‘name’ property in objects because it’s not even a useful feature, and I think this idea will make it better.
My idea is to replace the ‘name’ with a ‘tag’ property. The tag doesn’t have to be unique so multiple objects of the same type can have the same tag. Of course nothing restricts you to make them all unique, because this would be useful for extractors. We’ll also get a new behavior block to check the tag called ‘Tag check’. For example the tag is ‘hello’ and check if the tag is ‘bye’ it’ll output false.
Well, how would this be useful? Imagine you have a ‘weak enemy’ and ‘strong enemy’ object. They both behave the same, same movement, same animations etc. but the only difference is that the strong enemy has more health than the weak enemy. If you want to modify something in weak enemy you would have to do the same in the strong enemy which is lots of boring work. If we use tags we would only use one object called ‘enemy’, one with the tag ‘weak’ and one with ‘strong’. Now you connect an once to a tag check and check if the tag is ‘weak’. If it outputs true it’s a weak enemy, if it outputs false it’s a strong one.
Another useful thing would be spawning/emitting/attaching objects with a tag, and in the message block we would get a new option called ‘send to tag: ___’.
@grazer If you implement this, the ‘send to attachments’ option for messages doesn’t have to be added anymore.
Also some other small suggestions I’ve always wanted:
* Hue/saturation/brightness behavior block
Has 3 inputs to change the sprite’s appearance
* Mass physic property
When is it coming?
* Behavior block to hide/show cursor
custom cursor + cursor from OS = no good combination
* cUsToM cOlLidEr shApES
we nEed thIs
* Option to disable snap-to-grid in level editor and allow us to make objects with any size. Also the ability to make our own grid (cell size and offset from origin in pixels).
Why is this still not a thing? I want 24x24px sprites not 32x32px.
Hey @Latif3 - I actually started designing a tag /group system a while back. Instead of implementing tags though, I ended up adding object families / inheritance, which should be more flexible, and which I thought would be more generally useful & time-saving.
For your example - couldn’t you create an “enemy” object parent, with “strong” and “weak” children? I’m not saying that tags are a bad idea, but I’m curious to hear if there are obvious cases where tags would be a big improvement over using parent/child relationships.
Your point about Type vs Name being non-obvious to newcomers is well taken. I went back and forth on what to call those properties for a long time, and I’ve never been 100% happy with them. It might make sense to change the names to your suggestion, but I’d need to think through the implications of having the name/tag property be optional and non-unique. There are lots of places now that assume they are always available and unique.
In any case, thanks for bringing this up for discussion.
@grazer The difference is if I use object families for the enemies I would still have to duplicate the health and death logic in both children objects (weak and strong). Using tags would be better in this case, since you only have to increase a number, the health value, when the tag is ‘strong’.
Maybe this example makes more sense, in my 1v1 game (offline, not the online multiplayer one) there are two players and they have lots of duplicated logic. Player 1 shoots blue projectiles, player 2 shoots red ones. Player 1 is controlled with arrow keys, player 2 with WASD. The animations are also the same, that’s why I want the hue thing so I can simply make a blue character and make it red if it’s player 2, so I never have to make the animations twice.
I just really can’t use object families for this because they don’t use the same logic, they have similar logic.