Families are overrated?

I'm trying to figure out what the real advantage of using families over single objects is. Say you have a series of collectables in your game..you could just use a single object with each frame or animation representing a different object, then have an instance variable and sub-events to tell the difference. The same goes for enemies, bosses, bullets, particles, anything.

-It's much easier to manage & quicker than using families

-Your object folders will have far less objects

-Apparently implementing & maintaining families in C2 is a lot of work

Now there's talk of family values and behaviors and such, which will take even more work, and I'm really just wondering why bother? Are families really necessary? Am I missing something here?

download and study my code of SandBOX (on my signature) and see the advantages of this great feature. =)

For a example, you could do the detection of all the walls with 10 events, but I did just one event using families.

You can make 100 type of enemies with his own behaviors and AIs, and place them inside a families, improving his behavior with even more information.

We can't live without families anymore, because this is part of a very smart type of eventing, helping you organize codes and saving your time with similar events for different objects and purposes.

How i envisioned families working was that you could create a complex behaviour system for an enemy. Once done you can just clone that enemy and he would act independantly of the first, but with the same logic. Is that how it is going to work?

Even in its early stage though it has enabled me to continue working on a complex tower defence style of game (after i finish this platformer of course!). With multiple enemies it was hard to always make them shoot at the closest target without long and complex targeting code, but now when i stick all the different enemies under the Enemy family i can easily code to aim at the nearest Enemy.

(probably could have already done this another way but it makes it easier!) :)

I agree with telles0808. even though it's possible to do as you said with single objects, but what about objects with animations? that would definitely be very annoying without families. or if you wanted totally different logic for each enemy, or ui element.

something simple like:

On playerprojectile collides with Enemy -

-----subtract (playerprojectile.strength-Enemy.defense) from variable Enemy.energy

where 'playprojectile' can be all the projectile in the game, from arrows to lasers to machine gun pellets. 'Enemy' can be everything from walking soldiers to flying birds, to turrets. If your game has 30 projectile weapons types, and 50 enemies. without families that would be quite an annoying task to copy paste those to each enemy, and unthinkable to do some sort of animation frame based family equivalent. with families it takes a few seconds.

simple functions like enabling and disabling, creation and destruction, positioning can apply across a broad range of objects. The readability improvements alone make it worth it, but it can shorten the cap length drastically, and certain tasks that would be annoying or infeasible with some other workaround are as effortless as any single object logic.

I think you're missing the point. You don't have to make multiple objects to have multiple enemies or whatever; you just need one (and sub-events).

Think of Mario. There are lots of different enemies but you only need a single object for all of them. This single object can contain every enemy animation and every behavior; all you have to do is give it a variable to tell it which ones to use. Then whatever events you apply to that single enemy object applies to every enemy. It's what I did in Bumper's Quest and it's much, much cleaner and easier than using families.

Same goes for text objects. What if you want a score counter, a life counter, a time counter, and more? You don't need to create multiple text objects to do that; you just need to give one a variable to tell it what it's representing. Blam you just saved yourself a folder for your text objects and numerous properties to set.

Families are a great edition to C2. Allthough I have not actually used them yet. It's something I will not use often But it's also something I could not imagine C2 without.

I understand that you don't need more objects, but having multiple objects is visually and conceptually useful

I this assuming 'badvulture' and 'evilsmiley' are in the 'enemy' family

every tick

--badvulture - move slow

--evil smiley - cackle maniacly

on bullet collides with enemy

--destroy enemy

i think that's how it should read, and making the events was effortless. the most elegant equivalent without families either involve some naming convention, private variable comparing, or some clever functions, or just rote memorization of animation names and such.

I don't want to have to call functions, or use naming tricks, or remember what animation and what logic goes to who. I want the event sheet to have different icons of different enemies, or the single family icon, so it's easy to see what actions apply to who without reading anything. I want enemies to be able to collide with eachother, without having to check a name or a PV and some other workaround for multi-objecttype picking. And conceptually, I want the actual eventing process to align with what's going on in my head, which is separate types that share some common functions.

it sounds like you're saying there's an advantage for not using them? is this to save memory?

I agree with telles0808. even though it's possible to do as you said with single objects, but what about objects with animations? that would definitely be very annoying without families. or if you wanted totally different logic for each enemy, or ui element.

Sub-Events!

+Enemy.value=Goomba

(subevent) Do anything a goomba would

+Enemy.value=Koopa

(subevent) Do anything a koopa would

This single enemy object could contain every behavior that could be activated/deactivated depending on what the enemy variable is. Animations could be set like

-GOOMBA_Walk

-GOOMBA_Squished

-KOOPA_Walk

-KOOPA_Squished

Then when the enemy dies? More sub-events

+Enemy dies

(subevent) If it's a koopa do this

(subevent) If it's a goomba do that

I guess it's just personal preference :\ I like that each time one of my enemy spawners creates an enemy, ALL of its properties are set right there in events. Then I could have yet another sub-event for enemy variations instead of creating a brand new enemy object and putting it in the family just for some minor differences. The same applies to bullets and everything; If the bullet variable is Plasma - give it this strength and that behavior. If the bullet variable is fire - give it this effect with this other behavior.

I find that easier and more convenient than making totally different objects and putting them in the same family, but to each his own I guess o.o

Edit: TiledBackground Objects seem to be an exception, as each one can only use a single image. So if you want them to share a common behavior you'll want to use families.

But then again you could possibly load the image externally based on a variable, and not have to use families at all ;)

on bullet collision with enemy

(subevent)Enemy.value=Goomba

------ Do anything a goomba would

(subevent)Enemy.value=Koopa

------Do anything a koopa wouldquote]

on bullet collision with koopa

------do something with koopa

on bullet collision with goomba

-do some goomba thingquote]

This single enemy object could contain every behavior that could be activated/deactivated depending on what the enemy variable is. Animations could be set like

-GOOMBA_Walk

-GOOMBA_Squished

-KOOPA_Walk

-KOOPA_Squishedquote]

enemy - play animation - enemy.value&"_Walk"quote]

enemy - play animation - "walk"quote]

Then when the enemy dies? More sub-eventsquote]

+Enemy dies

--- do something for any enemy

(subevent) If it's a koopa

   --- do this

(subevent) If it's a goomba

   --- do thatquote]

enemy dies

---do something

koopa dies

---do this

gooma dies

---do thisquote]

find that easier and more convenient than making totally different objects and putting them in the same family. Hm.. it's not like you must like families, but personally, in all the above examples, the family version seems much cleaner and readable. Also the icons make it much easier to read the event sheet as well.

edit: also to emulate multiple families on a single object would make things a little messier still

like Koopa could be in the 'enemy' family and the 'ground creature' family and the 'all character' family

What about micro missiles with AI? A big boss shooting 100x of them with 10 variations, You can waste 2 lines of code to implement what happen with every missile when they launch (a smoke can popup on his cannon) and 2 lines to setup what happen when they hit the player, instead of codding 20 lines of the same code.

Another sample, when you do moving platforms like in Mario, instead of doing 10 lines of code for each type of platform (sprite and size), put them on a Families and setup this families to be a platform.

And the last sample. Making a "Cobra" game, you'll need to setup his ammo types, draw them, put them inside a Families, write a code for that Families and only setup what is different between each other, like the amount of life that specific ammo hurt the enemy.

^^

You can setup everything one by one, but you'll agree with Ashley and the Community when you start to do many enemies and your code start to make you lost inside each repetitive codes.

To make sure the greatest of Families, you can figure out a planetary game. You setup each planet, setup his families, and them, put all the cities and spaceships, asteroids, everything you need inside families for that planet. When you kill that planet, you can setup to clear all his objects instead of clear one by one, free of risk to bug your game.

I have 24 aliments who need makes 16 different fusions and all have drag and drop. Families here are very useful.

I think my previous replies still explain what all the fuss is about for most people tokinsom, but I just now realized a possible reason why you would think it was easier not use them. when you made minitroid, and possibly other games, you had a clever level editor so it was much more convenient to have the level editor load the level, create a generic object and assign it all the values it needed right then and there. That makes sense why you'd find it a hassle in that type of situation.

lucid Well when you put it that way then yeah, it does look a bit simpler :) Still, the thought of having 20, 30,even 40 different objects that are all enemies or bullets worries me. Knowing that all of that can be compressed into a single object is comforting. Plus it keeps the object list very small. After working with MMF and CC for so long, seeing that object list pile up and having to sift through it drives me insane. Fortunately C2 has a search box there.

I think it's safe to say OUTSIDE of the event sheets using a single object is simpler. With families, if I want to change the values of each bullet or something I'd have to go to the layout editor, find that object, open it's properties, open its instance variables, then change what I want. With a single object I have every single property of every bullet type right there in the event sheet / list.

I guess I just got used to this when working on Bumper's Quest before there were families, and am having a hard time figuring out why I should go back to them.

lucid again Yeah that too :P Using a level editor and any "custom" tools I guess can change how you look at and do certain things.

Families are really more useful in complex games. You can achieve what families do in different ways, but honestly, they are so easy to use that I don't see why I would. In my opinion it cuts dev. time by many times. And that is really the whole point.

If you find yer method easier, then it's fine as well. I'm trying to make an RPG, and trust me, families are a blessing.

I would never use a single object for all entities. It goes totally against my principles as a developer. Can't explain , it just doesn't fill right. Families for me is a must. I admit that having hundreds of different types of entities can become messy. But that's a fault with the IDE like it is now. The fact that an object must be "instantiated" in a scene once to be used contributes a lot to the problem. This is driving me nuts with my current project where there's lots of objects on scene, i don't know where to drag em anymore to put the out of the way. Not only this but selecting objects is a pain right now. If you have one big object that takes the entire screen i can't select anything else. Doesn't matter the layers i want to be able to select what i want. I think there was a command for it ? Can't remember. There could be an option for every object: Selectable, Locked or something. Locked layers is not enough.