Ashley's Forum Posts

  • Take a look at the voice recorder example which should be a good place to start. You can also save recordings to Local Storage as binary data.

  • It depends: Touch with mouse input enabled can work if all you need are left button clicks and drags. If you want something like detecting the mouse cursor hovering over an object, you still need the Mouse object for that, as the concept of hovering doesn't apply to touch input, or if you want to make use of middle/right clicks or the mouse wheel.

  • It's difficult to help from a forum thread like this, as all anyone can do is speculate. By far the best way to get the right help quickly is to share a project file demonstrating the issue.

  • Perhaps take a look at the Flowcharts questionnaire example which shows how to display a sequence of questions based on the user's choices.

  • Various project settings can affect memory use, including the downscaling quality and max spritesheet size.

  • There is a big difference between being an addon developer running in to the limitations of an API, and the entire product stability getting so poor that it risks the failure of the business. I don't think it's fair to use the same "development hell" term for both of those.

    I would rather nobody did make another platform behavior. This kind of feature duplication causes a bunch of other problems too. Again, we saw much of what happened when people tried hacking around with the official engine code in C2: broken projects, incompatible changes, no good way to switch between them, the official addons ending up superseding them but people being stuck with old buggy third-party versions of addons, confused users who don't know which they're "meant" to use... some of which takes years to play out, and leaves us having the support headaches of trying to help people with things like broken projects long after the third-party developer responsible has left the community. As I was saying previously, the consequences end up with us and our team, and as a small company with limited resources it is especially painful.

    Of course, it is possible to make a comprehensive and well-supported public API. It just takes time. We routinely get far, far more requests than we could possibly act on, and things like developing a large API that we promise to support indefinitely is potentially a major project and a major long-term maintenance burden, and we have to balance that with literally hundreds of other things. If I could click my fingers and have it all done, of course I would, that would be great! Unfortunately we have to deal with the real world and limited resources.

  • It's difficult to comment on suggestions. They can seem simple but turn out really hard. Sometimes they can seem difficult but turn out not too hard. You don't really know for sure until you actually implement it. Having said that, the effects system is one of the most complicated parts of Construct and very difficult to work with, and on top of that at the moment we are maintaining two renderers - WebGL and WebGPU - which means any graphics features have to be implemented twice with considerably different technologies. So overall I would say this would be a complicated change, regardless of what anyone claims about it. I'd add that we do not really want to end up making a full 3D engine - that would involve years of work and potentially amount to an entirely new kind of product, and I think we're already seeing a stream of "just one more 3D thing... just one more 3D thing..." that is trying to push us all the way down that road, and I'd rather not go very far down that road. Finally I must point out that for this and other reasons, the feature request guidelines state that we do not guarantee implementation of features, even for the top voted ones.

  • Changing the contents of just part of the text is not currently supported, but you can achieve a similar result another way, by building up the string with variables. For example "xxxxx [tag=mytag]" & SomeVariable & "[/mytag] xxxxx", and then changing SomeVariable and updating the text to that expression again will have the same result as if the contents of the tag were changed.

  • There is a fundamental tradeoff between a small well-supported API which is reliable in the long term, and a large API which keeps breaking in the long term. The worst case scenario is to refer to undocumented engine internals. This can break at any time and we will not provide support if this happens due to use of undocumented internals.

    Long, painful experience has shown the downside to just letting developers loose on the codebase results in unmaintainable software. This point is obvious to experienced software developers who have maintained a platform other developers use for the long term, and is the reason why decades ago the industry came up with concepts like encapsulation. It's not always obvious to people who run in to the limitations of the public API. The risk is that you end up in a situation where every single release of Construct breaks hundreds of projects and causes constant chaos with rolling waves of breakages on every release. Normal users do not care whose fault it is when things break. They blame us, blame the product, leave negative reviews, and tell other people not to use it because it sucks and keeps breaking all the time. Sometimes addon developers even blame us because they do not understand the tradeoff. Avoiding that means stopping improving the product: no more bug fixes and no more features, so eventually the product ossifies and becomes uncompetitive. This has happened to us to some degree in the past, and we've seen it appear to happen to a couple of competitors over the years, sometimes with catastrophic consequences. Once you fall in to development hell it's already too late. The best approach is to avoid that outcome happening in the first place, at all costs.

    Calling a set of APIs "experimental" does not mitigate this risk. Someone might use those APIs, leave the community, then years later we change them, lots of people's projects break, and then we are forced to reverse the change, and accept we are no longer able to improve the product in the way we want to.

    The cost is a small and documented public API that we promise to support indefinitely. Relative to the risk of the failure of the entire product, that is not such a high cost to pay.

    We can and do increase the public API over time at the request of addon developers, but we have to think carefully about every addition - we know we are committing to still support that in 10 years time, possibly long after any developers who wrote code using it have left the community. We already do this kind of thing, as Construct 2 first came out in 2011, and we are still maintaining backwards compatibility with projects and from back then (this blog post includes a section on how adding a single seemingly obvious action led to significant work to maintain backwards compatibility, which illustrates the kind of complex work we occasionally do with the engine to avoid mass breakage). Even the C3 runtime alone is about 6 years old now, and we are still committed to supporting addons using the public API from ~2018 and will still be doing so in 2030 and beyond. When you've felt the pain of decisions made a decade ago, it gives you a new and deeper perspective on how to best manage an SDK.

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

  • You're wasting your time. Just use a HTTPS connection and everything is automatically encrypted on transmission and decrypted when received by the server. The Cryptography manual entry has a section on that ("HTTPS is already encrypted").

  • The SDK doesn't really support modules yet. It would probably be a lot of complicated work to make sure they are compiled/bundled properly on export (especially with no-minify mode) and have difficult compatibility implications (e.g. legacy file: protocol Cordova apps). However using dynamic import should work, or use the file dependency system to bundle a script (using the old-style browser script approach of adding to global variables instead).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Export as an Android Studio project, and then you can edit AndroidManifest.xml like you can with any other Android app.

  • I didn't mean to suggest object pooling via events isn't worth it - if you do want object recycling then that is the most efficient way to do it. However you'd probably be surprised how rarely you need to do such things. As Performance Tips says, the best thing to do is the most easy and obvious approach, and only optimize if necessary.

    Modern JavaScript GCs are very sophisticated. Generational collectors do make it especially cheap to handle short-lived objects (minor GC). However modern JS engine's major GCs are still parallel (using multiple CPU cores), incremental (running small jobs intermittently instead of one big stop-the-world pause to avoid jank), concurrent (running simultaneously with JS execution, preventing risk of jank), and also where possible schedule work in idle time to avoid interrupting smooth framerates. The V8 blog has some good entries talking about this, such as this 2019 blog post, and bear in mind there's been ~5 years more improvements since then. Overall the state of modern JS GCs is so good that I don't think I've seen any meaningful performance impact from GC in Construct games for a few years now. I just write modern engine code ignoring GC, and everyone's games are running perfectly smoothly, and where any problems come up, they are not because of GC. So, it feels pretty close to a solved problem really. I don't know if C#'s GC is as good - I would not be surprised if it was not as sophisticated, and so some people do have to code around it to some degree, but in my opinion that is not necessary with JS.

  • If you right-click the project name in the Project Bar and select Tools - View spritesheets, you can see the images that Construct is really loading. Since everything is placed on spritesheets, it may be that a new image is added and it increases the spritesheet size by more than the image size. Usually Construct will pack a range of images on to spritesheets to reduce any waste, but you can also tweak the memory impact of it by adjusting the max spritesheet size in Project Properties.