Closed jcandres closed 6 months ago
Thanks @jcandres. I'm glad it's being helpful.
This is a good point. I've seen many games with this format. I wouldn't change the current behaviour as it adds complexity to the consumer, but we can think on alternatives for this.
This could fit well as an interpreter configuration, to always return disabled options.
A simpler solution would be adding a new method to the interpreter to get all the options regardless state. When you get an option type content you could call this method and get all of them.
The second idea looks cleaner, but also more verbose, so maybe the interpreter option is a better fit. Thoughts?
Adding a new method to get all the options could work, even if it means that the user has to juggle a bit with the output... but it feels a bit like a corner-case workaround.
Passing an optional parameter to get_content
would be great -- keeps the default behaviour intact but adds flexibility and transparency should you need it. I'm not sure if this would be easy to implement, but it feels very clean from the user's perspective.
This is available in the newest version. It can be configured via:
dialogue.configure({ "include_hidden_options": true })
I'm on the early stages of making a visual novel with Clyde, and loving it so far.
By default, Clyde won't return an option that's now available. While this works just fine, it's not very transparent or flexible. It would be better if it returns all the options regardless, but marking the enabled/disabled ones with an additional field in the choice json.
The idea is that you can decide which ones to show, rather than leaving that to Clyde. For example you might want to show the player that a given option is on the choice menu... but disabled for some reason. It would serve to let the player know that there are more choices to unlock in the future:
* {apples >= 3} [Trade apples for letter]
, or perhaps that some options are locked because of previous player actions* {murdered_merchant} [Trade apples for letter]
.