Ashley's Forum Posts

  • It's difficult to manage the suggestions platform - I estimate there's already about 10 years of work on there and people are still adding more regularly. As a small team with limited resources, even administrating it could be a huge amount of work. For example even just commenting on every suggestion would be a massive job and probably take a week or two at the expense of everything else we have to do, especially since in many cases even a brief comment covering the feasibility could involve reviewing lots of source code, architecture, and thinking about how it could fit in with existing systems. Similarly adjusting the processes could be tricky, and we also have to work within the confines of what Aha's system supports. I think picking a subset of users to review or curate suggestions could also prove unpopular as it essentially creates an elite few who get more control over the product, which kind of defeats the purpose of the system as trying to identify what most people want. There's also occasional cases of ballot-stuffing too so I'm pretty sure whatever we set up, people will try to game it.

    It would indeed work a lot better if people shift most of their votes to small/quick/easy things, which ideally would get done quickly, and allow the votes to be shifted to the next easiest thing. I have suggested people do that several times, but naturally a lot of votes go for big and potentially exciting projects, which are the very hardest and most time consuming to do.

    I'm not sure there's any good answers here. Periodically we take a look and do anything that looks particularly quick and easy. However given our limited resources and the amount of time that we have to spend on things like support, reviewing bug reports, maintenance, administration and so on, we don't have a huge amount of time to spend on new stuff to begin with. And every new feature, even small ones, tend to require several weeks to go through implementation, adjustments and bug fixes through a few beta releases, and then long-term on-going maintenance as the long tail of bug reports rolls in, and even later down the line when rewriting or upgrading existing code.

  • It's difficult to imagine a useful feature where you manually choose a spritesheet, because all spritesheets are dynamically created on-the-fly and they could be completely rearranged with even a small change. Pinning sprites to a specific sheet could also even result in even less optimal results, since it removes Construct's flexibility to later group the sprite with a better sheet.

    Does this actually have any meaningful impact on the memory use of your game? It's unlikely any automatic spritesheeting algorithm will ever be perfect, and manual intervention could make things worse. So one or two spritesheets that aren't ideal may be an acceptable result.

  • If Construct randomly closes that suggests the browser crashed, not Construct. Normally web pages can't close the browser themselves even if the page's logic crashes, since that just logs an error to the browser console.

    As for why the browser might crash, I can only speculate, but graphics driver problems is a common cause of stability issues.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct uses the placement of objects on layouts as a way to group objects that are used on layouts together on to the same spritesheet. So which layouts are these objects used on? If none of them are used on the same layout then perhaps there's something could be improved in the way Construct analyses this. However it might be something else, like relying on dynamically creating objects at runtime without them being placed in the layout, in which case Construct can't analyse which objects are used together. As ever it's easier to comment if there's a sample project provided.

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

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