Ashley's Forum Posts

  • - Pick output based on conditions proper to each possible output nodes

    An 'On node entered' trigger, with subevents with actions to choose which output to go to.

    - Having a specific dialogue node that wait X second before executing the regular Dialogue node condition logic

    An 'On node entered' trigger, with a wait action before going to the output. (You could for example have a "wait" node with the same tag in multiple places, and re-use it.)

    - Playing different sounds, or putting different actions in every single nodes (let's say you have 5000 nodes as you suggested)

    Have an output with a string of the sound to play, e.g. output name "PlayAudio" with value "SFX5", and in 'On node entered', if an output "PlayAudio" exists, play the sound in its value.

    - Having multiple value to handle for each node (avatar image, avatar animation, text animation, related QuestID, including variables within the actual Dialogue text)

    Outputs are also designed to store data, such as in the prior example I gave, where the sound to play is stored in the node. You can use multiple key-values, essentially using each node as a small Dictionary storage.

    So I think all that can be done with the current design. I think it will take some time for people to use it and get familiar with how it works and the patterns you can use with it. Maybe some things will turn out to be a headache to implement, but I think at the moment things are very speculative and everyone needs to try things out in practice and then give us feedback for real-world uses. We also have lots of improvements in the pipeline so the way it is right now isn't necessarily its final form.

  • We've found even old mobile devices perform very well as modern web technology, Construct, and mobile hardware, are so good these days. If your game is crashing when it gets past the menu, it may be running out of memory. See Memory usage in the manual for some tips.

  • One of the fundamental tradeoffs of spritesheeting is it bundles images together and can only load them all at once. You can change the maximum spritesheet size in Project Properties - smaller sizes will tend to fragment things in to more spritesheets and so avoid having to load other content, but ironically it can also increase the download size. Large spritesheets allow image compression to remove repeated image content and so can be better for reducing the download size. At the extreme you can disable spritesheeting (in the latest beta) which will load precisely the right content, but also make it a much bigger download. So you may be trading off showing the loader layout sooner, for showing the loader layout longer. Spritesheeting is full of tricky tradeoffs like this.

    If your entire game is only 6mb, I don't think there's much benefit to using a loader layout anyway - these days the average web page is over a 2mb download, so about three times the size of a web page probably isn't that long a download for most people.

  • 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");