Ashley's Forum Posts

  • It does work. See tips for this forum

  • Invoking a download uses the browser's download UI. In an APK there is no browser UI, so invoking downloads doesn't work.

    Snapshots should still work fine, you just need to find a different way to use them.

  • Because Construct 3 supports Z elevation, zoom is implemented as moving the camera on the Z axis, and 3D rendering requires a far plane (i.e. a maximum draw distance). Consequently while you can zoom to any value, you cannot draw objects at an unlimited distance away from the camera; so if you rely on extremely large objects extremely far away, they may in fact disappear. However I think this is an extreme way to design a game and there are probably alternative ways of getting the same effect without using such extremes.

  • This sounds like a bug we already fixed. Are you using the latest beta? It will be hard to help any further without a full bug report that reproduces in the latest release.

  • There are lots of technical complications involving Z depth (affecting the Z elevation feature), far-plane culling, floating point precision and more. This is not at all a simple change.

  • Wulfy already gave you the right answer. I just tried it and it works.

  • As far as we can tell, only a tiny fraction of Construct users are actually publishing to Xbox, which Construct does support (at no extra cost, I'd add). That's not to say it's not important - often those that do have the best games - but I think that actually this idea that most devs publish to consoles is not accurate (at least when talking relative to the entire userbase of Construct). I get the impression most devs aren't actually actively publishing to console, just they want the option. They're essentially asking themselves "what if my game does turn in to a success? Will it then be easy to take it further?" This is a reasonable question to ask - it's essentially planning for success, which is a good business consideration.

    However this then ends up with a slightly odd situation that everyone wants console exports, but very few people actually use them. It's a difficult situation to do something about because it seems likely that actually making console exports is uneconomical. Consider just how expensive the console exports are for YoYo Games, even with a much bigger staff, more funding and presumably more customers...

    Meanwhile there are third-party porting companies out there like Chowdren who are already successfully porting Construct games to consoles. I also think one of the reasons we don't see much usage of Construct's own Xbox export option is because people who go to third parties to cover consoles tend to throw in an Xbox port while they're at it. This also suggests that unless we cover all console export options - the most difficult and expensive option of all - then in practice a lot of people still won't use them, reducing a small userbase even further.

    So I think the main impact of the console export aspect comes down largely to perception. Also trying to solve it ourselves could prove very costly, especially as a small company playing the single-codebase card to great effect - and then there may well end up being very few people who use it. I think the best thing we could do about that is find a way to partner more closely with third-parties who can port Construct games to console. That's something we're thinking some more about and we've already had some conversations about it. It could be that there's little awareness that option even exists for Construct, and more people would choose us if they knew about it.

  • If you have images so large that you need extra zoom levels to view them, you will have so far exceeded the maximum texture size that no devices will be able to load the game.

    Construct warns you if you try to export a game with an image over 4096x4096, because that is the largest widely-supported size.

  • I think that the fact that Construct 2/3 does not generate an exe (it does not do it without NWjs) and has to rely on external technologies has some importance.

    Actually, I think this is part of the reason we've been successful. It's hard to tell but I'd guess YoYo Games have about 10x as many staff/developers as we do - but we are perfectly capable of keeping up, or even overtaking them (we're shipping timelines before their equivalent, for example). A huge part of the reason we can keep up while being far smaller is because we have a single codebase, and use HTML5 for everything. Also while the technology has certainly had its quirks in the past (especially when we started in 2011 and it was seen as a big gamble), these days the tech is working fantastically. People publish NW.js games to Steam and I don't think any players notice the difference.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Browser extensions can run on any page and do pretty much anything. They've proven a pain for the Construct editor itself, since they often break things too. There's not a lot you can do about it, other than add some basic anti-automation features.

  • I think the main reason for the difference is most Construct users don't sign up to the reddit page. I wouldn't draw too many conclusions from the number of followers on social media (especially since some companies pay to increase their follower counts)

  • In that case I would assume the user will call a "Pause" function where they implement their pause system in events. If your addon needs to do something to respond to a pause, this can then just be a "set paused" action in that function.

    I think if you try to pre-empt it with different built-in mechanisms, you actually end up with a less flexible approach. Events are the way to customise your game's logic, addons shouldn't try to short-circuit that.

    If you're integrating with your own addons, I'd recommend simply calling internal class methods instead. There's no need to drag the event actions logic in to it. A nice architecture (which many built-in addons use) is actions actually just call methods on the instance class, and then any other logic that needs to re-use that function can just call a normal instance method, rather than trying to bodge in a call to an action. Basically for internal stuff you can easily bypass the entire event system, and it makes your code nicer.

    Lots of addon developers seem to want to hack around with the event system - generally I think that causes more problems than it solves...

  • If you are developing an addon in developer mode like the SDK documentation recommends, you can also simply fix the problem and reload the editor.

  • I assume you're still using the C2 runtime? The C3 runtime doesn't support IE.

    Storage in the C2 runtime should work on IE. If it doesn't, please file a bug following all the guidelines.

  • This is specifically not supported because it's generally a terrible idea:

    • Nothing else in Construct works this way, so it's confusing to users
    • It hides logic behind "magic" behavior when it could be clear and straightforward events
    • It's brittle and inflexible because it has a hard-coded kind of action/condition to trigger - the user can't choose to do something else, or use a different kind of plugin
    • When using other addons, you end up taking an unnecessary dependency on an external addon - now you're subject to any backwards-incompatible changes or deprecation that may happen to that addon in the long term

    In particular, the last point is problematic - sometimes developers hack in poorly-thought-out features involving official addons, then we change them over time (e.g. deprecating them as we replace them with better features), and now the addon developer has a real headache as they need to figure out how to change their addon, which may in turn cause a backwards-compatibility problem for users of their addon.

    Just fire a trigger in your addon. Users can put whatever events they want in that. It's simpler, and avoids all these problems.