Request: changing default option behaviour to "display-only text"

[jcandres]

This is a minor, quality-of-life request. Feel free to ignore it!

Right now options in Clyde are returned as a line after a choice is made -- unless padded with [ ]. I find this counter-intuitive and I end up writing all my options between brackets... which gets tedious, specially considering how easy and natural the rest of the language is. I'm sure there's a good reason for this design, but I can't see a case where I would want a chosen option's text returned as a new line.

Would it be possible to change this behaviour? Having a variable in the interpreter to configure this behaviour would be great.

[verillious]

I personally use this functionality to add the chosen option to a "log" of the dialogue after it's been selected.

If you really never want to get the chosen text could you not write your own little wrapper? :

func choose(choice: int) -> void:
  clyde.choose(choice)
  var _content = clyde.get_content() #ignore selected text

[jcandres]

True, I just find it a quirky behaviour to have as a default since it returns as a line something that's not part of the source dialogue. Using it for logging the dialogue makes sense, though.

[viniciusgerevini]

Hello @jcandres . Thanks for the feedback. The reason it was implemented like this is because it is not uncommon in adventure games having the beginning of the sentence in the options list, but this was mostly influence from Ink.

Actually, It does feel to me that display-only as default would make more sense. @verillious has a really good use-case, but it's more of an implementation detail. I wish I could see how other people are using Clyde to find the most common usage.

I don't like the idea of adding it as an interpreter option, though. It makes the language less consistent and increase interpreter's complexity.

I'll put some though on this and try to gather usage examples. Another possible improvement is making the syntax more straight forward. Brackets do make it less fluid. Let me know if you have ideas for either display-only or non-display syntax.

Cheers

[jcandres]

A reason why I suggested display-only as default is because it sounds logical that an option written in a natural way (no brackets) should get parsed in a natural, unobtrusive way. And when you want your options with a more verbose output, adding brackets to those options makes sense.

I think the main problem is that by default Clyde is altering your dialogue by (1) injecting content into it and (2) in a way that's impossible to tell apart from the original content. When you write options both with and without brackets, how do you know what content is a line and what content is the interpreter spitting a selected option? Different things looking similar is usually a bad design.

A secondary problem is that the brackets are a syntax solution for an interpreter-configuration problem; you have to write your options thinking in a minor implementation detail. For the record, I don't mind the bracket syntax for choices, it's fairly commonplace. I believe Twine also uses them.

Instead of changing the syntax consider changing the default behaviour (solves problem # 1), or perhaps adding a way for the user to indentify the interpreter-created lines in order to deal with the output, instead of conditioning how content is created (solves problem # 2 so the user can deal with # 1). The simplest solution I can think of would be returning the option taken with a different type, such as "selection" instead of the default "line".

[viniciusgerevini]

it sounds logical that an option written in a natural way (no brackets) should get parsed in a natural, unobtrusive way.

I think you see display-only as the natural way, because that's how you use the language. It could be argued that making the option display-only is the obtrusive solution.

Options are not special content. In your case, you see the text as labels, so printing it feels like debugging, verbose. But if you were writing options like a script, as in a text adventure, they would be part of the content, like this:

npc: what do you want to talk about?
  * 
    npc:     Lorem ipsum dolor sit amet, consectetur adipiscing elit, 
             sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
             Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
    npc 2:   blah blah blah...

  *
    npc:     Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia
             deserunt mollit anim id est laborum.
    player:  blah blah...

When I was defining the language, besides matching my needs, I considered text adventure examples to shape it. The situation where options are a list containing the beginning of the branching sentence is quite common.

However, not all options would follow this pattern. Yes or No answers are usually not repeated, that's why the need to have a convention to differentiate it, and not an interpreter wide configuration.

In hindsight, for dialogues I don't think this use-case is the most common. This probably becomes even rarer by using blocks and diverts.

With all considered, display-only makes sense as default option, but I need to find a syntax that works in the inverted scenario, otherwise the fluid example I mentioned before would look terrible.

[jcandres]

I think you see display-only as the natural way, because that's how you use the language.

It could be argued that making the option display-only is the obtrusive solution.

Could be! But again, when the player selects a choice Clyde has already passed the full content of that choice, and if your game needs it you could simply reuse it. My point is that repetition is bad unless you really want it.

I consider the output of a traditional text adventure a pretty bad design, and I find myself skipping over repeated text. Specially after a choice menu, where you may read them a few times while choosing; or where the options are text-heavy like in your example.

For a syntax suggestion, what about a single character like <, combined to the existing choice syntax? Something like:

    +< Tell me about the quest again  -- Sticky that will be returned as a new line
    * (Puch NPC)    -- Default one-time choice, not repeated
    >< Bye!   -- Fallback, returned as line

The fallback looks a bit weird, but < makes sense for a "return this if chosen" syntax.

[viniciusgerevini]

Thanks. That looks interesting. I was also thinking on the lines of using an extra character after the normal option symbol.

< looks ok, but it might be misleading as something like this * <- would look valid, but instead of a divert it would be coverted to the option text -.

The extra char strategy looks good though, I'll go for it. Thanks for the discussion.

[viniciusgerevini]

Changes are on master as version 3.0.0. Still pending approval on Godot Asset Library.

As suggested, options are not returned by default. You can still reproduce the old behaviour by using a = alongside the option symbol. i.e.

+= this should be displayed
+ this will not be displayed

@verillious hopefully this won´t mess too much with your workflow.

Thanks for the suggestions and input. :rocket: