Ashley's Recent Forum Activity

  • Why don't I see such scandals in other game dev communities?

    Because they use public APIs with encapsulation. Again, providing source code is not related to that.

    Again, I understand your point and reasoning, but I frankly don't know how you can look at your userbase dead in the eye and say "this change you all unanimously find stupid is great for you actually".

    We have a responsibility to our customers not to cause their years-in-the-development projects to get ruined by development hell. We also have a responsibility to protect the business and prevent Construct itself falling in to development hell, which in extreme cases, risks the failure of the product and business.

    I know addon developers don't like it if that means they can't customize the engine as much, but as I say, often there are other workarounds which people can and should be using instead, and overall, in my view, it is better this way round. The way I see it, there's lots of addon developers wanting to do things that we know will cause disasters, but claiming it will in fact all work out fine; our job is to avoid disaster, which we will do whether or not addon developers understand why, because we understand just how terribly awful things get down that path.

  • And just in case anyone asks for my response to this:

    IMO this would be fixed by just letting addon devs specify a version range for which addons are made for, and have the editor warn you that the addon may be unstable if the current version falls outside the range (with a button to continue at your own risk)

    That does not solve the problem. Sooner or later people absolutely have to update Construct, whether it's for bug fixes, essential new features, or just to keep up with the latest publishing requirements on platforms like Android. If someone can't update because of a third-party addon, they are stuck in development hell: they absolutely have to update, but they can't. This is the same problem as addons unexpectedly breaking in future, and compatible version ranges or warning dialogs just puts a bit of metadata around that without affecting the core problem.

    As I say, it's easy to throw around ideas that sound like they work, but when you have maintained software for thousands of people for a decade, it's obvious they won't work. There is a well-understood and widely-used solution in the software industry: a public API with encapsulation.

  • I'm running out of ways to say this, but just to emphasise, hacking internal APIs will end in disaster. It already has for us in the past, and this point is obvious to experienced software engineers. It is the whole reason encapsulation was invented. I think it is likely that in 2030 and beyond we will still be dealing with painful compatibility issues caused by the internal engine hacking that people are doing now.

    Providing source code is not the same thing as providing a stable API. Other tools which have a public, documented API, which they change over time, sometimes in backwards-incompatible way, is not the same as letting people loose on the internal engine. That example of public APIs that evolve over time in a responsible fashion is in fact the thing we want to aim for. As I said, that's the industry standard, and what Construct has at the moment is a uniquely bad situation due to the poor encapsulation of JavaScript. This is not just a technical point: it is a matter of support and maintenance and what you promise customers and developers. I don't think everyone here has fully appreciated that.

    If everyone is insisting we do something that has and will end in disaster causing both us and our customers to suffer as a result, and insisting that actually don't worry, everything will work out just fine - sorry, software development for a tool used by hundreds of thousands of people that is maintained over a span of more than a decade just doesn't work like that. Our own experience has shown that, and it's widely understood stuff in the software industry; if you don't accept that, I don't really have anything more to add, and so I will stop responding to this thread accordingly. I am so convinced by this point, that I would heartily endorse all our competitors doing what you are asking us to do, because it will end in disaster for them, and if we can avoid that then it will turn in to a competitive advantage for us.

    If we put the addon SDK behind the scripting interface, then we solve our problem of how to have a public API with encapsulation that we promise to support in the long term. This can be thoroughly and widely used and will most likely not cause any disasters even years down the line. I know this does not give unfettered access to the engine, but as I say, that's the industry standard when it comes to API design (not source code), and it still gives you a lot - there is a broad and fully documented API there. Then we have a single place to add new APIs which are instantly accessible to both scripting users and addon developers, which is much more manageable than having to effectively maintain and document two separate APIs, and means we can move quicker and expose more APIs in the long term. I think that is the best direction to go in, and I think we will start to look at a "v2" SDK along those lines in the near future - as the sooner we can move away from the serious risk of disaster that we are currently facing, the better.

  • You must also tell Construct about your script interface class by returning it from GetScriptInterfaceClass().

  • I think this amounts to multiple inheritence: you want classes to inherit from multiple locations - the Construct provided base class, and a separately written base class also inherited by other classes. If you search for JavaScript mixins you should find a few ways to do that.

    Another simpler way (and one I tend to prefer these days) is to use composition over inheritence - create a complex custom class that you want to be shared, and just add it as a property on multiple other classes.

  • See Exporting to Windows with the WebView2 wrapper, which covers this. As of Windows 10+ all Windows systems should have the WebView2 runtime installed automatically. However some out-of-date systems may not have it installed, but in that case, the exported app will automatically download and install it.

  • Don't get hung up on whether or not we do it deliberately: the point is everything could break unintentionally, by accident, due to cleaning up our code, due to refactoring to reorganize things, due to performance optimizations, due to upgrading or replacing internal components, due to adding requested features, or for any other conceivable reason. Everything could break anyway. This is the risk everyone is running by using undocumented features, and this is why we have that warning. If that happens we reserve the right to say "sorry, you shouldn't have done that", otherwise we basically lose the ability to upgrade the engine.

    It sounds like stuff is already occasionally breaking and addon developers have to update their code. What happens when these addon developers decide to move on and stop maintaining their addons? We start facing backwards compatibility disasters and we are left to deal with the consequences.

    How do we avoid this risk? The industry-standard solution of using encapsulation to ensure people only use public, supported APIs and can't mess with the internals. It's nothing to do with Apple or the open web. The situation is JavaScript has weak encapsulation, so we've ended up in an especially bad situation for compatibility that other tools don't face, and we want to try to avoid the disasters that are inevitable if we carry on down this path.

  • As you will always have some form of text rendering in the engine it's save to assume that while it might change, maybe even drastically, it is near impossible to be removed completely.

    No, this is an incorrect assumption, and text rendering is actually a good example of why. I have been monitoring the canvas formatted text proposal, which lets the browser do the text layout for formatted text when rendering to a canvas. Currently we have had to implement our own custom text layout engine in JavaScript, which is both extremely difficult, has lots of difficult bugs and edge cases, and is reimplementing what the browser already does. Ideally we could switch the implementation to a browser-based one with the canvas formatted text proposal and delete our entire custom implementation. It could then have more features, better performance, better consistency, broader internationalization support, and so on.

    However if we did that, all third-party addons which rely on hacking the internal text layout engine will be broken. All the internal text layout code would be deleted, so there is no more scope to modify it. It may then be impossible to achieve the same thing with the browser built-in feature, as from our point of view, we only need the new text engine to be compatible with the old official features. It is possible that third-party addon compatibility is then such a severe backwards compatibility problem that we have extreme difficulty implementing the new, better engine; or even we have to cancel the project to upgrade it. For us, that's game over: now we can't upgrade the engine, or it is far more difficult to do so, and so we end up stuck with inferior systems in the long term.

    This type of thing can happen with literally any part of the engine. The undocumented features warning is there because we want the flexibility to be able to upgrade the engine in the long term. So really the problem here is developers assuming it is fine, when it is not. It is meant to be a serious warning that is taken literally. If you ignore the warning and assume it will be fine, and then everything breaks, we reserve the right to say "sorry, we warned you about this" and proceed anyway, to avoid the outcome that we are unable to continue making improvements long-term.

    Do you want to support 3rd party development?

    Obviously yes - if we didn't, there would be no addon SDK at all. Exposing a controlled public API is the industry standard, and as I keep saying, the only reason people can bypass that in Construct is because of weak encapsulation features in the JavaScript language.

    Would it be possible to set up a way for folks to more easily get access to an expanded api?

    I think perhaps a good way to do this would be to put the addon SDK behind the scripting interfaces used when doing JavaScript coding in Construct. That is already a more comprehensive, documented API, which does have encapsulation, and it avoids us needing to implement and document APIs twice (once for the SDK, once for scripting) - by adding an API there it then becomes available to both addon SDK developers and JavaScript coding simultaneously.

    Again, you needn't promise eternal stability, just a way to get the job done

    Yes, we do need to promise indefinite stability. Otherwise if we change it say 5 years down the line, it breaks a popular third-party addon, thousands of projects are broken, and the original addon developer has left the community, then we have a huge compatibility mess which we are left to deal with. This has happened. Again, this is a case of people assuming things will be fine, but it is not. The only way to avoid this is a public, documented API that we promise to support indefinitely.

    Do actually believe that behavior alone addresses all needs within the genre in a scalable, and sensible way?

    Maybe the behaviors don't do everything. They are designed to be flexible. But beyond that, you can use custom logic in event sheets, or JavaScript coding within a project, to implement things like custom movements. You don't have to jump to hacking the engine internals. There are usually several ways to get things done.

  • function getRuntime(runtime) {
	return runtime;
}

    This function is pointless - it just returns its parameter. 

    var playerInstance = getRuntime(runtime).objects.iPlayer.getFirstInstance();

    This line is run at the top level, so it is run before the Construct runtime exists, therefore runtime cannot be used. The runtime only exists when the callback to runOnStartup() is executed. So you have to wait until at least that point in time or later before trying to use the runtime.

    A typical way to do that is to declare the global variable as set to null initially, and then assign it later on.

  • To help clarify the point, I've updated the wording in the Addon SDK documentation to read:

    To be clear, it has always meant this - I'm just adding a clarification to emphasize the warning includes that possibility.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It went from "undocumented features could change or be removed at any time" which is perfectly fine and understandable to "we plan to make sure nobody could ever access and use an undocumented feature".

    "We plan to make sure nobody could ever access and use an undocumented feature" is a case of "undocumented features could change or be removed at any time". It is precisely what the warning was warning you of.

    It is not removing engine customization completely. Engine customization remains, but with the provided APIs.

    As I said before though, if we do this, I promise we will do our best to approach it in a responsible fashion, and roll it out gradually and in phases and deal with compatibility issues where feasible.

  • But, isn't it a similar situation to any support request that Scirra receives: if a project has correctly-made third party addons and sends it to Scirra to fix, Scirra wouldn't touch these until the addons are removed?

    No, there is a distinction here: it is not Scirra's responsibility to provide support for third-party addons. If there is a bug in a third-party addon, then the third-party developer needs to deal with the report and fix the problem. However if the addon developer themselves identifies a bug in Construct's supported APIs, they can file an issue with us and we will fix it. (Note if the bug is in an unsupported API, we are not obligated to fix it, as per our warning about using unsupported features.)

    Overall, it really hurts my trust/faith in Construct, and I'll think more carefully about my choice of game engine for upcoming projects.

    I would point out nothing has changed. That warning has been there for a long time and it has always meant this. If this was not clear to you, I am not sure how to make it any clearer. Do you think the wording should be different? If so, what should it say?

    You can of course stick to the documented APIs and do anything you like, and we promise to support that indefinitely. I am pretty sure there is a lot more flexibility in using officially supported features than most people appreciate. As I said many engines make it difficult or impossible to hack the runtime code, especially at runtime, so this entire pattern of hacking the engine mainly via the weakness of JavaScript's encapsulation is not typically used in the industry. Everyone uses different approaches, like creative workarounds, or other implementation techniques. You can do all of that with Construct too, and have no risks or problems. As I said before, I think people are too quick to reach for "hack the engine" as their solution, rather than more thoughtful approaches that would be more reliable in the long run.

    I think you need to understand our stance on this Ashley while you are working on software architecture and striving to have something that will still work in 10 years, we are not.

    I realize game development may be different, but it doesn't change the fact we are in a different position having to maintain software for many years, and that imposes different and more stringent engineering requirements.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,383,152 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x107
    Coach One of your tutorials has over 1,000 readers
  • x61
    Educator One of your tutorials has over 10,000 readers
  • x2
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs