[Suggestion] Story Variables and Conditional Branches

[Semeny Licket]

The more I think about this, the more attached I become to the idea, especially as I try to get accustomed to the notion of threads that can be linked to from multiple parent chapters.

Chyoa has a feature where readers can put in a character's name and such, right? And as they read that story, those variables are remembered, so that whenever one of them is referenced by a code in the story's text, the story will display that character's name. Pretty much?

What if we could designate certain variables as uneditable by the reader, and authors could use a code in a story thread that would alter one of the story's variables? Further, we could have story branches that are only available if certain variables return certain strings when the thread is loaded. In this way, if a reader chooses to pursue a specific path in a story, they might unlock a new path further along.

Story owners would have to blank the variables on the first thread, and this entire feature would be entirely dependent upon the feature where multiple chapters can lead back to one single chapter. The interface would probably get cluttered with coding, especially if down the line we decide it might be neat just to have certain paragraphs in a single thread only appear based on a variable's status. In the end, all this really seems to circumvent is having a lot of chapters with pretty much the same text but a few sparse differences. This could economize on chapter threads, but I could see people preferring just to work around it.

As a practicable example, a character might decide to ask for another character's phone number. Later, because they learned that phone number, they would be able to call that character up. The author would use a code to change a variable "PhoneNo" to "555-5555". Then, in a subsequent chapter, a branch would be made available only if "PhoneNo" was equal to "555-5555".

 

[bsnick]

Twine and ChoiceScript both give those kinds of stories as far as I know, but I've no idea how complicated it might be to use them. In all likelihood it would have to be done in the forums, perhaps be a forum section for Adult Interactive Fiction. I know there's still life in that genre, so Chyoo could perhaps gain more users if it catered a bit to them.

 

[Mr.B.]

I was kinda thinking something similar the other day.
Usually games with erotic\adult themes tend to have one variable linked to the morality\immorality of the character (and another representing their money). And if I can think of one way to bring chyoa up several levels (in the future) it would be by adding the possibility to:

- setup hidden variables in a story (example: an integer from 0 to 20 starting at 10, representing the morality of the main character)
- the possibility to link a modification of that variable (+x or -x) to a thread. Modification defined by the writer of course. (example: the reader chose a thread where the character will do something immoral, -3 to the morality variable)
- third: grey out some threads (choices) to the reader if the required variable values aren't met.

I'm interested to see what our good Friedman thinks of this madness

PS: anyway, this is more difficult than it seems, especially because it requires the writers to balance the variables correctly within a story with recurrent threads.

 

[Semeny Licket]

Twine and ChoiceScript both give those kinds of stories as far as I know, but I've no idea how complicated it might be to use them. In all likelihood it would have to be done in the forums, perhaps be a forum section for Adult Interactive Fiction. I know there's still life in that genre, so Chyoo could perhaps gain more users if it catered a bit to them.

I'm not sure what Twine and ChoiceScript are. Are they what Chyoa uses to function? I'm not entirely sure how a forum section reiterating what Chyoa is all about would suffice, particularly for a site functionality feature. Using forums would just be silly; it'd be linear, and forums are horrific for plying through. Everything's far too transitive, conversational, unwieldy, cluttered, etc. Web pages are formal, not casual.

 

[Trugbild]

I think, that this would be really complicated. Especially, if more than one author is involved.

How should the story map react? Don't show unavaillable threads?

On the other side, there is another way to create that kind of stories.
Just introduce your system at the beginning and create the answers with your requirements

Something like that:
Christy gave you a napkin with her phone number. Add "napkin with Angela's phonenumber" to your inventory. You gain 5 experience points. Add 2 points to your morality.

2 posts later:
You are really bored. What do you want to do?
Answers:
1. Wank (you can always choose this option)
2. Call Christy (only, if you have "napkin with Angela's phonenumber")
3. Go to your mothers room and try to seduce her (only, if your morality is below 5)


With that, everyone can easily cheat and choose unallowed threads. But I don't think, that this would be a problem.

 

[Semeny Licket]

So, pretty much an honor system with a lot of penciling your napkin. The premise of this system would be to completely automate that, though.

You would have to edit pretty closely to check what other authors have done, but I don't know if it's so complicated that it would beyond the reckoning of those with the ambition to pursue writing such stories. I'm not sure the story map would be affected any differently. Linking multiple threads to a single thread shows duplicates of the threads being linked to.

Additive and subtractive numerical variables would be handy in conjunction with this system.

 

[Mr.B.]

I think, that this would be really complicated. Especially, if more than one author is involved.

How should the story map react? Don't show unavaillable threads?

I think there's a way: in that kind of stories you have to force the reader to begin at a "starting point". There's no reason not to.
Second, you need the server to "save your progress" (example: you've arrived at thread 10283, variables: 130$, 8 morality, napkin on true).
In that kind of stories (a lot of variables) you probably won't need to use the story map (you can hide it or make it not clickable, why not).

The problem is that even with stories with a few simple variables there can be the chance of recurring thereads, so if you don't want to use the system above (so you want your readers to be able to use the story map and click random threads) I think you're forced to simply write the variables in you answers and nothing else.

 

[Trugbild]

It could work, if there would be another story format beside the normal (single player RPG mode)

Save progress could probably done by serialize with json.
The question would be, if only the answers would be affected, or if another template system would be needed to create if-then-conditions.

This way?
1. Call Christy (only visible if "napkin" = "1")
2. Call Jessica (only visible if "lost cell phone" = "0")
3. Take a taxi to the club (reduce "money" by "20")
4. Go to bed and sleep alone (reduce "fame" by "1")


I still think, that it would be much programming effort to integrate this into chyoa.
Writers have to learn the syntax, when contributing to stories. Maybe it would be hard to balance that stories. Writers don't know, how much other writers added/reduced from some variables. For an short overview, writers must have access to all threads and have to count through them. (then also readers could read all threads, because for this case they are also writers)

 

[Semeny Licket]

Numerical values certainly complicate matters more than strings.

I feel like this system would be building upon a system that's already here, that I'm surprised nobody's asked about: The variables that readers make when they start. Aren't those remembered when you leave the story, per each story? Or do you have to return to the cover page and put them in again each time?

 

[Mr.B.]

I feel like this system would be building upon a system that's already here, that I'm surprised nobody's asked about: The variables that readers make when they start.

Yep, that was what I meant too: expanding on the already existing system (and no need to code by the writer..it can all be done with a simple gui (example: menu\buttons at the start or end of a thread that let u select the possible changes to your variables. +\- x for a number, true\false for a boolean).

 

[Friedman]

I like the idea of having conditional branches within a story. Therefore, I’m thinking about enhancing Chyoa by introducing several story types in the future.

1. The current type would be the standard type.
2. New story types could be the in this thread mentioned conditional stories where the owner defines variables (similar to the customization functionality) and the writers can then add/modify the values (+/-) in their threads and set viewing conditions for them (single player RPG, discussed in this thread). Key to this is a sufficient overview of all variables within a story (Should only the owner define the used variables, or should writers be able to add variables as well (e.g. the mentioned phone number above), or have an inventory where you can add items?).
3. Another third story type could be a one sentence at a time story where every contributor writes only one sentence as a thread.

Let me know what you think about this.

(...) The variables that readers make when they start. Aren't those remembered when you leave the story, per each story? Or do you have to return to the cover page and put them in again each time?

Those variables are remembered for the current session. And since one session has a lifespan of 14 days they are remembered for two weeks normally.
But with a new single player RPG story type it makes more sense to associate those variables directly with a user and have a reset button to start all over (or resume to a story even after those two weeks).

 

[Mr.B.]

That's awesome! It would (almost) be like creating a rpg
Yeah, the introduction of a new story type is the better solution. As you can see we've already discussed the main issues, but we leave the final decision on how to better implement the system to you.
To summarize:

- In these kind of stories is highly probable there will be a lot of recurring threads and variables, so Idk how useful can be to leave to the reader the possibility to start from a random thread through the story map. So how to solve this? Leave the story map anyway, or show it but don't make it clickable, or don't show it at all, or make it clickable only until the first variable is used, or let the editor of the story choose? Or something alse?
- Do you think a way for the reader to "save his progress" will be needed? Maximum once for each story, for example with the (number of the thread, variables with the relative values).
- I'm for showing the link of the threads where the reader doesn't have the necessary requirements yet greyed out, not totally hiding it. You?
- You made a good point there..who is going to handle the variables? If we leave all to the story owner there's the usual risk of having other writers stucked if he's not available, but if we let the writers in there's the risk of someone making mistakes (could also "broke" the story) or spamming new variables or worse. So yes, in my opinion there has to be a barrier of some sort. Soo...a system where the writers can add new variables but they have to be approved by the owner\editors like a normal thread?
- You mentioned an "inventory", but basically it's already what the reader would be carrying anyway...I guess there should be a (visual) way for him to see what the actual state of his variables are.

As for the one sentence at a time story, I cannot imagine how it would end but I'm curious to see what happens ..maybe in those cases the creator of the story should take extra care in describing the key parts of the whole thing (description of main characters, locations, direction of the story)

 

[Trugbild]

Due to the growing nature of chyoo/a stories there should be a way to save the progress. Maybe even more than one slot (I think 3 would be a good number to give everyone the chance to reach a wide range of big stories without starting again with each update). This shouldn't be hard to realize (serialize progress data with json)

I think that greying out unavaillable answers would be a good teaser.

Would the approval system enough to cover variable spamming, etc.?

Know variables (money, inventory, names, ...) could be done as "public".
Unknown variables (moral, alcohol level, horniness, how easy to get) should be done as "private".

How to handle the story map is the hardest question.
Writers probably need access, but readers shouldn't have access (easy to cheat).
That could be avoided, if writer have only access to the threads they currently reading (or history - see below). They should see the names of all variables, but not the values. Possible changes should be increase (+), decrease (-), set (=) (maybe with short explanation).
Then the story owner can put in suitable values.

For all user (except the story owner and moderators (illegal content)) the story map could be a history, so user would have to chance to read the complete process of his rpg, but can't access the parts they didn't reached. (that history can probably created with the threadnumbers, so there wouldn't be a problem, if some threads would appear more often in the history)

 

[Semeny Licket]

I can only offer suggestions on this matter, since I'm only another user, but I can't help but feel inspired by, even giddy at, the idea of using conditional threads and variables to create stories that are more game-like and less linear in nature.

- In these kind of stories is highly probable there will be a lot of recurring threads and variables, so Idk how useful can be to leave to the reader the possibility to start from a random thread through the story map. So how to solve this? Leave the story map anyway, or show it but don't make it clickable, or don't show it at all, or make it clickable only until the first variable is used, or let the editor of the story choose? Or something alse?

I think the nature of a literary community encourages us to abstain from shortcuts. Fiction is fundamentally about the simulated intellectual and emotional stimulation the process of reading can provide (or is that just me?), so people would only be robbing themselves of the experience if they jump around the thread titles. Nevertheless, story maps are useful to story editors as well. Perhaps the ability to alter story variables should be disabled from the story map view, and only accessible when stories are navigated via orthodox means (that is, reading through threads from the cover page and via clicking options).

In a similar fashion, though, I wonder how we could handle backtracking. If it were only numerical values, a back button might be able to revert any changes made, but strings would be such a valuable function. The simplest solution would be to lose your progress. Perhaps the next question can address this, however:

- Do you think a way for the reader to "save his progress" will be needed? Maximum once for each story, for example with the (number of the thread, variables with the relative values).

Certain ambitious flash games store data in the browser, but clearing cache (or doing something along those lines) can lose hard-earned progress. However, I imagine a pair of simple "export" and "import" buttons found on conditional stories could transcribe variables to or from a tiny text file for a story. They could keep track of what story was being read, and what thread of that story the reader was on. Again, people might question the "honor system" aspects of this methodology.

With the ability to export and import story variables (like "save data"), players could manage their own quantity of "save files". This could solve the issue of backtracking, so long as readers keep track of their own exported text files. How does Cookie Clicker handle this? I've cleared my cache loads of times, and it still has my months' worth of progress kept track of. Incidentally, that uses an encoded export/import function.

Another potential approach to this issue could be the bookmark command. Perhaps bookmarks could keep track of story variables as well as stories somehow, but as I believe these are stored in the site's user database, I worry about how bloated this could quickly get. This website must be storing a whopping great ton of information on it already.

- I'm for showing the link of the threads where the reader doesn't have the necessary requirements yet greyed out, not totally hiding it. You?

Hm. This might provide spoilers by implication. "I hadn't even though of that option!" a reader realizes. Then they want to backtrack. Would it make the site too bloated to add a toggle functionality to this?

- You made a good point there..who is going to handle the variables? If we leave all to the story owner there's the usual risk of having other writers stucked if he's not available, but if we let the writers in there's the risk of someone making mistakes (could also "broke" the story) or spamming new variables or worse. So yes, in my opinion there has to be a barrier of some sort. Soo...a system where the writers can add new variables but they have to be approved by the owner\editors like a normal thread?

Story maps for conditional stories should indicate what a thread's option alters, so that the creator and all editors can see this information at a glance. It's so nice that we have collapsible trees. In actuality, I envision this being slightly less complicated than debugging a "proper" game. What's also clear is that when editing a thread or adding a new one, writers should be able to see their current variables, hidden or not, just like a programmer. This might slow the writing process a bit by encouraging writers to read their way through the story beforehand (which, if they've read it enough times to be familiar, could be moot).

But here's something important that's just crossed my mind: There could be a use to the story map and variables. Perhaps writers could simulate variables without loading each and every page. They could go to the story map view, clear their current variables, and then click on a special button beside each thread title that simulates that choice's change in the story's variables. Clicking on the first page clears everything. Clicking on a subsequent thread would change the variables as if they had clicked that option from the page on which the thread is linked to. That way, with just a few swift clicks on one page, writers could keep track of where their variables ought to be, or can possibly be, by the time their thread is reached. There's no need to worry if your morality can be -10 or if you can get that phone number, because you'll see the variables declared.

On this subject, erroneous variables declared by typo could be cleared by a variable-clearing mechanism (that sets everything to null for that story). You'd have to debug those in an exported file if you don't want to sacrifice your progress, in this hypothetical example. Be sure to watch out for declaring variables that might not be mutually exclusive--If you want Greg's phone number and Cindy's phone number, it'd be best not to use a single variable called "PhoneNo".

- You mentioned an "inventory", but basically it's already what the reader would be carrying anyway...I guess there should be a (visual) way for him to see what the actual state of his variables are.

I vote sidebar. Something that won't require more scrolling. Perhaps something that can be sorted by clicking and dragging, if the option allows. Something very low-key and unimposing.

Ultimately, what this could mean, is that a detour the reader takes seven threads ago won't require seven virtually identical threads just to come to fruition later. All in all, conditional stories would definitely require a lot more careful thought and planning, but I feel confident in saying I believe the end results would be worth it for those who pursue this.

 

[dirtytyke]

I like the idea of having conditional branches within a story. Therefore, I’m thinking about enhancing Chyoa by introducing several story types in the future.

1. The current type would be the standard type.
2. New story types could be the in this thread mentioned conditional stories where the owner defines variables (similar to the customization functionality) and the writers can then add/modify the values (+/-) in their threads and set viewing conditions for them (single player RPG, discussed in this thread). Key to this is a sufficient overview of all variables within a story (Should only the owner define the used variables, or should writers be able to add variables as well (e.g. the mentioned phone number above), or have an inventory where you can add items?).
3. Another third story type could be a one sentence at a time story where every contributor writes only one sentence as a thread.

Hi Friedman, have you thought any further about implementing additional story types? Conditional stories would be great. I see some stories where people have essentially attempted to implement them, but they of course require the reader to remember all the variables themselves.

 

[Semeny Licket]

I read in another thread that there's a plan to have conditional paragraphs in a single story thread, which sounds fantastic. I don't think it would be necessary for story tags to have to be conditional as a result since tags are used for weighting a story more than finding individual pages (I think), but I expect it might've come up.

 

[Ovipositivity]

I love this. As it is I'm doing lots of very similar but not identical branches to reflect changes earlier in the story.
I love the conditional paragraphs, too. I can see a lot of use for those.

 

[audax]

1) Conditionals. They've been kicked around, but I didn't see that they were codified that well. My suggestion:

Stories should track integer variables in the Query String. For those who don't know, a Query String looks like this: www.youtube.com/watch?v=dQw4w9WgXcQ

The "v" is the variable, here just named "v". The bit after that is the value. YouTube is alphanumeric, but for this site, I suggest sticking with just integers. Keep it simple.

2) Page text should support conditionals embedded in it, along with simple logic. Have it work similar to block quotes (see above). Example:
[IF v>3] Whatever v is, it is greater than 3.[/IF]

Assuming >, <, and = are supported, writers could then nest them. I could test for two things:
[IF v>3]Whatever v is, it is greater than 3.[IF m=3] And m is exactly 3. Fantastic.[/IF][/IF]

With that, you could have alternating descriptions based on state of dress, their mood, or whatever else.

3) Page links should have optional conditionals in order to show the link. As with descriptive text, if there are no conditionals, they always show. If they are used, they must be true to show the link. If there are more than one conditional per link, they must all be true for the link to show.

3a) Would be super nice if links we could either put links inline with the story, just like tag blocks (say, with a [ LINK] block or such). Then you could just use the previous conditionals exactly the same way, but against the links.

4) Links include Query String variables, which can be referenced, incremented, or decremented. In other words, by clicking on a decision, you alter the variables depending on what the writer wants. Example:
[IF v>3][LINK v+1;b;c-2;d=4]Option 1[/LINK][/IF]

Which reads: if v is greater than three, the link to "Option 1" is available. If the user clicks that, it will increase v by 1, copy b over, decreases c by 2, and d is set to 4. In practice, all this does is to build a link as normal, except it attaches a Query String. So from an actual story, the URL might look like: https://chyoa.com/chapter/Alternate-Version.169573?v=4&b=0&c=1&d=4


So, why do all that?

Well, you could easily link a chapter back to itself. This is helpful if you wanted to, for organization sake, keep everything that is part of one scene contained in one page. If you want the player to have a conversation with someone, you could keep track of a handful of variables based on what topics have come up. If the player selects options that are engaging or insulting, counters to track that could be added up. Facial expressions could be made visible through changing descriptions - the person the player is talking to could become happy, bored, or disinterested. When whatever ending condition is met, there is only a link to say goodbye. Variables used during the conversation could get tossed, and the only thing saved is the outcome. The next chapter is the next scene.

It could be something far simpler. Maybe I want to keep track of whether the player rifled through someone's private items, and nabbed a key. If you have the key, you have the option to unlock a door and go in; otherwise, you can't. Or maybe I found out a computer password, and want to log in. Or retrieved/found/stole a favored item to return to someone. If you have the item, you can; if not, you can't.

I've seen several stories that want to give the player the option to dress in various styles. Usually, that's handled (poorly) by complete story branches that never close back. The amount of writing required explodes. Not this way; just track what outfit or items the player has. If that has an effect on the story, write only that conditional description or link. It enables additional description and options, without several times as much text to be hammered out.

For that matter, the writer can push the player through the same scenario, but with different options. Say the writer wants to allow the player to decide between male and female. They run the player through the exact same situations, but alter them based on what the writer wants responses to be based on the player's gender. The player might go to the same party in both instances, and have the same series of events occur; someone spills a drink, later a fight breaks out, and later someone attempts to crash it. During each of those events, what a player is able to do (or would like to try) could differ based on gender. But you don't need to rewrite the whole story; many descriptions and conversations work on either path, and the writer may not want to replace the ones that work.

 

[Trugbild]

Stories should track integer variables in the Query String.

- There is no better way of cheating...
- Query string length is limited.
-> Variables should be saved per user on the server.

 

[audax]

- There is no better way of cheating...
- Query string length is limited.
-> Variables should be saved per user on the server.

Cheating isn't an issue. The stories aren't multiplayer, so the only one "hurt" is the reader, and they can already "cheat" by looking at the story map. Plus, it makes testing scenarios by writers so much easier than having to launch through the story every time.

The URL limit is 2k characters in IE, which goes up if you use Edge, Chrome, FireFox, etc. I can't imagine that any writer is going to actually keep track of more variables than even the 2k limit, unless using stupid-long variable names. Even with this limit (which is pretty much out of date), you're talking about upwards of 100 variables, easy. Waaaay more than enough for the amateur crowd.

You can save on the server. Bookmark the URL, exactly like you do today.

Also, the intent was to offer a suggestion that changed code requirements as little as possible. The only really difficult part (relatively) is the changes to chapter links. Also, all existing stories would work as-is.