Suggestion: Improving Families and Inheritance

Construct 2 is great: it has an extremely intuitive syntax which allows you to develop games almost as fast as you can think of them. However, I think there is one place where it can improve: Families.

In design, we try to kill multiple birds with one stone. We do not want to write functionality we have already written. Families tend to take care of this. We can take anything to which we want to give that functionality, and simply drag it into a family. This works for small projects, where you might have one or two players, and a few types of enemies/ terrains etc.

However, on bigger projects, when good object oriented/modular design is extremely important to save time later on, issues arise in Construct 2:

First: Families can only have generation. Let us say that I make a family for talking NPCs. I write very basic, open ended functionality for talking. It covers the structural work of putting up the speech bubble, etc, but it is still up to the children to decide how. And so, I decide to make two more specific families: ordered talkers, that say a set of phrases in order, and random talkers, that say phrases in a random order. I then make several different NPCs that use each family.

Unfortunately, Construct doesn't let me do this. If I wanted to make OrderedTalkers and RandomTalkers, I would have to choose between making two independent families and rewriting the basic talking functionality for both, or rewriting the specific functionality for every single object I make. This could get encumbersome if you wanted to make a game with hundreds of NPCs that talk in slightly different ways.

The solution is simple: Allow sub families: Families whose children MUST be a part of a grand-parent family, and therefore have all the functionality of the grand-parent family.

Second: There is no absolute "Object" Object. Say I wanted to make a game with destructible enemies and environment. I write a family for anything that has HP and can be destroyed. There is a problem though. For walls I use tiled backgrounds. For enemies I use sprites. The destructible family only really needs the "destroy" action and collision condition. Both tiled backgrounds and sprites have those, so why should I have to rewrite the destruction functionality for both types? Shouldn't there be abstract "Collider" and "Destroyable" interfaces which sprites and tiled backgrounds implement?

Solution: Make more general single purpose object types which types like "Sprite", "Tiled Background", "Array", and "Nine Patch" extend so that programmers can cast different objects into one type when handling common functionality.

Third: If all else fails, perhaps just allow us to manually cast objects in events, and it is our responsibility to make sure objects don't get miscast.

Will this affect every game developed? No, but Construct does say that it is meant to be a viable tool for professional developers, and I think that adding something like this would be a large step towards that goal. I also don't think it would complicate things for casual developers, and it could be achieved in the code free approach.

For the first issue, use family variables. That ensures all objects in the family have that variable, and you can set it to 'ordered' or 'random' and check it via a condition to set how they talk, leaving it so you only have to have one batch of code that works with the family rather than specific objects, and removes the need for secondary families.

That would work for my example. However, if the differences were more complex, or my individual subsets needed their own instance variables, I would have to store every one of them in the single family. In addition, if I use that String technique, I would become dependent on that conditional. If I needed to overhaul the structure for the main family's events, I would need to remake a long conditional.

However, if it would be too difficult to change anything I suggested, another suggestion could be a cut/copy/paste feature for events, so that when situations come where re-factoring is unavoidable, no events have to be re-written.

You can already cut/copy/paste events.

Holding down ctrl key and drag droping an event will copy/paste it.

And for cut you can right click the event and select "Cut".

Also are you familiar with the Function plugin and picking ?

For everything you've described, I think Functions would be of great help to you.

I use functions and picking, and it does help. Sorry for missing the event copying and pasting, I thought I tried to once, but I guess I was wrong. I know it all can be done procedural, but I just thought it would be more intuitive if it were more family oriented. Thank you for your input though.

There is a plugin called nickname, which seems to allow you to assign object types to families "on the fly" at runtime.

dl.dropboxusercontent.com/u/5779181/C2Repo/rex_nickname.html

Perhaps this can give you some extra flexibility you need.

I also support the idea of adding family inheritance.

Sure, you can keep adding variables, conditions and copy/paste code in order to replace inheritance, but inheritance would be a lot more convenient.

Families exist only as a convenient tool. Why not making them even more convenient ???

I agree with Mathew overall for sub famillies, but more importantly I would open families. Where I can mix sprites, TileBG, 9Patch. I want this desperatly because I tried to make a UI with a common behaviour of such example

OnEnter

OnExit

OnClick

OnRelease

Params

......

unfortunatlly because I have Sprite for Buttons and other graphical widgets and have 9Patch for the panels because obviosly using 9patch border and internal scaling makes sense. This has led to two different objects that cannot share the same event code.

So there is a very good reason to have mutual object families. Also as a complain I would like TextObject and SpriteFont to have a collision object. That way I can compare if these objects are over my panel(9patch) so I can auto pin to the overlapping panel... which again leads to the silly thing that I need to numerous families with Pin and extra actions and events conditions to do this.

Also yes we can use variables, but since building and SOL requires itteration through the Object/Family in question. Large object lists that can be the result of large projects as the OP is posting in theory will result in longer SOL building times. Where as if Families could have sub Families could allow for faster SOL building; especially for EveryTick situations.

Family Inheretence and Open Families are just over all good OOP design. Actually it's very common for other OOP languges to support such design as

class goo{

public function(){ do stuff };

}

class foo extends goo{

public function(){do foo stuff};

}

class doo extends goo{

public function(){ youknow what};

}

class bada extends foo{

public function(){ yeah}

since this extends foo it also get's the featues of goo

}

this is common in good OOP design. Something that C2 doesnt' let us do. Working around situation doesn't make the work around good. Heck anyone remember the days before Function?

edit:

I also requested this many months ago and got the reply from Ashley that I could just use variables

C2 already basically has 'sub families' - you can just put an object in multiple families.

One object in multiple families makes the project easily very confusing. I also really need inheritance in my project. Of course it's working somehow right now, but I'm really unhappy with the current structure.