Ashley's Recent Forum Activity

  • Construct 3 works offline, and the way it does this is by always loading from the offline saved copy first. This means if the server is not reachable it can still start up just fine. It even means if you're online but the connection is super slow, it still starts instantly.

    Since it starts with the last-used version, if it spots an update is available it tells you, so you can hit reload and start using it right away. You don't have to manually opt-in to updates; if you ignore it and come back later, it will update on your next visit. It just tells you so you can update sooner than that if you want.

    (Beta releases use a slightly different update mechanism by the way - you have to opt-in to updates, but that's mainly because using a beta release requires visiting a URL that's locked to one version.)

  • For dealing with bug reports, please see the bug report requirements. So far there is nothing for me to investigate. If you provide your project I can try it out myself.

    • Post link icon

    I have read many C2 docs over the years and they were in general at an amateur level. My suggestion is that if you are charging "big boy" per annum prices, that you hire a trained tech writer

    I wrote the manual. I also wrote all of C2. Are you suggesting we get someone who didn't write the code, and doesn't know the inner workings, to write the manual instead? That hardly seems like a way to improve the quality of the manual.

    Also if you want to build APKs, you can always sign up to PhoneGap Build - the paid plan is also a subscription, and costs more than Construct 3, which provides a full game development IDE and a build system, at a cheaper price.

    Still, if you don't want to use Construct, you don't have to. If you think a different tool will better suit your needs you are welcome to go and use that instead.

    Anyways this thread is already too close to a totally unnecessary flamewar, so closing.

  • We only made runtime changes in r254. Are you sure it only started in that release? Are r253 or earlier affected?

    • Post link icon

    If you don't want to read the documentation, I guess it doesn't matter how well it's written!

  • My point is to expose those features and let JS-Dev's deal with depreciation or similar breaking changes.

    Generally they won't, though. Often they're not professional developers; sometimes they suddenly disappear forever and stop maintaining their plugins. Then if we break third-party plugins people get upset at us. Browser developers also still go to great lengths to maintain backwards compatibility and avoid unnecessary breakage, and even in the few cases they do break things, we're paid, full-time professional developers and can deal with it.

  • Heh, newt is right, the feature actually already exists: just use a large sprite and make your first condition "is overlapping sprite". That will efficiently reduce the list of instances to run the rest of the event on.

    Sure, you can make a test with 10,000 objects and measure all sorts of performance differences, but have you ever actually measured it making a difference to a real-world game? Most games use far fewer instances. Of all the projects I've ever debugged or profiled, people usually run in to GPU performance limits (a hardware limit) before CPU limits. I guess there are some special cases where a game really does involve 10,000 objects, but that's generally the exception, and then there are ways of reordering conditions to efficiently reduce how many instances you're testing against - e.g. using the overlapping sprite trick.

  • Time is our most limited resource. We are constantly working at full capacity on all sorts of things, including exciting and essential projects like the new C3 runtime, which nobody can develop apart from us.

    The SDK exists because we don't have time to implement all the features everyone wants. In acknowledgement of this, we allow third-party developers to come up with addons independently of us, so some ideas that we simply do not have the resources to implement, can be implemented by others.

    For this reason it's out of the question to expect us to do any sort of maintenance on third-party addons. To start with we don't have the time anyway, but on top of that, it's unfamiliar code often written in a radically different style to what we'd use, and being dragged in to maintaining third-party code defeats the whole reason the SDK exists, which is to allow development without our involvement.

    Third party developers can, and do, disappear at any time, for any reason. This has happened before, and will happen again. When you choose to use a third-party addon, you are entrusting any further maintenance and support for that addon to someone who may or may not be around in future. It should be common sense: you're making a trade-off between using a new feature that may be valuable to you, versus the uncertain level of support for that.

    If a third-party developer disappears at any time - and it could happen to any other developer, for any reason at all - then I'm afraid they're the ones who have left you out in the cold. But you should have been aware that was a possibility, and if your project is important, perhaps made some preparations for it. After all often these are volunteers working on addons in their spare time - do you expect the same level of support as a for-profit company with full-time professional developers? No, that's unreasonable. They do what they can when they feel like it. That's the deal.

    As I say it's happened before and will happen again. The problem is unreasonably expecting a professional level of support from third-party developers. If you are not aware of the deal you're making when you use a third-party addon, this is your wake-up call. Maybe you want to think a little bit more carefully about it next time you use a third-party addon.

    If you're missing any really crucial features that you've previously depended on third-party addons for, you can post them or vote on them here: https://construct3.ideas.aha.io

    Any really important ones we can build in as official features.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • TheRealDannyyy - I don't think you understand, that in engineering terms, undocumented features exist for a reason. As I mentioned in that other thread often it allows us to move quickly and make radical changes without the burden of backwards-compatibility dragging things down. So some features will remain undocumented for that reason. Again, all products have undocumented features, and experienced engineers know not to rely on them or at least not to expect any support for them - this is not controversial or new. We're actually in general more closely aligning ourselves with the industry standard approach. Outside of that though, we will make sure we document as much as possible.

  • Your projects do not disappear if your C3 subscription expires. You can still open them, preview them, export artwork and other assets etc. It's only the ability to edit them that expires.

    Also, many existing C2 tutorials should be straightforward to apply to C3 as well - the UIs are generally similar.

  • It also looks perfectly smooth here. The engine is not doing any significant amount of work. So I would guess this is just a system v-sync issue. It's been discussed a lot on the forum already if you search.

  • The ^ operator calls Math.pow() which might be as slow as Math.sqrt(), I'm not sure. For best performance I just use value*value.

    If you profile a snippet of JavaScript vs. doing that in events, then yeah, events have a performance overhead. As with any higher level abstraction it tends to come with a performance cost, just like how Python tends to be slower than C. That's pretty much unavoidable, it's just how these things work. Most of the time though, it doesn't matter. It's only if you're doing something thousands of times every tick that you'll be able to measure a difference, and even then, will it actually affect a real-world game? Probably not - so I'd guess that writing a behavior to make a bunch of specific tests is not necessary. Also most of the usual suspects for performance are already highly optimised as internal code, such as collision detection and pathfinding.

    Exposing collision cells to events is an interesting idea - I think we could do something like "pick instances in rectangle area" without having to iterate all instances.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,773,387 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
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    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
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs