Ashley's Recent Forum Activity

  • I think you can work around this on the latest versions of NW.js by turning off worker mode in advanced project properties.

  • LOS only casts a single ray to the given position. If you test LOS to an object it only checks the object origin position.

    Testing if the whole shape or any part of the shape has LOS is tricky - you have to cast multiple rays across the object to check if any part of it is visible; for a 100% accurate version you'd need to cast an extremely high number of rays which would kill performance; and for high performance you need to cast as few rays as possible, which means certain size gaps or overhangs will not be counted as visible even though they would be with a 100% accurate system. So there is a performance/accuracy tradeoff there. The LOS behavior gives you the single ray primitive so you can build your own logic that makes your own tradeoff about how to detect larger objects. One simple scheme is to add a few image points around the edges of the object and check if there is LOS to any of those. There will still be edge cases where the object is not counted as visible when it is though.

  • The usual way to do this is an action to load a string of JSON data.

  • Don't put a wait before trying to open a new browser window, or the browser popup blocker might block it. You should only attempt to open new browser windows directly in a user input trigger without any waits.

  • Just thought of another option - if you can make a tiny macOS universal app that just detects if it's Intel or Apple Silicon, and then launches one of two other bundled apps, then you can point Steam at the launcher app and it will launch the right one.

  • I have yet to see a solution in C3 that doesn't slow my high-end PC to a crawl at 200ish instances even with nothing else happening.

    Can you share a project file that demonstrates the performance problem of doing something like this? It would be interesting to profile and experiment with it. Perhaps just using a smaller collision cell size would make it OK.

    A problem with making built-in quadtrees is Construct's collision engine needs to extend over an unlimited area (e.g. still handling activity outside the layout area, or with unbounded scrolling). Collision cells can do that with sparse cells. I'm not sure quadtrees can handle that.

  • There's eval(), but it's generally regarded as unsafe and sometimes security measures block it from working.

    You can also load a new script file with dynamic content. As Construct uses modules, you can dynamic import a custom script like this: 

    const scriptContent = `console.log("Hello world!");`;
const scriptUrl = URL.createObjectURL(new Blob([scriptContent], { type: "text/javascript" }));
await import(scriptUrl);

  • Huh, that's weird. These days I generally just upload to Dropbox and share a link - it seems to be a lot more reliable. There's lots of other things that can go wrong with email attachments, particularly low size limits.

  • It looks like Electron universal is a tool that essentially glues an Intel and an Apple Silicion app together in to one - if you're lucky it might work out of the box on NW.js, or perhaps it can be adapted to work with NW.js.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's cool to see a quadtree implementation working in Construct! One of the reasons we added JavaScript coding is to open up advanced uses like this.

    I've been cooking a bit since I noticed that javascript testOverlap() does not benefit from collision cells.

    FWIW collision cells are not actually applicable to testOverlap(): the point is to eliminate even checking instances, so it is basically a filtering system that efficiently reduces the set of instances that you might call testOverlap() on. So it is not possible to implement collision cells within the testOverlap() method itself, it's something that has to come before it. Your quadtree implementation essentially takes the role of collision cells when checking collisions in event sheets - it's an alternative system of filtering the instances you check collisions for.

  • There isn't always a simple example snippet to show. A realistic example of static conditions might involve hundreds of lines of code for a niche use-case that most people don't even need. It's kind of a complicated escape-hatch for when the usual picking algorithms aren't appropriate. My point is Unity can throw dozens of staff at such things, but it's difficult for us to justify. The other alternative for us is just to not document stuff like that and leave it as unsupported engine internals. Then at least people won't wonder what it means or how to use it, but I'm not sure that's preferable.

    If I download the full Construct manual it currently comes in at around 900 pages. It's a huge body of work, and "just sprinkle some examples all the way through" is probably a major project that would take weeks.

    Being a smaller company I think we have to rely on our community more than huge companies that can just throw loads of staff at something. For example there's no way we can possibly do our own Construct integration for all the third-party services out there - it's year's worth of work. So we have an addon SDK so third-party developers can potentially do it themselves without having to wait for us to get round to it. I think it's a similar situation with documentation - if you want tutorials for specific kinds of games, useful code snippets for specific features, demonstrations of useful approaches and algorithms, then we have a public tutorials system for that too, so the community can share their knowledge rather than relying on our already-stretched team to provide everything. To be clear, that's not an excuse for us to have inadequate documentation - I think we do a good job with the resources we have available - but when it comes to samples, guides, tutorials etc. there's just an endless array of things to be covered, it all takes a great deal of work to do well, and the fact is we're a small team.

  • I'm not sure what more there is to add to that documentation - normal conditions are run once per instance, static conditions are run once only regardless of the number of instances, and that's about it. Normally you don't need them, so you can probably just ignore that they even exist most of the time.

    A billion-dollar company with thousands of staff can probably afford to have hundreds of people working on documentation alone, which is many times more than the entire size of our company dedicated solely to documentation. So while we want to have good documentation, I don't think "why aren't you doing well as Unity" is really a fair point to make. In fact I think it's a sign of how extraordinarily well we've been able to leverage web technology that you can even mention us in the same sentence as them with a straight face.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,383,852 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
  • x107
    Coach One of your tutorials has over 1,000 readers
  • x61
    Educator One of your tutorials has over 10,000 readers
  • x2
    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
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs