Visual branching passage system

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.

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.

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.