Families are overrated?

I use tokinsom's method as well for some of my stuff. It all comes down to preference really. In C-Classic families are a pain in the ass (you can't delete variables once you add them..) so this method is more reliable sometimes. Plus, with this method, it makes it really easy to swap objects on the fly, and can actually reduce code in specific situations.

You're not required to use any particular features, you can do what you like! You can make multiple objects in one Sprite but my personal preferences is Families is more convenient. It's mainly for more philosophical reasons:

• It's more object-oriented to have each object as a separate object, rather than one object representing many objects. Families represent a base class and its members are derived types, as per OOP.
• It's less events, since you can use families as one object anyway, without conditions checking what kind of object it really is. If you need events specific to one object type, you just make them normally as well.
• I just think it's more intuitive the families way.
• Things like animations can be easier to set up with families.
• Adding a new object type to an existing family should be more straightforward with the families system, since you can just add it and it inherits all its functionality. No need for more subevents or animation events.
• I don't think there's anything wrong with having lots of object types - the folder system allows you to stay well-organised and we hope to add the folder view to the event sheet dialogs in future too.

Still, you can do it either way, it's a personal preference.

we hope to add the folder view to the event sheet dialogs in future too.

Been waiting for that since CC ;)

and in some spare time you could add "Show in editor" (like in CC), not every object needs to be visible in Event sheets. :)

also things like that are easier to do with families

closeDetection.capx

With family you can more easily filter 2 instances of the same object type and always know in expression which is which.

You filter the first one with the objecttype name, the other one with the family name and you can do complicated operation between them.

Without family it's still possible but you would have to do that in more convoluted ways.

That's a good point Yann, using families as a second independent object-picking list is probably the best unintended feature of families!

Also during dev, it happens that you make 2 really different objects.

That never shares any kind of behavior or aren't close enough to justify any blending.

But one day you discover that you begin to copy paste many identical stuff. Like if you want to destroy a bunch of sprite on game over or because of a brand new feature you just added that spawn a nuclear warhead that destroy everything within a certain range (decor tiles, enemy and pickup sprites) here family come really handy. You just have to create a 'destroyable' family and test for distance or invisible radius sprite overlap.

The other possible thing you could do is a pokemon kind of game.

yes you could have all pokemon animation in only one object.

But having dedicated sprite for each pokemon allows you to do something interesting : setting default parameters and some list of attack ID in variables during edit time.

And then just drive all your pokemon with the family system.

That's very powerfull, 'cause the work around without family would be to put all the pokemon in one pokebal... erm 'pokemon' sprite :D

And then have a CSV string for default properties of each pokemon.

Pretty painfull to maintain. You'll have to keep track of which line match which pokemon.

Ashely

Anyway, I might be wrong, but there's still on thing in this design that work better with one sprite instead of family: a random creation system.

It would be intersting to be able to do a

System: create pokemon[floor(random(pokemon.ObjecttypCount))]

to spawn random pokemon in the overworld.

Well you could have just a little sprite with all the pokemon for the overworld display and do a set frame to random(animationframecount)

But then you'll still have to be able to call a specific objecttype within the family.

So yeah objecttype index and object creation using expression could be a plus.

Edit: Just saw that Creating family creates a random object from the family. But still, having an index could be interesting for weighted randomness or if we want to match some stuff to the order of the objecttype in the family (like a 'thumbnail' family would relate to a 'photo' family by the order of their member)

I just got my license and was excited about implementing families. Seems good for a lot of things, but I was kind of thinking about them like a class. I might be wrong about that though...

I have a character that can pick up objects, so I put all the pickup objects in an "objects" family. Then instead of having a separate function for each object I created a generic function for "pickupObject". Woot! The problem I'm having is that it doesn't seem like you can reference your particular instance once you discover it. I want to pickup when I'm overlapping an object, but I don't want to pin all the objects in the layout to the player at the same time.

Is there a way to get Objects.name or this.Object or something so I can pin just the object I'm overlapping with? I can't find anything like this...

I'm pretty sure instance picking with families should work differently to what you are stating - could you share a capx so we can see your issue?

GabeOfThrones

You can pass the object's UID to the function and use that to pick it.

<img src="https://dl.dropbox.com/u/8367729/construct/pics/pickupFamily.png" border="0" />

Ramones! Thanks! UID was what I was looking for!