WackyToaster's Recent Forum Activity

  • Alright so I had some time to tinker a little bit more with it.

    - For my usecase which would probably be some kind of text adventure, this seems actually pretty ok to use. I don't know how unwieldy it gets if there's a ton of nodes.

    - On node enter does a lot of heavy lifting since most logic has to happen there. This would also include all the checks for "player health < 5...."

    - Branching is also possible with this by just adding a node that executes the branching logic on node enter and sends to the according next node

    - Some way to switch from flowchart node to associated triggers and back wouldn't be the worst idea

    One thing that I still think would be huge (this has been suggested already) are some kind of instance variables. 1. For the nodes themselves and 2. for each individual option. The current way to put extra data in is to add more outputs, even though the data is not an output. Imo this adds at the very least a bunch of visual clutter. It also has no way to associate the datapoints with the options. Something like "Option 1 has value 5 and Option 2 has value 10". I think this would fit in the properties bar just as it does for sprites. On the node, it could be hidden in some kind of dropdown, especially if you have many variables there.

    And I think it fits perfectly in line with the idea of flowcharts just being a type of data object. With the classic variable options to set/add/toggle/ + expressions 

    FlowchartController.currentNode.variablename
FlowchartController.currentNode.option("foobar").variablename

    Some other things I noted:

    - Reset flowchart does not trigger "on (any) node enter" though this might be by design (?)

    - I'd like to be able to resize nodes diagonally too. Right now it only allows horizontal or vertical.

    - Is there a way to access data from a specific node from anywhere? I don't see a way with something like a UID. Basically like a tag except tags can be non-unique so that might be an issue.

  • You can just use set text and reference the variable in the action. For example:

  • Oh yeah they can ! cool, I probably failed my input when i tried doing so on last update r370 (when we didn't have feedback for linking nodes)

    Pretty sure it was somewhat bugged because I also thought you can't have multiple inputs because it just didn't seem to work.

  • Wait is an action, not a condition. You'd put it where you have the sleep right now. Wait can be a bit tricky to get right for various reasons, which is why timers are usually recommendet.

  • Yeah I suppose that's what I gotta do. I just think it's kinda weird to implement it this way. I wish I could hack into the platform behavior and emit some event or something :I

  • I'm gonna give flowcharts a good try once the next beta drops that (presumably) fixes the crashes. I am arguing a little bit in the dark here because I have not yet actually build anything from the ground up or really at all.

    I have however exactly in mind what I would want to build and what functionality I'd want. So I'll attempt to do that and see what comes out of it.

    I'd personally be ok with keeping the logic in an eventsheet entirely BUT only if there's a good interface between the two.

    If there's one thing I can pick I'd want, it's anything that avoids having to glue flowcharts together at runtime. It's probably useful in some cases, but I'd want to avoid it as much as possible.

    If I look at a node, I have no idea if I glue a flowchart to it at some point or not. I can probably guess that I do, but I still have to check through the events to see which one. I'd rather have that connection already established in the flowchart view and be able to enable/disable this connection at will (checkbox in the flowchart view maybe?). It would be immediate visual feedback as to what's happening, rather than it being obscured in the eventsheets.

    In the same vein, branching connections would be important. If I think a coinflip, I really want to avoid having to do the 50:50, then glue the correct following node/flowchart to the out. I'd rather have this already visually connected and somehow communicate which path I want to take. Maybe something similar to function "set return value" there could be a "set branching value" which is than simply compared against when "go to next node" is called.

  • It's hard to say what exactly would be causing the issue just from this alone. It's probably some every tick, for loop thing. You can try disabling individual groups and see if the situation improves. If you disable a certain group and suddenly the game stops stuttering, it's pretty evident that something inside that group is causing the stuttering.

  • My concern : i have try the Array, reading and writing it on complexe data seem very troublesome.

    I have tinkered with data-driven stuff before and I always reached the conclusion that it's absolutely possible to do so, but doing it via Events is somewhat cumbersome.

    If you want to do it no-code, I'd probably recommend the json plugin.

    If you bite the bullet and use javascript, classes/subclasses and methods will be your friends, as well as json/array data.

  • It depends a little on the project and what you plan to do but it can absolutely make sense. But it's not strictly necessary, you can re-use the same eventsheet easily in multiple layouts, so if you prefer creating individual layouts and working entirely visually, that's fine.

    If you plan, for example, adding a level editor, creating levels from an array in the first place is probably much better. I also think it's a bit easier/cleaner to work with overall.

    For example, is there a Construct 3 command to draw squares with a solid color and border? Or, do I need to create 5 sprites (Start, End, Path, Open, and Blocked) and then dynamically write them to the layer?

    Technically you could probably use the canvas but don't bother. Just create the 5 sprites and/or use a tilemap.

    In my case I load an array like in this image, then do Array for each and create a bunch of sprites. It's quite easy since my game is based on a grid, so the coordinates are just array coordinates * gridsize.

  • It depends a little on how exactly it's set up but roughly:

    On start of layout

    Array for each Element X -> Create object (by name) Name:Array.At(Array.CurX,0), X: Array.At(Array.CurX,1), Y: Array.At(Array.CurX,2)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Our approach with flowcharts is, currently, as a data structure only.

    I have 2 cents in that regard. I've been more and more going into javascript and I'd say handling any kind of data structure, being array or json is so much easier and flexible in javascript.

    One big thing that Construct does very well are the visual editors. 2D/3D array editor, awesome. Flowchart editor, also awesome. Json, well that's just a text editor, but also perfectly fine. But manipulating these data structures in the context of the eventsheet... I dunno, either it just doesn't work for me or it actually is very cumbersome. Flowcharts are shaping up to be easily the most cumbersome data structure to handle in events. Although I have yet to properly test the usability since it's currently crashing a bit too much to test this.

    I don't exactly have a solution here, I just feel like that eventsheets are not that well suited for that type of data-driven work.

  • I don't think this needs a screenshot. Just add "For each Enemy" above the trigger once, that should do the trick.

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

wackytoaster.at

Trophy Case

  • 10-Year Club
  • 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
  • Coach One of your tutorials has over 1,000 readers
  • 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
  • RTFM Read the fabulous manual
  • x16
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x5
    Lightning Draw First person to up-vote a new Construct 3 release
  • x10
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

23/44
How to earn trophies

Blogs