Ashley's Forum Posts

  • You can use the 'Set canvas size' action. But it seems an odd thing to do, I assumed most games would always use the same viewport size.

  • If you're writing JavaScript code, why not just use the Instant Games SDK directly? There's no need to go via the built-in plugin.

  • It may never be a problem. Use the profiler to make measurements about what's actually performance intensive in your game, rather than guessing. Otherwise you're likely just wasting your time.

  • Do you mean using autocomplete? That's a feature of the editor, so it depends entirely on the features of whichever editor you're using.

    Note Construct's built-in editor has Construct-specific autocomplete based on its own APIs, such as listing runtime methods after typing runtime.. Other editors won't be able to do that, because they aren't specially designed for Construct's APIs.

  • LOS has always worked that way. It's a quick and simple design and it seems to be fine for the majority of uses, since it's worked like that for years and most people seem fine with that.

    Also, testing line of sight to any point on the collision mask isn't necessarily desirable. In many cases you don't want to count line of sight if only a tiny fraction of the collision mask is exposed. For example if only a tiny hair-width of the player is showing past a wall, should enemies count that as visible? If it works by any point on the collision polygon, the answer is yes, and then you get enemies that leap in to action chasing you down when the player is still basically hidden (and based on past experience people will probably file this as bugs thinking Construct is calculating this wrong). This then also breaks the symmetry of line-of-sight, meaning the enemies have line of sight to the player, but the player doesn't have line of sight to the enemies. You could also try to fix that by allowing any part of the player collision polygon to have line-of-sight to any part of the enemy collision polygon, but then you get even more absurd results, like a hairline edge of the player's shoulder being able to "see" a hairline edge of an enemy's shoulder counting as both objects having line-of-sight to each other. So then you could try to fix that by having some kind of way to configure the proportion of the area of the collision mask that counts as visible... and now you have a complicated feature that's hard to visualise, difficult for beginners to understand, and tricky to program.

    As with most features if you run all the way down the rabbit hole of the various details and edge cases, you end up with lots of complications, which in turn makes Construct more complex and difficult to understand. The main point of the product is to be simple and intuitive for beginners, so we avoid doing this wherever possible. As it stands, you can test line-of-sight to any position, so you could set up a few key image points around the edges of the object, and count it as visible if you have line of sight to any of those points. That's pretty straightforward, doesn't require any new features, and still more or less solves the problem.

  • Those screenshots don't show the full configuration since you also have to set up AdMob correctly too. See the documentation.

  • I tested ads recently and they worked correctly. Most reports of ads not working turn out to be users who have misconfigured them. So check they are correctly configured. If you still think the problem is with Construct, please file a bug following all the guidelines, since we need all that information to be able to help.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You can't request permission in 'On start of layout'. See the manual entry for it, you must use a user input trigger.

  • Thanks for the feedback, it's interesting to see people's thoughts on C3 especially in regards to the wider market.

    For what it's worth, from my perspective points 1 to 3 are basically feature requests, and I think at least 2 and 3 are already filed on our feature suggestion platform. These all sound great and only reason things like this are not already done is we're a very small team with limited resources, and we're also being asked for literally hundreds of other feature requests. I estimate there's about 10 years work logged on our feature suggestions platform, so we have to prioritise pretty ruthlessly. FYI suggestion 2 is probably best achieved through a layer tree rather than a flat list of layers, but as with many suggestions it's pretty complicated and we have to balance it with everything else.

    Suggestion 4 should already be possible. If you disable all behaviors, stop animations, and don't run any events involving an object, then the engine does virtually nothing with it. The only thing left that it does is a tiny check every frame to see if it's visible and on-screen for drawing. This is usually negligible, but if you have the unusual case of thousands of such objects scattered across the layout so that this check is using a measurable amount of CPU, then the render cells feature should fix that. It organises objects in to cells to organise their rendering and only check instances already near the screen. This brings the engine overhead of a far-away instance to exactly zero: the engine will do absolutely nothing with it, unless your own events do something.

  • Construct's event system is itself implemented in JavaScript. So JavaScript code can do everything the event system can and more. It's a strict superset. So there are lots of things you can do in JavaScript that aren't possible in events, such as using browser APIs that are not exposed in the event system.

    The main advantage of event blocks is they are very quick and easy to set up. There are things event blocks can do in a few clicks that could take you weeks and weeks of very difficult programming to achieve in JavaScript. So naturally it's a trade-off.

  • The manual isn't updated until the next stable release, and the Physics APIs are currently only available in beta releases. In the mean time you can use debugging in dev tools to explore the available APIs.

  • You need to request permission before using motion/orientation.

  • As ever, without a project to look at, all I can say is it should work, and if it doesn't, the error message it tells you is presumably correct in its diagnosis and you should do what it says.

    I also noticed that functions are global now, you can call them from any eventsheet even if they are not attached, is this by design or a bug?

    This is by design.

    • Post link icon

    This looks like a duplicate of this thread so closing. Posting the same thread is against the forum rules, please see the Forum & Community guidelines.

  • As I said, if you can reproduce a case where Construct seems to get it wrong, please file a bug following all the guidelines. It's the usual way that we deal with problems and the process is designed to maximize the chance we can fix the problem.