Let me start off by saying I know this requires what is essentially a graph search to implement, so if that's not feasible it's not a huge deal. Basically what I'm here asking for is a way to see and anticipate stub chapters (even just authors manually marking a node as a stub would go a long way.). If each chapter had a count of how many nodes are in the path to its deepest descendant that would help with stories that give many options to the reader/other authors. I feel like using many stub chapters is a valid writing technique, as it lets the primary author construct a skeleton for collaborators/themselves to later fill in. Stub chapters do become a problem for readers though, because no one wants to click and backtrack 40 times before finding the 1 path that actually has a fleshed out story (and the story map is hard to read, it would be nice if it looked more like a flow chart, but I can see that being hard to do on a site that probably takes compatibility seriously). Basically my ideal would have each chapter option look like this <chapter_name>:<max_depth_below>, or at least like this <chapter_name>:<bool is_chapter_stub>, where the stub flag is checked by default, and authors must manually uncheck it. Edit: Maybe it would be worthwhile to have a distinction between key chapters and inbetween chapters like animation uses with key frames? Then you could restrict loops to not cross keys and just count key chapters Edit 2: I didn't see the suggestions subforum before posting this so could an admin move it?
Partially related to Display branch length on option You can add draft chapters to create the desired structure. (You just have to do that after publishing the story as it would publish all existing chapters.) It isn't possible to calculate the chapter depth as you can have linking chapter and even be able to create loops. This could be done with a chapter draft. I think the only difference would be that you would have a forecast of what options are already planned by other authors. (Though the story owner and editor can see that already.) Or do you rather want users/authors to suggest possible options which could be picked up by other authors? That might work around the loop and linking problem, though every time a chapter gets added, you would have to recalculate all chapter depths. You could report your post to request that.
I understand I can do that, I'm trying to come at this from the viewpoint of the reader, and as a reader I know that even if possible, not many people take effort to hide their wip stubs. Also, as a reader I would like to see all the options to know whether to keep an eye on the story, it's just that backtracking after clicking on a stub is annoying (especially when tethering from a phone at low bandwidth). Isn't convenient/fast isn't the same as not possible. I don't know web stuff or what kind of performance limitations the site has but cycle detection in graphs is a thing. My main concern is just not wanting to backtrack up the story when I hit a wall. If readers and authors could put stub tabs in with a request for someone else to write that would be cool as well. I think that's a given from the nature of the suggestion? Again I don't know much about the sites hardware or about web languages, but the largest(by depth, no search filter for total chapters?) is The Gamer at 2.2k chapters, and that's not that big of a tree. Also I'm sure there could be clever tricks done (saving depth at each branching node and just incrementing when possible springs to mind)
I usually see them at new stories (as they get published with the approval of the story) but have seldom seen them later. It's also a disadvantage as readers wouldn't get a notification when the chapter is finished. Well, if I would add all possible options to a chapter, even though I don't even plan to add them. So if they aren't marked for overtaking by other authors, it would even discourage other authors from adding that option. And even if I added an option to write it myself, it isn't said that I ever will. If you don't limit the number of loops, it isn't possible as it would create an endless loop. Using cycle detection might be an option but not knowing exactly, I would think that it is pretty expensive. Game stories might use the same loop several times with different outcome which would increase the actual depth (in chapters) without increasing the number. Also, it won't show the number of words, so you could have 5 chapters depth with 5,000 words while another branch depth with 50 chapters only has 500 words. So an option "Go back to last branching chapter"? Not sure if that has been suggested so far, though I don't think so. It's basically the same as with other programming languages just slower as the code isn't compiled. I guess At the Cabin is currently the one with most chapter and around 3,800 chapters. Loading big story maps has been divided into 1,000 chapter chunks as it otherwise won't load. So when adding a chapter, it starts at 1 if it's a normal chapter. If it is a linking chapter, the number would be the same number as the linking destination. From there you go to the next parent and add 1 to the chapter except the number is already higher. If the number is higher, stop. For every chapter, you would also have to check if it is a linking destination and if so, you have to do the same with the linking chapter and its ancestors. For loops, there might be additional problems. So you could either get all information (the whole story map) from the database in one go or only the related chapters but one by one which would lead to a lot of database queries. Every chapter needs the number or you can't show it on the options. Also, you don't want to show the depth of the node but of its child chapters.
Again I want to say I'm not a web programmer so knowledge here is limited, and maybe it's a server power/budget thing, but that seems like a red flag. What does the story map look like in data? Would think it's just a bunch arrays or lists of strings for the titles and URLs between each node and some variables on each node to show views/likes/comments/dates right? Assuming the strings are 100 utf-8 characters (that's a long chapter title) and there's 8 other 64 bit ints for bookkeeping, that should be 264 (plus or minus some wider unicode characters that may be present) bytes per edge on the graph. If the mean At the Cabin node had 12 edges (I doubt this for some reason) it would be 3800*12*264 = 12,038,400 bytes, or about 12 megabytes, although that assumes no edge is a link (links could be less space, as you could have an array of all urls and titles and simply store an index into that array to lookup its url/title). Usually when I'm updating a game, steam tells me I usually get about 10 kB/s, meaning it would roughly take me 1200 seconds (20 mins) to download the full story map. That's pretty long, but it's also before any sort of compression, and the 12 average edges per node assumption seems high to me. I just zoomed out all the way on At the Cabins story map, counted how many lines fit on my screen (115), and counted how many times I could hit page down before stopping (34.something), 115*35 =4,025 edges, which at 264 bytes/edge would be 1,062,600 bytes before any sort of text compression/link aliasing (100 seconds on my slow connection). Also my estimate for averadge edges per node was way off it's actually like 4 on At the Cabin. I don't know why I sat and did this and I really hope I'm not making any errors after all that lol.
I can't estimate the expense in CPU/bandwidth as well. There are one or two threads/posts around which show the USD expense of the server in detail. 1.000 chapters on the story map from AtC delivered to a user are around 50 to 70 kb. Actually, the links are delivered in full twice, though that doesn't matter as it won't be delivered to the user but processed on the server/database. You would rather need the ID, the parent ID, the current depth to end, and the link status/destination ID. So if this is done, it might be better to load the whole thing in one go. Well, given that there are about 200 new chapters a day, it might be doable if the processing of loops works.
As I read this thread I got more and more annoyed. (Not angry, just irritated.) This website is MASSIVE and entirely coded and designed by one guy. What you ask is not impossible, no, but it is expensive and difficult. What I want you to ask yourself is not whether this is possible, but rather if it is Feasible. There have been many points lately where the site has come close to having to be shut down for lack of funds. Don't add to that.
Well shit sorry for talking. I know I got carried away last post, but hit submit just out of gamblers fallacy. I really doubt talking about the site "adds to" the lack of funds.
I expected I would turn out to have expressed myself badly, and as usual, I was correct. I'm not irritated by your talking or making a suggestion, im irritated by your not taking "No" for an answer. It can't be done without a massive increase in funding: if you can't provide that, accept that it's not workable and move on, if you CAN provide that: why haven't you?
