Ashley's Forum Posts

  • As fewer browsers support Ogg than WebM, if Construct exported Ogg, it would cause worse compatibility issues for publishing your project. WebM Opus is near-universally supported by all browsers now, and after years of resistance from Apple, is the only free and open audio codec to reach that point.

  • It sounds like you are using an exceptionally large amount of images. See the manual guide on memory usage - if you're doing something very inefficient you can quite often easily reduce the memory usage by 50-75%.

  • I don't see how changing when the suspend happens changes anything about what happens when it suspends. If you want to do something custom when the game suspends, use the system 'On suspended' trigger.

  • There's no limit and I can't think of any downside to having a lot of them other than it might be hard to organize if you have, say, hundreds of them.

  • When I move to macOS for some testing I always end up getting the email client too, but it's because it's a different shortcut. Make sure you're really pressing the right keys and not something like control instead of command!

  • There is also a known issue with WebGPU that rendering fails on Intel Gen12 LP GPUs. See this issue.

  • I apologise for the confusion over "obfuscation" versus "encapsulation". These are different things. Writing long posts about deeply technical topics across all sorts of areas is difficult and I'm only human and can make mistakes or phrase things badly sometimes.

    I am interpreting "obfuscation" as doing something like minifying the entire runtime source code with Google Closure Compiler. This will do things like rename parameters and variables in methods. It does nothing to prevent people accessing internal APIs. To that extent, it doesn't seem relevant to this conversation.

    Encapsulation means blocking off internal details to make them inaccessible unless used through the documented API. This is the main thing I'm talking about here and is the main concern as it has backwards compatibility implications.

    I'm not sure why anyone would be concerned about obfuscation. The main topic of conversation seems to be about encapsulation, as it blocks off access to the internal engine, whereas obfuscation does not by itself necessarily do that.

    However, we reserve the right to use obfuscation. In fact I think we used to, and then for complicated technical reasons had to change that. We might change it back. You should plan accordingly, as per our long-standing warning.

    I would point out this long-standing warning has always made it clear undocumented features could be removed at any time. Use of undocumented features is at the addon developer's risk. Nobody else can be held responsible for the consequences other than them. We could remove all undocumented features in the next release, and say "tough luck, we warned you". To those of you saying people with access to the source code know what they are doing and understand the risks they are taking... this is a similar situation, we warned people, we are going to do it, and now people seem to take issue with the fact the thing we warned them would happen is going to happen. It puts us in a very difficult situation. It's also why I'm very skeptical of any more "don't worry, it'll be fine, people will understand" type solutions when this has clearly failed in this case.

    So, as I said before, we are not actually going to remove all undocumented features in the next release. However we will move forwards with a plan for a v2 SDK over the next year or two, which should give enough time to design a suitable SDK and deal with the inevitable difficult backwards compatibility issues that come up. Let me be clear: we did not have to do this, as we reserved the right to say "tough luck". However as it is clear this is untenable and obviously unpopular, we are promising to do the necessary work to make sure this transition goes smoothly. This does mean designing a new API in co-operation with the addon developer community, and I would hope this ultimately ends up a comprehensive, capable API that does pretty much everything addon developers could reasonably want to do, short of unfettered access to the internal engine. I would ask for co-operation during that process so we can end up with a reliable, robust, maintainable SDK in the long run, and not the risk of disaster that we are constantly running at the moment.

  • I am not sure about the technical feasibility of that. It sounds very complicated indeed, and getting a better answer would require quite a lot of research work.

  • While we are arguing for days why we don't want Construct to be even further black boxed, the creator and technical lead of Godot just started a Youtube series where he explain in details the Engine internals.

    Once again, repeating myself, source code is not an API. We are talking here about an extensibility system where a first-party codebase interacts with separately installed third-party modules through a defined interface with encapsulation. There's that, and then there's getting a copy of the entire codebase in a game engine, which is something entirely different.

    So you guarantee the runtime will never be obfuscated like the Editor SDK ? Just better encapsulation but everything will still be readable for us ?

    I haven't been talking about obfuscation here, only encapsulation. I am not sure where you got the obfuscation point from. Even so, as the warning has always said - we reserve the right to change undocumented features at any time. So the very purpose of the warning is to say "we might do that, and take the possibility seriously".

    isn't the best way to deal with it is to FIRST make improvements to the SDK with an active cooperation with 3rd party dev during several months/years and only then starting to progressively encapsulating ?

    No, because the current SDK is unmaintainable and risks disaster, and the longer it is used, the greater the risk.

    Add a license to get an unecapsulated version of C3.

    I think this thread has shown, if we say "don't do XYZ, it's unsupported and we won't help you", in the end people do it anyway and then still expect us to help them. We had a warning specifically reserving the right to change and remove all undocumented features at any time and say "tough luck" to those affected, but in the end, in practice, doing so is not feasible because of the backlash, and we are going to have to go to great lengths to avoid the consequences of doing the very thing we warned we might do - an outcome the warning was also meant to avoid. In practice saying "this is not supported" is not realistic as at the end of the day customers facing disaster end up begging us for help anyway, and we usually still try to help them because are we just going to refuse to help them finish a project they had been working on for years? So the commercial reality of running a business like ours is you end up helping everyone anyway, even if they did things you specifically warned against; the only way to prevent that happening is to enforce it with measures like encapsulation that make it as hard as possible to get to the internals and prevent anyone doing the unsupported stuff in the first place.

    Some companies provide source code. Good luck to them - it sounds like a nightmare to me. Perhaps they just have enough staff to support the desperate customers who get themselves in to a huge mess, or maybe they really do just say "tough luck", but I don't know how they would get away with that in practice. If you decide you absolutely require access to source code for your game, then perhaps Construct is not the right tool for you - there are tools out there which provide that, and it's not something we intend to do for Construct. We do intend to have a public, documented, supported API with encapsulation though, which anyone can do anything they like with, and we promise to support indefinitely.

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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