Ashley's Recent Forum Activity

    This sounds like you're trying to circumvent Construct's free edition restrictions, so closing the thread.

    The HTML export is not designed to run in an Android app. Use the Android exporter instead.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,383,476 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