Is there a method to access engine internals from JS blocks?

Post reply
1 favourites
From the Asset Store
Isometric Ground Blocks
$2.50 USD
25 high quality isometric ground blocks + sprite sheet
mewki's avatar
mewki

  • In the addon sdk I can do unofficially supported things... like this: 

    const wi = this.GetWorldInfo();
wi.SetSourceCollisionPoly(someAnimationFrameRefference.GetCollisionPoly());
wi.SetBboxChanged();

    Is it possible to bypass the official interfaces provided in the editor, either in modules or js blocks?

    I was trying to test out moving some behaviors into modules, for ease of cross behavior interaction and the ability to extend classes, and I was having trouble figuring out how to do basic, unsupported api calls.

  • Do not do this. See the warning in the addon SDK documentation. If you refer to undocumented engine internals, your project will be unsupported and could permanently break at any time.

  • Do not do this. See the warning in the addon SDK documentation. If you refer to undocumented engine internals, your project will be unsupported and could permanently break at any time.

    "Permanently"?... or just until I can understand what changes were made and why and make a fix?

    Or is it that there is a plan to obfuscate all internals at some point?

  • Or is it that there is a plan to obfuscate all internals at some point?

    This could well happen, and it could mean whatever internals you are accessing become permanently unavailable.

    A long-standing problem with JavaScript is it has typically had poor encapsulation: external code can easily mess with the internals of APIs. With newer features like private fields there is proper encapsulation support that makes it genuinely impossible for external callers to mess with internals. As encapsulation is a basic principle of software engineering and important for the long-term reliability of a platform and codebase, I would definitely like to use that throughout our codebase. This would however make all sorts of internals permanently inaccessible - much like they already are with any other game engine with any other technology that properly supports encapsulation, so bringing us in to line with the industry standard. This could permanently break engine hacks with no workaround. This is exactly why we have this warning, and why whenever possible I advise against it, since as per our policy we will not help anyone in this situation if they were using undocumented internals.

  • Hey Ashley, I totally understand why you're saying us to not use undocumented internals. It allow C3 to evolve pretty fast without Scirra needing to worry about rewriting some chunk of the runtime. You don't have to support indefinitely every method etc.

    However please, never obfuscate it / make the undocumented runtime unavailable.

    Being able to acces the runtime internals (at our own risk) is essential to allow us to workaround engine limitations or create very specific features we need for our own games and that Scirra couldn't want to implement (for legitimate reason - too specific, would bloat ACE lists, taking too much time to implement, too hard to grasp for beginners).

    For any complex game production no matter the game engine, the gamedev sometimes need to tweak, hack or extend the engine to make something work. I avoid it as much as I can, and I don't plan to release publicly addons making heavy use of it but for my own purpose, i need it very often and making it unaccessible at some point would just make any dev at the mercy of what Scirra has the time/wants to implement. (And most likely very specific issues hapenning on specific game productions aren't Scirra priority)

    I think the current balance is good: Scirra warn us to not use it, but advanced dev knowing what they're doing still can use it for their own purpose instead of spending months/years to beg for missing features that might never happen, or moving to an other engine.

    As Scirra has limited resources/small team and far too many suggestions this is the best balance for 2 reasons : Scirra can rewrite any part of the internal at any time AND If a user REALLY need a specific feature, at least he's able to do it using undocumented features.

    If this become obfuscated, we wouldn't have any ways to implement features ourself, the documented Addon SDK is just far far too limited. (and will always be, because no one knows what will be the very specific/advanced needs of any complex game production)

    I would definitely like to use that throughout our codebase

    Are you really considering to do it ? Your message could let us think that this is actually planned which would be really worrying. Could you give us any guarantee that this will or will not happen ? This kind of thing would have a major impact on my business and mid/long term plans. Imagine if you knew the Construct 3 engine you're developing for 15 years as a whole had a 50% chance to just permantently break with no workaround at any time because major Browsers decided to do so ? This is basically the situation you're putting some of us in with this kind of statement. (in fact it's even worse as we're paying a subscription to fund the development here)

    Some of us are C3 subscribers or customers for 10+ years and i think we desserve to know if such an important change is about to happen. If a game engine moves from "a workaround is likely possible if you really need something" to "no workaround no matter how experienced you are and how hard you try", it's not the same kind of game engine anymore.

  • I gotta admit it's kinda spooked me too.

    I had some suggestions that aren't popular and may not get implemented by Scirra, so community members have assisted, where their solution uses a few undocumented things, mild things but it gets the result I need.

    I know the risk, can break any time, but it's nice to know I could try to ask the community to help again if it did break.

    Whereas if an update for C3 dropped and it obsfucated those things, then this would permenantly prevent me from having the result I previously had.

    I guess if this really has to happen, I will need to resist urge to update and remain on last working version of C3, but I like being a beta tester and playing with cutting edge stuff!

    I get the risk but would feel painful if things broke, not because a new C3 feature broke it and could potentially be fixed, but because an active choice to obsfucate thing permanently breaks it, would feel very hopeless.

  • Jumping on this topic as well. Obfuscating the runtime will ABSOLUTELY break most of the bigger 3rd party addons, it will break a LOT of scripts and in general it is extremely hostile to any advanced user of the engine.

    To me this sounds like shooting your own foot with a shotgun because a fly landed on it.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
    • unreal engine: source available
    • unity: source available
    • Godot: open source
    • gameMaker: open source runtime
    • GDevelop: open source
    • Phaser: open source
    • playCanvas: open source
    • Defold: source available
    • ... and many more

    I'm confused what you, Ashley, mean with industry standard, as almost every game engine is either open source or source available.

  • Open source is not the same as compatible with hacking the runtime. In a native engine, you could do things like identify memory addresses where useful things are and overwrite memory addresses with custom data to achieve new things. Anyone who knows anything about reliable software engineering will be cringing at that idea because it is obviously a disaster and you will end up with a total nightmare with everything breaking all the time. The main reason people don't do that with native engines is because it's particularly difficult. JavaScript lets you do something similar, but more easily. It does not make it a good idea. Again, this is not the same thing as whether or not the engine is open source. It is a matter of maintenance and long-term reliability. Being able to look at the code does not mean that hacking memory addresses in a native engine becomes reliable, and likewise, being able to look at the code does not mean that hacking internal JavaScript APIs is reliable.

    I'd say the open source equivalent would be forking the engine and making a bunch of modifications to the internal engine. Now you have a compatibility nightmare as the main branch diverges from your customized codebase. You might try to occasionally merge over changes, but then you might end up with merge conflicts and a huge mess in the codebase. The easiest thing to do is never update the engine. Now it's game over for support - nobody can support your customized engine, and you cannot easily merge in any new features or bug fixes in the main engine. Anybody who has been through this process knows the only good approach is to merge any changes upstream in to the main open source project, so you are still working with the single shared codebase shared and supported by everyone. If you have your own hacked fork, you do so at your own risk, and it will probably end in disaster for you, but that's on you.

    The difficult thing for me here is that this is all well-understood stuff learned over decades of the software industry. But right now people are already doing it with Construct, it looks like it works, and why would Scirra go and break it? It's because in the long run, it ends in disaster. This has already happened with Construct 2, and it is obvious to anyone else who has maintained a software platform for a long time, but it may not be obvious to people tinkering with the engine right now. So you can downvote and argue all you like, but our responsibility is to make sure the engine is reliable and will continue to be reliable even a decade ahead from now; we know what that involves; and we are advising people accordingly.

    The exception to all this is the documented, supported APIs. If you use those, we promise to support them indefinitely. That's why part of my advice is to stick to those.

  • I understand the reasoning, but also you need to understand why stuff like that happens in the first place.

    I have been making addons for 7 years now, and the overwhelming majority of the issues I encountered making addons for C3 has been the fact that the C3 addon SDK is very limited. I don't think anyone would be too worked up if the exposed SDK was more extensive.

    In fact most of the new addons made by Scirra use non exposed features. You also run into the same issues we run into and I don't think it's fair to say that for us it's not allowed because programmer god said so.

  • I see it as quite the opposite, the engine would become less reliable if we cannot fix our problem ourselves. This would be a risk for anyone building a game with c3. Because than the "wontfix" or "enhancement" has potential for much more dire consequences.

    This is also why having source code available is so common and the industry standard, as no company of a certain scale would risk this.

    Construct 3 already has a insanely limited addonSDK, I think bringing the addons sdk up to the industry standard would be a better solution if you are worried about engine hacks.

  • The only thing we want is to keep being able to access undocumented methods (that all official features relies on including all official Behaviors/Plugins that never changed in 6+ years) at our own risks when we need it. It's nothing like forking/hacking the engine.

    Anyway could you just please answer this simple question so we can plan our projects accordingly : do you plan to obfuscate the whole undocumented runtime and only let us use the documented features ?

    I think it would be fair to give us a clear answer

  • If I'm missing a small feature or some ACE in an addon from Overboy I know I can contact him and he will most likely add it if it is possible and it's done the next day, sometimes within an hour. Or he lets me know that it isn't possible and I can move on trying to find a different solution.

    If I am missing a feature or ACE in an official addon (I'm screwed) I make a feature requests, it gets deleted after a year, I make it again on the new platform, wait another year, etc. etc., sometimes I give up, sometimes it gets added after 3-7 Years.

    You can't argue with how things work in other engines when this is the state of your engine. Look at how stressed you were dealing with Apple, this is the same for us, this is cutting us off from our last resort to be able to fix our own issues because WE KNOW FOR A FACT that Scirra wont.

  • The addon SDK may be limited. I appreciate that. However I suspect most of the time, there are workarounds to what you want to do. I'm pretty sure at least some of the time you don't have to go hack the engine. As I mentioned, with a traditional native engine, usually there is no scope to hack the core engine at runtime, and so everyone resorts to other workarounds and gets by; only JavaScript makes it easy for people to hack the engine at runtime in this way. I get the impression people realize they can, and then they reach for it as their first solution when there are better options. There is also the feature request system, which I also appreciate is slow, but that's the official way to get new things supported.

    Sure, if an engine has an open source runtime, you can hack it to your heart's content. But as I explained before, that's a double-edged sword: you could well end up in development hell, and some people learn that the hard way. Someone giving you source code doesn't mean they'll support you if they make a mess, it's more just "here you go, good luck".

    do you plan to obfuscate the whole undocumented runtime and only let us use the documented features ?

    There is this warning in the addon SDK documentation:

    That warning is there precisely because it is a real possibility! It could happen unintentionally, it could happen because of some major upgrade or new feature, or it could happen because we want to improve encapsulation for better long-term reliability. We don't want to break things, but the point of this warning is if you use unsupported things, it definitely can; we will do our best to avoid causing major disruption where reasonable, but it may be infeasible or go against our long term plans, in which case, what can I say other than we tried to warn you?

    If you ignore that warning, you should be working under the assumption that the undocumented features you are using can change or be removed at any time, just as it says. I would say if you are going to ignore that warning, the only responsible way is to have a plan in place for what you are going to do if the thing it warns you about then happens, so then you can fall back on plan B. But then in that case I would say, just do plan B first, and you won't have the trouble with undocumented stuff changing or disappearing.

  • So you can guarantee the Runtime API won't become like the Editor API in the future where only the documented exposed stuff is accessible while the rest is obfuscated and impossible to use ?

    To me what you are saying here isn't clear.

    I think we all know about that warning and that we should use undocumented features with caution.

    The difference here is that you mentioned several times those past months that you would like those undocumented feature to be totally unavailable for us. Which is completely different

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)