Ashley's Recent Forum Activity

  • I just tried an iOS build and it worked fine. I haven't seen any other reports of issues either. I'd advise filing an issue following all the guidelines if you have trouble.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,447,910 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x63
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs