github.com/Scirra/Construct-feature-requests/issues/173

At the end of the day, scripting is suggested to be able to solve needs that the event system can't.

But...

There is limited api access for basically EVERYTHING.

The devs know this, but choose to ignore it for other priorities, and that makes sense in their position. But if Scirra has to access private internals to get a behavior or plugin to work, its because the public API is far too limited. You can't recreate a huge swathe of vanilla behaviors, let alone create better versions of them with the current public api.

This isn't good if you care about creating anything unique, or have higher standards - I'm looking at you pathfinding, platformer, and 8way.

This makes Construct an engine that supports ONLY out of the box behaviors. Creating sophisticated behaviors in events is poor in performance if you keep them abstract or wish to scale, and using JS to recreate all the wheels construct won't expose is stupid when other engines do you the favor of allowing you access. Plus, to beat a dead horse, the event system is objectively one of the best things about construct, in terms of speed of design. Wading into scripting editor side essentially defeats the advantages of working with construct and, objectively, there are much better engines out there if you are coding.

The issue as I see it is that Scirra wishes to keep things internal to allow them to be able to a.) refactor at will when needed, and b.) not break peoples projects in the process, which is a great goal and I understand. But the flipside is that while construct is very stable, there is so little exposed that the promised "stability" is nearly pointless as you have to use the undocumented api to accomplish anything.

All and all, I understand I am in a minority here.

I am at a cross roads. I can keep building up my brittle collection of behaviors built on so many undocumented api calls...

Many undocumented features have remained very stable over the years, and I'm okay correcting the odd compatibility issue here and there - But what if they become inaccessible or obfuscated in the future - for no other reason than simply scirra wants it to be? Ashley has hinted at that possibility - though that would pointlessly break many 3rd party addons that have necessarily used internal features.

This isn't an issue if you are making small, uncomplicated games, or are happy with the provided boxed solutions. I am not, and I am not.

How many other people have simply ignored the official advice and built behaviors on undocumented API?

I personally don't feel like I have a choice. Either I use the unofficial api, or I don't use construct for this project... again...

And to be clear, my project isn't fancy. I just want a custom platformer that doesn't resolve collisions the same way construct does, is extendable and well written in "SOLID" fashion, and one that isn't pigeon holed into using the solid attribute, along with better oneway jump through handing, slope performance, and a different physics integration model that accurately deals with variable accelerations over time. This is all pretty basic needs stuff AND construct has everything built in to handle this... just not exposed. What is exposed through the custom behavior makes alot of hard-coded assumptions about what is needed instead of just letting the user decide.

For example: PushOutSolid, which is an undocumented function that custom movement behavior uses, has a hard coded max distance for resolves, a fractional nudge algorithm that iterates a hard coded 4 times, and only works with solids, when in fact, along with other internal functions, you can do less work and achieve sub-pixel perfect collision resolutions without limiting it to solids only or hard-coding the details.

Construct has trapped itself in a place where it is afraid to expose api because it needs to stay flexible, but insisting on remaining backwards compatible for decades means things can't advance.

---

Perhaps a new class of api should be released. A publicly documented "experimental" api. This would allow construct to sanction the use of more internal features, but with the caveat that they can change in the future, with "fair" warning.

Basically, you can use them, but they are subject to documented change.

Thoughts anyone?

How to swap collision polygons without interrupting an animation

TLDR: I use unofficial "Getters" to the construct3 CollisionEngine, in order to directly set collision polygons and bypass the sprite plugin changeframe/animation behavior. This allows me to control and check collisions from a behavior, and reduces alot of the overhead to changing frames through an ace. Since I bypass the change frame entirely, it doesn't disrupt any currently playing animations. It only affects collision polys on the object.

The problem : Compound collider objects require picking loops, containers(no families), hierarchies (with picking loops for animation), or similar solutions

The issue isn't obvious until you try to scale, extend, or have performance issues, then it's painful.

When it comes to managing complex/compound objects, do you ever get annoyed with picking, iterating hierarchies, or dealing with containers, just to be able to have multiple collision polygons for an object? Picking loops often require a "foreach" loop, which can be expensive at scale. Hierarchies do a lot of additional lifting but will still likely require a loop if you need to separate view and model. And containers don't work with families.

Sometimes, all of this isn't a big deal for unique objects, or those in lower quantities. But the more you have, the more difficult scaling will be, and extending any solution through abstraction will also require a lot of repetition.

You can avoid the above if you create an animation on the object and simply switch frames for different collider polygons, BUT that comes at the cost of not being able to run animations automatically, and will require additional systems for tracking the animation state. Swapping frames around can also cause any triggers set up to repeat.

The solution : WorldInfo polygon swapping.

There are a number of ways to approach this, but currently, the way I do it is as follows:

You will need a distinct objectType in the editor to be able to create animations and create collision polygons for various frames. It has no other purpose than to serve as a place to edit your collision polygons.

Then you will need the object you want to have the super ability to change colliders without changing animation frames or interrupting the animation playing.

Last... you have to create a behavior or script an equivalent tool editor side to then automate the process of changing polys. I chose to use a behavior.

The behavior

The behavior is going to have an action with 3 parameters to pass in an objectType(restricted to sprites), an animation string name, and the number of frames in the animation to collect.

Here is a sample bit of code that sets up the behavior: (obj, animName, frameCount)

const pickedInstance = obj.GetFirstPicked();		
frameCount = Math.min(frameCount, this._stateCount);		
const animation = pickedInstance.GetSdkInstance()._objectClass.GetAnimationByName(animName);
for(let i = 0; i < frameCount; i++) {
	this._stateFrames[i] = animation.GetFrameAt( i );
}

const wi = this.GetWorldInfo();
const ce = this.GetRuntime().GetCollisionEngine();

//you can iterate through all states with a for loop, or pick individual frames
//Keep all related variables in equal length arrays and you can easily iterate
//Use solids, build a candidate list, or test against whatever
wi.SetSourceCollisionPoly(this._stateFrames[i].GetCollisionPoly());
wi.SetBboxChanged();
if (ce.TestOverlapSolid(this._inst)) {
	this._state[i] = 1;
}
else this._state[i] = 0;

Thanks for the details. I suppose that all makes sense,

As I understand, you are essentially saying the cost/benefit ratio also doesn't exist engine side, due to increased bugs/complexity without a "real" benefit to most games. I agree given your explanation.

2 things I disagree with though:

1. Making a pool via events isn't worth it. The cost of the event editor overhead eats a major portion of the performance gained, and its nigh impossible to create a generic one that doesn't spend more energy than it saves. This activity is much better to be done in script - but the cost of tying that into the editor can still outweigh the performance gained IF you use js blocks. If everything is in script it and you don't need to make recycle calls from events, perfect.

For that reason, I would argue it isn't worth the time, because the cost/benefit ratio just isn't there.

2. GC is most performant when collecting newly created items. I think the vast improvement in JS gc is in this realm, yes? But recycling is good because it helps major collection (though total allocations has an ongoing cost). If the bulk of gc allocations are items created every tick, the collection of those items is much, much faster. These items are part of a minor garbage collection and typically get collected in the idle time each frame, so have no impact on frame or stutter whatsoever. However, if performance is being impacted by minor gc, reducing it is as easy as not discarding obj refs every tick and not creating objs just to discard them every tick.

Items that remain in memory for longer get collected by the major collector and those can indeed cause frame drops when it runs. Object pooling helps most in this arena.

IIRC maybe the C2 runtime did that, but the C3 runtime doesn't, so this hasn't been the case for years. JavaScript and modern GCs are so good that kind of pooling approach doesn't matter any more.

Respectfully and in humor, lol.... What?!

No way! For games that it matters for, it does matter alot. For the rest, it doesn't hurt any. A generic pool usually always helps performance for any objects being created/destroyed at runtime. Tweaking, or supplying specifics can improve a pool even further.

Allocating and releasing memory takes cpu work, no question. Better gc doesn't really change that, just lessens the impact... but it doesn't eliminate the impact. Call me a skeptic - but industry standard is still to pool - and that is regardless of whether you are in c++, c#, js, or heaven forbid gsl. If you pool in unity or unreal, I can't see a reason why you wouldn't in js in construct, given c#/c++ has better performance at runtime.

You can easily test this with an objectpool made out of construct events using inefficient arrays and pick by uid, and it will perform better than simply creating and destroying objects, despite the pool having a large overhead for looping objects. I still get 20% better performance in this case. If you perform the same equivalent loops to the non-pooling method, the performance increases. Move the pool to scripts and you will see bigger benefits. I didn't do it in script form because I still have to lumber through js and the api, but I'm sure you could whip something out to test in minutes.

For a bullet hell game or any other where objects are frequently being destroyed and created, object pools are a absolute must for smooth performance.

If I run equivalent loops for pooled/vs non pooled objects to eliminate event overhead for loops, I can get 5x the fps for pooled objects in perfect contexts. Engine side, you should be able to do even better by properly moving those objects to a space where nothing updates for them and they aren't "technically" on the layout anymore.