Ashley's Recent Forum Activity

  • In the exported index.html, look for the <noscript> tag. That is where that content comes from.

  • The way SpriteFonts work, every character is in fact an icon. So yeah, you can use custom icons with special characters.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's not easy to support npm in Construct as it runs in the browser without any involvement of node. If you can get a library you want packaged in a manner suitable for using in a browser, it should work in Construct too. So usually the trick is to find some browser-compatible package of a library.

  • As noted in the manual, the | operator is logical OR. An expression of the form A | B will only ever return 1 or 0 (for true or false). This isn't very good for setting a position! I'm not sure what your actual intent is, but you are probably thinking the operator is doing something it doesn't.

  • I am talking about encapsulation, not obfuscation. The extreme would be having no API at all. I don't think it's reasonable to compare having a supported API as welding down the engine cover, even if the API does not do everything you want.

    I don't think me continuing to post here more is going to help much, as we're just restating the same points. But I would point out I'm not posting here making our case and taking all this heat for fun. The current situation is unsustainable and risks disaster with every release. To be clear, disaster includes ruining people's projects that have been years in development, ruining the reputation of the product, consuming our already-limited resources with weeks or months of dealing with emergency compatibility issues, and in the extreme, the failure of the product and business (which I've seen happen to other products over the years, and naturally I'm keen to avoid that). These types of things have happened and will happen again, until we design a maintainable SDK. Those arguing it will all turn out fine are arguing against our actual experience of how things have gone, and widely-understood industry practice. I do not believe there is any plausible way to avoid disastrous outcomes other than a public, documented, supported API with encapsulation - the industry standard and the reason encapsulation was invented by the industry decades ago.

    Sure, having a limited SDK is frustrating. Some people may even decide to choose other products to do what they want to do. That is all less bad than the disaster we face if we carry on down this path. Obviously I don't want to cause disruption but as we already face the risk of disaster, I think it is sensible to take steps to mitigate that - to leave things as they are would in my professional opinion be reckless. I always knew this was the case, and that is why our SDK has always carried a clear warning that I have always repeated whenever possible: do not use undocumented features. If some people disregarded that warning on the assumption they thought it would all work out fine in the end, then that in my opinion was the wrong decision. We will likely start moving to a better designed SDK in the future, and we will try over the coming months and years (as this will be a very long term project) to make good faith efforts to mitigate compatibility problems caused by use of undocumented internals where they come up, even though we clearly warned developers about it. This is time-consuming and difficult, and is itself what we wanted to avoid as that type of work takes up disproportionately large amounts our already-limited time, but we also should be pragmatic about not causing more disruption than necessary. However in some cases it may turn out to be infeasible and some use of undocumented internals may be permanently broken. This was always a risk anyway as it could have happened for other reasons, and was something we specifically warned about, and we will be sorry if it happens as it is never a good outcome. But that's why the warning has always been there. This is what it takes to make software that customers can trust will still work 10 years later.

  • Well, a limited public API with encapsulation is the norm in the industry. So it's normal that you work with that and either rely on workarounds or feature requests. Perhaps in an ideal world the APIs would be broader, but that is always improving, at least in the script APIs (which would be the basis of a v2 SDK).

    Another thing people routinely underestimate is seemingly minor features can have difficult complications. I've lost how many times I've thought "this is only a few lines of code" and then ended up spending a couple of weeks on it. Over the entire lifespan of a feature, let's say it's over 10 years of support and maintenance, writing the initial code for a feature and getting it working is probably about 25% of the work. The rest is long-term support, maintenance, refactoring, optimization, and upgrades which are sometimes very tricky to do in a backwards-compatible way. There are many things that might look obvious from the outside but get much more difficult when you have hundreds of thousands of lines of code used by hundreds of thousands of users maintained for over a decade.

  • 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.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,424,126 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
  • x108
    Coach One of your tutorials has over 1,000 readers
  • x62
    Educator One of your tutorials has over 10,000 readers
  • x3
    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