Visual branching passage system

0 favourites
From the Asset Store
This music pack covers differents situations for visual novels, anime games and many more!
  • Something that would make me buy Construct 3 subcription in an instant:

    If Concstruct 3 has a built in the editor a visual branching system, where you can place passages, just like in Twine.

    To make rpg/text adventure/adventure game/visual novel style games.

    Built in the editor itself, and would work from get go, without importing stuff.

    How does it look like?

    It looks like a flowchart system!

    rpgmaker.net/media/content/games/6568/screenshots/mossy_stone_editor_shot.png

    Imagine having this in C3!

  • I imagined it, and gagged a little. I'm here almost specifically because Construct DOESN'T use a scene graph based system. It's pretty common in other engines though, and I understand how it can be more intuitive to other people. Maybe just learn and use another engine if your preference is that over the event sheet system.

  • I prototyped an idea I had about this a while ago, unfortunately I lost my file so I can't share it here. But the basic idea is to have a layout per scene, and each layout has a series of parented text boxes with properties like "Actor", "Animation", "BGimage", etc. The actual dialogue is sourced from the text box's text, which uses custom tags to take the user to the relevant text box and/or perform defined actions.

    Dialogue flows up or down the heirachy chain depending on defined interactions. It worked okay; definitely requires some effort to build but it's a system that could no-doubt be built to do what you need.

    IMO, you're better off building a branching dialogue system using JSON. Similar approaches have been the standard for dialogue-driven interactions in games since such things existed, and only in more recent years have node-based approaches taken off. It's also much easier to translate file-based than node-based dialogue.

    I suggest you check out Laura_D's tutorial series on implementing a JSON-based dialogue system: construct.net/en/tutorials/introduction-json-dialogue-2331

  • IMO, you're better off building a branching dialogue system using JSON. Similar approaches have been the standard for dialogue-driven interactions in games since such things existed, and only in more recent years have node-based approaches taken off. It's also much easier to translate file-based than node-based dialogue.

    I suggest you check out Laura_D's tutorial series on implementing a JSON-based dialogue system: construct.net/en/tutorials/introduction-json-dialogue-2331

    Where's the visual component of that system? I feel a linear text is bad to visualize the branching.

    Also what if you need to work in more turns in mid somewhere?

    I am not sure if it is like this in this tutorial but usually they want you to number the text flow, and if you need to patch in more dialog, you have to rework the entire thing, including in construct.

    But even not then,

    Lots of going back and forth with referencing when someone said this and that...

    By then it would even be simpler to just write in the dialog raw in construct.... At least you will see what you get. Even in a very linear, non branched way. hm. idk.

  • I imagined it, and gagged a little. I'm here almost specifically because Construct DOESN'T use a scene graph based system. It's pretty common in other engines though, and I understand how it can be more intuitive to other people. Maybe just learn and use another engine if your preference is that over the event sheet system.

    I am not talking about replacing Construct's event system.

    I just wanted a visual tree for the dialog aspect of the game.

    Why would it be gagworthy? It is very nice and clear way to show how people talk and do branching from there.

    How would you make a visual novel with 1000s of dialogue, with lots and lots of spaghettis going everywhere?

  • Nono it's just I've had past experiences with scene graphs that got way out of hand and unmanageable, so I just don't like them myself. There are other softwares that do visual novels and branching dialogue much better than construct.

  • I built a dialogue system with an array that i load into a dictionary which makes it somewhat visual using the array editor but i don't really have anything branching. Maybe looking into the Ink Language could help and there seems to be a plugin for that in Construct:

    construct.net/en/make-games/addons/518/ink

    Otherwise, i too think JSON is probably your best bet. It takes a moment getting used to but it's really not hard although i prefer to have my dialogue in a spreadsheet kinda way so that's why i'm using arrays but, as mentioned, i load that in to a dictionary so i can access specific keys directly rather than looping through a huge array every time i want to call upon a dialogue.

  • I think dialogue designer comes close to what you are after.

    https://www.construct.net/en/tutorials/dialogue-designer-construct-2624

  • In my view these flowchart systems look like they work well for simple cases, but for more complex cases you end up with a pile of spaghetti and endless scrolling which makes it hard to even find anything. I doubt it would be easy to track dialogue in this type of system if you had a novel-sized amount of content (e.g. 300+ pages, 80,000 words). You'd have a huge scroll distance and everything scattered over an enormous area with incredibly long lines joining tiny fragments of text.

    For more complex cases a linearly-written approach may work better, with the branching done conceptually. The way event blocks work is analogous. Events, conditions, actions, functions etc. all conceptually branch and could be represented as a flowchart system. However keeping it in a single list actually makes it much easier to work with when you end up with a large number of events. I think a data-driven approach like JSON is the equivalent for managing large, complex trees of dialogue. However I do appreciate that takes more work to set up and involves learning more like how JSON works. But it may well be worth it in the long run.

  • Plus if you're thinking of getting a publisher be prepared to provide multiple languages in your game as well...

  • Nono it's just I've had past experiences with scene graphs that got way out of hand and unmanageable, so I just don't like them myself. There are other softwares that do visual novels and branching dialogue much better than construct.

    I understand fully. I just wanted to make a game that combine the best sides of both. As I want to have full control of the game side of things, so I can put in mini games (imagine the player visiting a video arcade hall and playing arcade-like mini games!) and things like these. Highly customizable and I personally love Construct's event system.

    So going back to let's say Twine is making me feel VERY limited. lol.

  • In my view these flowchart systems look like they work well for simple cases, but for more complex cases you end up with a pile of spaghetti and endless scrolling which makes it hard to even find anything. I doubt it would be easy to track dialogue in this type of system if you had a novel-sized amount of content (e.g. 300+ pages, 80,000 words). You'd have a huge scroll distance and everything scattered over an enormous area with incredibly long lines joining tiny fragments of text.

    For that I would break up into smaller units of "flow charts". Or even implementing a kind of "collapse/expand" system. Group one particular set of location, and then collapse/expand it to make it clearer in view.

    It would be harder for the developer for the game maker engine to write, but would be easier for the end users to use. :)

    But I know you, Ashley, are very set against this idea and that I can respect, that's YOUR software.

    As for the going to JSON route of things.

    I know how to import JSON (in a very general idea as I have used it, however together with RexRainbow's plugins, to import levels made in Tiled, in a wildly different type of game)

    but I am just not seeing how I can organize the dialog branching in a visual/easy way when coming to a book size volume, with spagetti branching, in a such linear format as JSON. idk. Even more so when I need to expand the game (expansions is planned to gradually release new releases - demo - first release 1 release 2, 3, 4, 5, introducing more and more characters, ending with 100+ characters and interactions between those.. )

    I just can't wrap my mind around how to organise it. It is my major issue.

  • This whole approach seems like something that would be better suited as a plugin, rather than a native part of Construct. Look at Unity for example, there are some excellent node-based plugins for story development. In my own experience with building a narrative-based game in Unity, these are great for managing high-level chunks of conversations, but get laborious to use for every single line of dialogue.

    Not sure if you read the first part of my previous response, but you could implement a similar hierarchy-based system to manage whole conversations, and then write the dialogue lines in JSON. That way you're using small, segmented JSON files that might be easier to manage.

    You could also write your story in other software like inklewriter/Twine/etc., and export to JSON (might need a third-party plugin). From there you'll need to build systems to interpret and play back that data to the user.

    Regardless of the method you choose to manage and write your story, you're going to need to unpack that data and display it to the user somehow, and that's going to require some serious legwork.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I am not going to have problems with setting up the engine. (as for the reading the strings/json, and making the interface including the text output) that I can do, no problems.

    I just have problems with wrapping my mind about how to structure the thing. In a way that will work in all the way I want, and with being expansion-friendly, and... ughhh.

    I have bought a Twine importer for C2, but I am not even sure if it is the right way to go either. It would require me to learn Twine's language as for the variable and array passing around, and to me it looks clunky and not.. very visual. lol.

    Might even end up with me making event sheets for the whole thing.. I hope there's no limit of event sheets. ;)

    *googled* ouch, there's a limit on events. Oh well, there goes the hope to keep it in one place.

  • I think dialogue designer comes close to what you are after.

    https://www.construct.net/en/tutorials/dialogue-designer-construct-2624

    I have actually looked into that, as far as I can remember, the software itself is a bit glitchy/clunky/no good for large projects. At least that's the impression I got from reviews. It could be wrong, of course. It is a paid software with no trials afaik so I could not evaluate it if it would work for me.

    But at first glance it does look close to what I would like to have. Maybe I will look it up again.

    Unfortunately it (the tutorial's project file) will not open up in trial version of C3 so I could not see if it is the thing that would make me go up to C3. For now I will stick to C2 (I prefer C2:s gui, simple as that).

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)