More navigation tools

[mplooster]

I think StoryTime would benefit from having a menu (or bar, or context menu, etc.) to help with navigation through the story. It should definitely have a "Main menu" entry so that at any point in the story (including the end), a user can go back to the main menu and choose a different story. Depending on whether you want to allow a reader to go back in the story to make a different choice, it might also have a "Back" entry. It might also have a "Forward" entry if the user does not change any past choices, and they quickly return to where they left off in the story.

When I read stories, I often like to refer back to previous sections to make sure I understood what happened given what I have learned later in the story. I also do the opposite - I look up old information to help me understand what is currently happening in the story. This would help do that.

[RasmusD]

Yes, absolutely.
There's TODO's that suggest both, one is a settings menu in general and one is a scroll bar to scroll back in the text.
If choicehistory is saved not as a set but rather as a ordered list one can retrace choices and thus steps through the story. Alternatively a new list of branches passed through can be saved and flipped through. There's some things there to think about.
We also currently just delete all text segment objects when not on screen, should they be kept or not?
A bit simpler might just be a Menu which can be accessed by e.g. pressing escape (which currently exits the game) and then it would have the following options: Main Menu, Save Story, Load Story, Exit. If one wants to be fancy one can mofidy the main menu to have an optional entry saying "Continue" on top of te current options if one has accessed the main menu through this pop-up menu.

[mplooster]

We also currently just delete all text segment objects when not on screen, should they be kept or not?

I think the answer to this question depends on memory. How much memory would be consumed to load an entire story? Currently the text segment is tied directly to the graphics rendering, so maybe it takes up a lot. Would it make more sense to separate it from the graphics object? Then the text segment could just be a string with some additional data. Perhaps the whole story then becomes a graph-like structure where the arcs of the graph are the text segments and the nodes are the choices. If it is all just a bunch of text, it probably won't consume a lot of memory. Then the rendering can add or remove sf::Text objects as required while traversing the graph (or have a single sf::Text object that gets updated with new text - there are lots of possibilities here).

If the story was simply a graph, I can see that helping a lot with navigation (and saving the story too). All you would need to save is a record of the path taken through the graph. And you could do fun things like autogenerate an adventure map (that I briefly suggested in issue #4) because all the information you need is contained in the graph.

I haven't analyzed the code closely enough to tell whether or not you essentially have a graph already (I suspect you do), but I think separating the story data from the graphics would be very helpful for this enhancement (and other things). What do you think?

[RasmusD]

It's essentially a graph. The story verifier binary is the most obvious example as it verifies that is a valid graph where you can get from the begin segment to the end segment and never get stuck in infinite loops or dead ends.
Internally there's still a bit of improvements to do with keeping the correct record of the history, history can sort of be deleted as it is now, but it's there.
I don't think a lot of memory would be required to keep a plain string history of text shown so far and then create graphical representations needed when needed for going back.