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.

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.

There is a typo I have made before:

Make sure the variable of the function name is NOT in quotes, or else the system will make the decision ""name""=/="name"

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.

If the issue with TCP is one side falling behind over time, would this work:

Assume a multiplayer game with Player A and Player B

Set up the game so that every frame, each player will attempt to read a packet. However, each player will only send a packet every three frames. This way, whenever there is any latency, either side will catch up. It would not be the smoothest, but it would allow for an up to date communication while the client would fill in the gaps.