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