It would, but the other families the sprites are in couldn't refer to them (and I agree shouldn't be able to, that would be weird.)--platforms is a family that responds to wetness by changing its surface type variables, plants would want wetness to know they've been watered. Each object type could individually respond to the variables, but I already have like *checks stats* 1700 events so I'm trying to keep my code from getting too complex... or uh, trying to keep my code relatively lean anyway. Like platforms would be alright, but I'm expecting to have 3 dozen kinds of plants, probably similar amounts of animals, fungi, enemies, etc.
I think what would best serve my purposes is like hierarchies of families, and then I could put every sprite that's like "in the world" under one family that would hold wetness, and then plants and talkables would be a subfamily of that, and carryables a subfamily of talkables (and groundPlants and treePlants subfamilies of plants, which would help with another similar problem, etc). I imagine that would be a significant rework of construct's code base, though? And I mean, if I'm the only one who would ever use it, I'm happy to do my workaround--it's not that annoying (though it's a bit confusing in some instances--like in the aforementioned thing with the cats, sometimes the carryable needs to inherit the type from the talkable's name, and sometimes the talkable needs to inherit the name from the carryable's type. i've already resolved this one, it's just an example)--I was just wondering.
No, you cannot make truly universal instance variables in object-oriented programming.
ok i got kinda heated at this one i won't lie, but seeing it could be ai generated cooled me off.