Real hierarchy data in objects

Why there is no hierarchy in construct2? It exist in almost every game engine i had being (starting in DIV GameStudio, father of game engines...).

i mean, Why i can't point to my son? If i spawn an object, whatever it is (even if it is not in my "family" or "container") it becomes my son, so i should be able to point it. I know, i can do this by creating an instance variable and give to each spawned object the same "variable", but it doesn't work backwards, since maybe, i want my son to point to father or his father (his grandfather) that shouldn't have the same variable.

[quote:1rh8dw6c]

In variables, is like creating a new empty array attached to every object, that array will save only the ID of their sons and each son will save his father and his own sons. Now if i want to know who's my brother, i go to my fathers array and check for his sons, also i can know who's my uncle by going to my fathers father and check his sons, etc...

Family hierarchy is important for strategy games and also improves coding and memory a lot. Is good to create smart IAs or beautiful fractal effects (like the rain of variety of bullets and ships in a space shooting game).

The main magnificent reason is that i will be able to make one object spawn his same object or thousand diferent objects, and will be easy to diference between who's spawining who, also it's easy to diference between colliding with my father or brothers if they spawn at the same tick.

Let's think an example: Ogre spawn 5 ogres, those ogres spawn 2 ogres, and i don't want the grandsons to be further than X distance from his grandfather, but i want their fathers to be more free, also the grandfathers will move to his sons. At the same time, the 5 grandfathers are not related so they will fight each other but will not harm their own family and will not damage grandsons of anybody, but the grandsons may hurt their own brothers but not their fathers.

Now this could be easly implemented with only 1 Object called Ogre, and a few lines of code if there is that hierarchy.

Other example: i have 10 different bullets, i spawn 10 bullets of the same type, but i want those bullets to be destroy by bullets if they collide, so if i only check if i collide with bullets that are not my brothers (regardless what object it is, so i can spawn endless different objects that are bullets and avoid their self destruction). Also those bullets will be able to diference between my father and grandfather (for example a ship that shots a bullet that is diveded in more bullets and those bullets creating explosions, so that explosion can damage his own grandfather, but not his father or brothers)

maybe with this title is easier to understand

Hm. Could you not just give the objects a tier variable as well as the UID of it's father?

Tier 0 (Grandfather) spawns 1 (Father) which spawns 2 (Son) and so on, sharing a UID or another identifying variable for reference.

You'd find the grandfather by comparing an object's own UID to another and subtracting 2 tiers, father by subtracting 1, child by adding 1, and so on.

Grandfather

Tier = 0

UID = 111

Father

Tier = 1

UID = 111

Son

Tier = 2

UID = 111

Or..y'know, something like that. You could maybe build a string or array storing the UID's of all of an object's parents too.

i can understand the question, but it's pretty hard to translate

OOP principles like inheritance, polymorphism and such to events and C2 engine, because that implies some heavy object handling and i think javascript is not really a fully OOP language (correct me if wrong), though i'd love to see some more combinations and control over families and objects. some optimizations might be achieved, and hopefully they will, but it takes a lot of testing and playing around with..

You might take a look at other ways of picking, and new ways of filtering using the system "for each" or the picking conditions "pick by evaluate" etc.

Remembering that picking smaller groups, then filtering to even smaller saves system resources.

You might take a look at other ways of picking, and new ways of filtering using the system "for each" or the picking conditions "pick by evaluate" etc.

Remembering that picking smaller groups, then filtering to even smaller saves system resources.

That's exactly the problem, all the "pick" options consider variables or conditions, but no one considers "where do i come from?" and in each collision with objects of the same type "are you related to me?".

Hm. Could you not just give the objects a tier variable as well as the UID of it's father?

A simple way if i could control UID.

saiyadjin actually Java supports something like that but for classes, here the idea is to keep that track for objects and no, it's not hard, like the solution of tokinsom or using the array of spawn and creation (actually you can create that now in construct2 by hand using arrays, but it should be integrated since it have a thousand uses)

java, c#, c++ and so on... i know. i'm working everyday with c#, and no you are wrong, it's pretty hard to create inheritance in current event system, actually impossible.

or multiple inheritances.. and so on..

The pick conditions will work for any behavior expression as well.

I'd be willing to bet rex has more than one that would work already, or you could make or have one made.

The hard part is knowing how picking works, and how/ when you would label objects.

Edit:

Actually all you would really need to do is put a data type plug into a container with the objects you are creating.

You would then have to fill in the blanks at creation.

xml would work nice, Yanns json might do as well.

You have to define everything you want to do to start.

You can't just start with "whos yer daddy".

java, c#, c++ and so on... i know. i'm working everyday with c#, and no you are wrong, it's pretty hard to create inheritance in current event system, actually impossible.

or multiple inheritances.. and so on..

I said it was like inheritance of classes, but this are not classes, this are objects. Objects store local variables, this is just an other local variable (like x,y,angle, UID, father) it's not necesary to store sons, but to know who is my father is quite important, the rest can be done in code. It's like having a growing container...

i mean, they already did a lot of stuff simil inheritance: iid, Spawn vs create are different, container, family, wrap, group... but why is not able to store who's spawning? to know if they are really my family or to avoid overlapping when spawned from the same source (imagine a building game, it's important to know if a brick is placed by the player, the IA or if it was created by system or self spawned (reproduction like cells))

You can do what you want with a instance variable "parent" that you'd set the the parent's uid.

The tediousness would be the picking other instances of the same type. The two way is either a family or storing values from another instance to variables. Functions would also be useful here to make the events more readable.

For example if your object types look like this:

sprite: ogre

family: otherOgre

variable: parent=-1

Then your events could look like this:

// this creates the hierarchy
//  Ogre spawn 5 ogres, those ogres spawn 2 ogres

Start of layout
repeat 5 times
for each ogre

R0J0hound Ashley words:

"IIDs and UIDs in the editor don't change depending on the Z order, but they do change if you delete and insert instances. Because of this you should not rely on knowing UIDs or IIDs in advance at all - the instance with UID 3, for example, could change to a different object if you add or delete some things in the layout view. This could easily break your game or make it work differently "randomly" (it will seem random to many users because they won't realise certain things they did changed the UIDs and IIDs). For this reason I don't think UIDs or IIDs should ever be displayed in the editor, in order to discourage this bad practice."

A real parenthood will never change, doesn't matter how many instances you destroy or create.

They don't change at runtime, until they are destroyed.

Also the z order part has also changed for the editor.

That's a pretty old quote. The fact that ids can now be seen in the editor tells you that.

kingpirux

What newt said. I was using the uids at runtime, where they never change. Setting up the hierarchy from the editor is a different issue, but still can be done with an instance variable to give each instance a unique value. Just be careful not to give two instances the same value.

perfect! if the uid is locked, then it's easier to create the herarchy, as i said, it's an array storing all the uids of the family, father, and sons (or just fathers) and being reach by "object.father" or "object.isfamily" to know if its a son of my father or my grandfather, other one "object.uncle" to reach an object that was created by an object created by my father (for example, attacks of friendly npc's)

Ok just to be 101% sure, the UID stays the same throughout the life of an object? I've been assuming "Yes" for quite a while :-\</p>