brushfe's Recent Forum Activity

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

    If so, it seems there'll be quite a gap between the expectations of this feature and the uses you're building it for (meaning it's setting up a lot of disappointment, looking like it does more than it does).

    If it's just a series data structures connected to each other in a linear fashion, couldn't each flowchart just be one big data table? If the nodes aren't going to have conditions/reactions between them, there's no need for all this big empty space between them. The arrows linking node to node could just be index numbers. And there would be no need for scrolling around, looking for a certain node's tiny title, etc; it's all just one big table (like an array, but with fixed content types in each cell).

  • Well said! It's incredible how many powerful tools have been released this year, and how simple they are to use. Plus all the community-built tools we're seeing now!

    Thank you for taking a moment to remind us all of that, and thanks to the whole Scirra team for such an exciting year!

  • To be honest, with the current set of features, i'm not sure why i would go with the Flowchart instead of the Arrays (or JSON). Because Array would also allow us to store any number of values ("unlimited column numbers", while Flowchart are just more retrictive and require to parse data contained in just a 3 values max - Name/Value/Tag, it means potential huge token list which are not always very pleasant to deal with).

    JSON would even allow us to nest and manipulate any amount of Data/arrays/Dictionaries for each nodes.

    So IMO right now Flowcharts compete with Data Plugins while they could become something new that synergize well with Eventsheets

    100%, this is also the conclusion I've come to. This is such an exciting feature, and it could be a truly great addition to Construct, but I wonder if it's being designed functionality-first instead of use-case-first.

    In the end, Nodes should a) improve workflow of existing methods (make it easier to do what users already can do in Construct); b) make it possible to create new methods with the same ease as Construct (FSM, Dialogue, Quests); or ideally c) both.

    That's probably obvious, but if superior workflow and additional capability can't be achieved with nodes in c3, nodes shouldn't exist in c3. There's been a few additions to construct that felt designed in an engineering bubble, and I really hope that all the amazing users here can guide nodes to a truly useful and powerful addition.

    It's amazing that this conversation is happening and there are so many great ideas being shared. I can't wait to see how it progresses!

  • An email just arrived about a sale something on my favourites list, despite already having purchased it.

    I didn't realize favourites lead to sale notifications; that seems like something for a wishlist. Or maybe favourites = wishlist on this store? I was using favourites to show support for great assets I'd already purchased.

  • Thanks very much for the clarification!

    The current setup does create a strange user experience: "layers" means something very different in the editor vs at runtime, but I'm not sure C3 users would ever think about it that way.

    Certainly for global layers, there's (currently) no reason to think that creating it dynamically would just be an empty layer with the same name. Up until runtime, using the name of a global layer overrides an empty layer and forces its objects into existence (which i think is the cause of the above expectation/confusion)

    But if that's the intent so far, it sounds like a feature suggestion should be made?

  • I just fell for the same thing... It seems dynamically created global layers don't create the objects on that layer?

    I can get it to work using the method mentioned above — for example:

    But it's a labour to have to manually recreate every single object with events (and keeping those events reflective of any future design changes to that layer).

    Unless I'm doing it wrong? Otherwise I'm not sure what the point of dynamically creating a global layer is, if not to bring the objects with it? (like how the editor does it, when you add a global layer to a layout)

    AVIX If you end up recreating another suggestion for this, please link it here!

  • Ah OK — it took me a while to develop the habit of switching from x/y to tileX/tileY. The Tilemap.PositionToTileX / Tilemap.PositionToTileY expressions are really useful for converting them.

    Good luck with your project!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Variables seem to work fine on my end (see below). Is this what you're trying to do?

  • There's a lot of different ways to achieve this, depending on your game's needs.

    To mark a level as completed, a simple way would be to create a series of global variables in your event sheet. These would be booleans, called "Level1Complete", "Level2Complete", etc. Because they're global variables, they'll retain their data from layout to layout.

    You could also create a Dictionary object, with keys named that way, and set to either 0 or 1. If there's going to be more information about each level you want to store, consider an Array instead of a Dictionary.

    However you choose to store these flags, you'll need to add a system condition called "On Start of Layout" in the event sheet for the level select. This only runs once, and it's useful setting things up before the user has control or sees anything.

    Now you can add sub-events to your On Start of Layout condition. Using the simple global booleans, you can add events to each one to see if it's true, then unlock the level if so (such as "If Level1Complete is True, destroy LevelIcon"). If you use a Dictionary or Array, you can do the same (and more) in a more elegant way.

    Hope that helps!

  • Let us know what you end up with! I'm sure a lot of people would love to know!

  • I have seen some games slow the player and camera speed while on stairs, to give the sense that they're climbing up or down. Sometimes it's coupled with a unique walk cycle animation. Food for thought!

  • Sure thing! Maybe your last idea could be accomplished by altering layer scale - check out the manual entry for more on that!

brushfe's avatar

brushfe

Member since 21 Jul, 2013

Twitter
brushfe has 2 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • RTFM Read the fabulous manual
  • x10
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x3
    Lightning Draw First person to up-vote a new Construct 3 release
  • x3
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

21/44
How to earn trophies