Ashley's Forum Posts

  • Construct 2 support ended in 2021 (see this blog). However the multiplayer feature should still work so long as browsers remain backwards compatible with it, and Construct 3 uses the same signalling server so that is still running too.

  • A flat data table can't easily represent tree structures. Sure, you can write something like JSON if you want, but that's not particularly accessible to beginners or non-technical people, which is largely the point of the event sheet system.

    I'm not sure how a "node event sheet" is any different to just triggering "on node enter" with the same tag? You still end up putting your logic in a different event sheet. With some tools like a context menu to switch between the node and its trigger (similar to find all references/go to function for functions) hopefully it should be reasonably easy to switch between the flowchart and its corresponding logic.

    I think people are also seriously underestimating the downsides of having different places to put logic. If you have 100 flowcharts encompassing 5000 nodes, with bits of event logic distributed all across them, and then you find something isn't working right... how do you even begin to sort that out? You could easily spend hours just trying to figure out which part you ought to be looking at. Keeping things in the same set of event sheets might seem like an inconvenience, but IMO it's actually far better for scalability and organising larger projects.

  • I'd guess it's an oversight, as nobody ever needed to dynamically change the layer rendering mode before. It'd be best to post it as a suggestion.

  • You can change whether JavaScript runs in a Web Worker or in the DOM (main thread) with the 'Use worker' project property.

  • I remember 11 years ago when the Scirra staff said they discourage the use of flowcharts in programming, saying that “they are really inefficient with space, and you quickly end up with a unwieldy spaghetti which hurts more than it helps”, and now they’ve implemented them. I’m curious what changed their minds.

    I don't think flowcharts work well for game logic. You tend to end up with what looks like a big pile of spaghetti, and the two-dimensional scrolling makes it hard to review and change. Our approach with flowcharts is, currently, as a data structure only. This is suitable for things like conversation trees which are typically structured in an ordered way, and game logic stays in the Event Sheet View (or coding). I think this is a good way to bring the benefits of a visual designer for tree-like structures without the downsides of spaghetti-logic.

  • Thanks for the kind words! We might be a small team but we're working hard to make Construct great 😀

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • As noted in the manual, starting a download is a browser-only feature, and it doesn't work in mobile apps which aren't a full browser. You can try using the Share plugin instead.

  • Give a keyframe a unique tag, and then use the Timeline Controller 'On keyframe reached' trigger to run some actions when the timeline reaches that keyframe.

  • The layout size is basically how big the level is. It's the editing area in the Layout View and the default scrollable area.

    Construct defaults the layout size to twice the viewport size, because if the layout size is the same size as the viewport size, then by default you can't scroll anywhere. That resulted in a lot of beginners asking "why doesn't my game scroll", so the default is to provide a scrollable area.

  • Use the IStorage JavaScript API to integrate custom code with the Local Storage object's data.

    The database is only created on demand, so if you delete it, it won't come back until it attempts to write new data.

  • would a possible solution be to restrict this to just being able to trigger Functions in nodes?

    I think that is already possible with 'On tagged node change' in the Flowchart Controller object. Give the node a unique tag, and then that trigger fires when the node is reached, where you can then place any special logic for it. (Correct me if I'm wrong @DiegoM)

  • You can change the classes (and pretty much anything else) in already-loaded HTML with the JavaScript DOM APIs. In this case classList can be used to change an element's classes. For example: 

    const myElem = document.getElementById("myElem");
myElem.classList.remove("oldClass");
myElem.classList.add("newClass");

  • Why are you trying to use <body> tags? In HTML a document should only have one body tag, which contains everything in the entire document. You should be using a different tag like <div> anyway.

  • Well, like most web specs it is written by WHATWG or W3C (I forget what the exact relationship between them is), and usually devised by browser makers and interested third parties. The Pointer Events spec was originally written several years ago now. This part of the spec seems to be relevant to how holding mouse buttons work (they call them "chorded button interactions").

    I guess conceptually they consider a mouse a single pointer device and so something that can only go down or up once, similar to how a pen device goes down or up (making and releasing contact with the screen) separately to its button press state. But I don't think it's actually very intuitive for a mouse - as developers you just want an event when each button is pressed. It was annoying for developing Construct too.

  • The blog is from 2013 so parts of it, like the reference to a 256mb VRAM graphics card, is out of date! It's overall point is still relevant though: composition is better than large images.

    You could go a lot further with large images on modern systems, and unified memory systems are more prevalent these days (where there is no separate VRAM and the GPU re-uses system memory, perhaps with an additional dedicated cache). However it still won't scale: no matter how many gigabytes of memory you're willing to use, composition can extend to essentially an unlimited extent, whereas a single drawn image will exhaust memory at a far smaller size, so it imposes tighter limits on the level size. Then there's the fact you have to split everything up in to tiles to work around the maximum texture size (4096x4096 tiles for best compatibility) which is inconvenient. A single tile at 4096x4096 is about 67 MB in memory. If you make a 10x10 grid of them (approx 40k x 40k pixels) you have already used well over 6 GB of memory, so your game will probably already crash on systems with 6GB RAM or less, and that's not including the memory requirement of everything else in your game. With composition you could make a same size level probably well within 500 MB RAM. It would probably render faster too as there'd be less pressure on GPU memory.

    Realistically for broad compatibility I'd avoid going over 1 GB RAM for the background alone, which as you noted limits you to about 4x4 tiles of 4096x4096, or approx 16k x 16k pixels. I suppose that could be enough for some games. So perhaps it is a somewhat more viable option these days within reasonable limits. However I wouldn't be at all surprised if it runs poorly, especially on weaker devices; if it's at all possible to achieve the same by composition, it's far more efficient, both on memory use and runtime performance. It also depends on how willing you are to have demanding system requirements for gamer-style GPUs with loads of dedicated memory, or compatibility with mobile devices and general web browsing.