Can I make universal instance variables?

0 favourites
  • 11 posts
From the Asset Store
Easily store, modify, read and manipulate colors with Color Variables!
  • I keep running into problems where I need multiple families to know about the same information.

    For instance, I have sprite objects for NPCs and for Cats, which both need to know their own names and types for drawing animations, and their names for talking to them. This is held in my "talkables" family's instance variables. However, I also need to know the Cat's name when you pick it up and carry it around, which is information held in the "carryables" family's instance variables. Right now I'm just setting carryable.name to match talkable.name, which works fine (though it's a bit ugly in code.)

    I just ran into another problem where objects need to model wetness, but I'm looking at lots of families (platforms, groundPlants, animals, etc) that all need to store wetness. I'm just curious if there's some way to set universal object variables that families and object types would always be able to refer to in expressions?

  • If I was doing this, the npc and the object you are carrying wouldn't be related. NPC go in the npc family and object you are carrying is a different object entirely. i.e. you don't carry the object you are also talking to. If the name is really that important then you can do it the way you described, store npc.name and then set cats.name to that value, but something like name shouldn't be too important I think ? you can even use the object type's name.

    For the second part why do those families all use wetness ? or how ?

  • Thanks but I was not looking for help about the cats and NPCs. It needs to know the cat's and NPC's names for drawing the correct cat or NPC, and for talking to them. Cats are both carryable and talkable; they're in both families. Object type name does not work for my purpose at all.

    They all use wetness for different things; animation, particles, figuring out the platform's surface type (for playing sound effects and affecting movement physics), behaviors related to freezing/burning, etc. I can give every family wetness but it gets annoying if something is in two families because they need different names. I'm only asking if there's a way to add instance variables to for instance every sprite, which the engine will know every sprite can have (similar to how every sprite has a sprite.X, sprite.Y, etc.) and so can be referred to under any family. I already have a workaround, but I'm just checking if I can avoid working around it.

  • If a Sprite belongs to FamilyA and FamilyB, then only actions on Sprite can access instance variables inherited from FamilyA and FamilyB. There is no way for an action on FamilyA to access instance variables from FamilyB - nor is it clear how such a feature would work - what if a member of FamilyA does not belong to FamilyB but you run an action on it accessing a FamilyB instance variable? I think for this type of thing you just have to work within the system.

  • Alright, I'll take that as a no and keep doing the workaround. Though to be clear I wasn't asking why families can't refer to other families variables--I didn't think they could (or should) do this. I was asking if I could put a variable on say every single sprite object type so they could universally be referred to (again, the same way that sprites all have sprite.X, and a family of sprites can refer to it as familyName.X in conditions/actions/expressions--an individual object can have its X set by referring to its object or any family it's a part of, and every family can freely use its X to make conditions) or if there was some other way to do it maybe. Thanks!

  • No, you cannot make truly universal instance variables in object-oriented programming. Instance variables are specific to each instance (object) of a class, meaning that each object will have its own copy of those variables. If you want a variable to be shared across all instances of a class, you would need to use class variables instead.

    Class variables are shared by all instances of the class, meaning any changes made to the class variable will affect all objects of that class. However, instance variables remain unique to each instance, and their values are not shared between objects.

    So, while you can share data across instances with class variables, instance variables are inherently tied to individual objects.

  • The previous post refers to "class variables". These do not exist in Construct. This kind of thing is typical with AI-generated posts - they tend to produce content that sounds plausible but is actually wrong and misleading and pollutes the forum with incorrect information. Please see our Forum & Community guidelines which say this, and note further such posts may result in a ban:

    Please don't use AI, such as ChatGPT, to generate content. It often produces text that sounds plausible, but is actually misleading, incorrect, or otherwise unhelpful. This causes confusion and ends up wasting people's time and making it harder for people to get help. It can also put pressure on more experienced users to have to step in and provide a correction, as it's important to ensure the forum is a useful source of information. So please only write posts that you personally know to be true and don't rely on AI to generate responses for you.

  • I was asking if I could put a variable on say every single sprite object type so they could universally be referred to

    Wouldn't a family of all sprites in the project do this then?

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • There have been multiple suggestions about family inheritance over the years (like this one: https://github.com/Scirra/Construct-feature-requests/issues/1) but AFAIK Scirra is not interested in pursuing this design and wants to enforce a more component based architecture. But this is also difficult to do with events as it's not easy to traverse families, for that I made this suggestion: https://github.com/Scirra/Construct-feature-requests/issues/7

    I feel like either of these additions could make your intended system easier to implement

    An additional feature that could make families more flexible, but not directly connected to this issue, is having a type that is based on worlObject instead of plugin type, suggested here: https://github.com/Scirra/Construct-feature-requests/issues/383

  • I was asking if I could put a variable on say every single sprite object type so they could universally be referred to

    This is kind of what a Family achieves though. You shouldn't really need to go cross family if the events are good, since Family is really just a pickable object type. If for example you want to store a plant family wet value and then relate it to a platform family then you can store plant.wet in a local var during the event and then use it when you pick the platform family etc.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)