I'm writing a custom platform engine for my game, and I had a question about 'pushing out' an object from another object. In simple terms, say Mario is falling and he overlaps a platform. We now need to perform a 'push out' loop where we slowly move Mario up until he no longer overlaps and is 'flush' with the platform.

C2 uses sub-pixel precision, so pushing out an object pixel by pixel will yield inconsistent results visually i.e sometimes Mario will be a pixel too high. I've found that pushing out an object at less than a pixel per iteration is more stable, but no matter how small I go (even at 0.01 px/iteration), Mario is still vibrating ever so slightly, giving a blurred look.

Something seems fundamentally wrong with my approach. What's the best way to implement a 'push-out' so that by the end of it 'Mario' is no longer overlapping the obstacle and he is flush with it?

Yeah, I can see that. Without looking at the code, I always got the sense that Families were a little restrictive in how they were set up behind the scenes, judging from the interface where you add/remove objects.

Perhaps what is needed is a new feature entirely separate from Families that focuses on inheritance rather than merely being able to reference several objects at once.

I'm visualizing something like a Parents property that can be set in the editor. When you click on it you can choose a sprite (or applicable object) to inherit from, and just like that all variables and behaviors are inherited.

That would be a really advanced feature that I'm sure is hard to implement, but some kind of advanced inheritance system in Construct 2 would be extremely useful. I hope Ashley can consider it for a future release.

Ah, good idea. I will probably use a function in my case because I'm going to have a lot going on. Thanks!

What would be the difference between sub families and simply putting an object into multiple families as can already be done?

The main difference is that a sub-family would inherit the variables of its parent family, whereas two separate families would have no connection to one another.

Say we have a family called Bullet that moves left and right at a set velocity and kills stuff. Then we have a sub-family called ChaserBullet that changes its velocity in order to chase someone. ChaserBullet can now access the parent family's velocity variables in order to modify them.

Why wouldn't the approach of multiple families work? Because then, ChaserBullet cannot handle the logic for its child objects. There will be duplicated logic for each child, which defeats the purpose of the ChaserBullet family. Only the children will have access to all variables.

I assumed Sub-Families existed until today (Families are treated like objects in almost every other way). I needed them and they weren't there, so I had to come up with a work-around, which did the trick although it makes the logic a little more convoluted and isn't as clean when assigning families. You basically have to make sure that anything that is ChildFamily is also ParentFamily.

Someone asked about this a little while ago and Ashley more or less said it's not happening.

Oh! I missed it when I searched. Could you point me to the thread? Thanks!

It seems like the next logical step for families is to support sub-families. Families are already treated like normal objects in any every other aspect. In a relatively complex game such as the one I'm currently making, multiple levels of inheritance would be really handy.

What's the demand like for this feature? Are there plans to support it in the future?

C2 doesn't do sub-families (yet), so I'm using an approach where I assign the effective parent family to every effective child family.

If I'm working with an instance of the ChildFamily, how can I pick it as the ParentFamily? For example, I'd like to do the equivalent of this:

ChildFamily collides with Bouncer:
+ Pick ChildFamily as ParentFamily:
     -> Set ParentFamily.VelocityX to -50

ChildFamily collides with Bouncer:
+ For each ChildFamily
  + ParentFamily: Pick Instance with UID ChildFamily.UID
    -> Set ParentFamily.VelocityX to -50

This is a great example. Thanks man! This answers my original question.

Constant instance variables (or 'instance constants'? :p) would be terrific in their own right. Even so, I think traditional 'Enums', for me, excel at 2 important things that make them especially worthwhile compared to other approaches:

1. Forcing a single choice. An enemy can't hide and attack at the same time. In code, instead of having to specify a priority order, one could simply select 'State.HIDE' from the list and call it good - super clear and less prone to buggy logic - like using a Boolean instead of isTrue and isFalse vars (hopefully no one has ever done that). Plus, the idea of a neat little drop-down in the C2 user interface when testing against an Enum really excites me.

2. Less prone to typos. True that Javascript enums are just strings, but I guess there's also the possibility of using the Object.freeze method to seal a property into an effective Enum, eliminating the typo issue. I feel like in many cases in JS games, this would be more desirable than using dynamic JS enums. Likewise, in C2 having an Enum in many cases would be preferred to using strings or constants.

All in all, I think Enums would be an awesome addition to have down the line, but I see why this wouldn't be an immediate priority because there are a handful of alternate approaches.

Let's say you had an instance variable called state that can represent three states: HIDING, CHASING, or ATTACKING. Without Enums, the best approach is to use a Number for this variable, and then declare global constants in the following manner: HIDING = 0, CHASING = 1, ATTACKING = 2. Now you can use these constants in your code with full control over them in case things were to change.

That works fine for one object, but now consider you have 15 different objects with different state values. That's a lot of global constants and can make things very unclear in the code. This issue could be eliminated if we had an Enum instance variable type. With an Enum, every state would be self-contained and it could be easily referenced in the code.

Is this planned for a future release? If not, why not? Instance Enums would be handy ex. intelligent enemies (hiding, chasing...), characteristics (sharp, smooth), etc.

I put a hold on the project I was working on at that time, so I never really got around to finding a solution.

The best approach I can think of straight off the bat is to use a Sprite Font with fixed width. Knowing the width of the characters, you could anticipate when a word will flow to the next line and place it there beforehand using a line break. That would be the general idea.

Also, I recently saw another C2 game (can't remember which one) that had this same problem, but seemed professional in almost every other way. It really bugs me because I haven't seen a single professional release that messes this up, yet most beginners implementing the typewriter effect don't seem to mind the visible word wrap. It looks disgusting to me

There is no such thing as a secondary 'then'. An event is an 'if' statement. So a sub-event is an 'if' statement within an 'if' statement. Like this:

if (Condition1)
{
  // actions
  Action1();
  Action2();

  // sub-events
  if (Condition2)
  {
    Action3();
    Action4();
  }
  if (Condition3)
  {
    Action5();
  }
  
}

Awesome! Great timing. I'm looking forward to the next release. Thanks Ashley!