RoboBob3000
Level: Smitemaster

Rank Points: 1982
Registered: 10-23-2003
IP: Logged

It looks like everybody's got an idea regarding how to best manage saves in DROD RPG. We can go ahead and throw mine on the pile too.

Succeeding at this game requires analyzing branching decision paths. That suggests to me that an expandable/collapsable branching tree view of saves would be the most useful for players.

The gist: The root save of the tree is the beginning of the quest. At the start of the game, the root save is the current node. When a new save is made (including autosaves), the new save is marked as a child of the current node, and then the new save becomes the current node. Any time you load a save, the save you load becomes the current node. Ta-da! Tree structure!

The ability to display saves as an expandable list would make it much easier to identify major decisions that the player made along their current branch (provided that they named them well). The depth of the tree is directly related to progress along a certain branch - a player can confidently return to an old save earlier in their branch and know that they didn't return to a similar point along a completely different branch.

Obviously, this wouldn't be compatable with existing save files. Perhaps a patch that implements this could just mark all previously existing saves as children of the root.

And then there's the issue of quicksaves - I don't think they necessarily need to change with this system. They could remain as disposable saves, but the previous "real" save would retain the current node attribute.

Edit: I should note that the implication here is that each save would potentially have several first-generation children.

____________________________
http://beepsandbloops.wordpress.com/

---

[Last edited by RoboBob3000 at 09-17-2008 11:48 PM]

Fafnir
Level: Smiter

Rank Points: 315
Registered: 11-05-2004
IP: Logged

Hmm... On the one hand, it sounds like a pretty good model, it works with my play style, and it's the best idea I've heard so far. You could actually give separate playthroughs of a given hold separate trees - a forest rather than one big tree - which would be a godsend for organisational purposes.

On the other hand, any given playthrough is going to be a very deep, very unbalanced tree - people don't generally explore the consequences of a decision very far, so at any given node (at least near the root) one child will be far larger than the others. That makes it tricky to represent efficiently coding-wise, and even trickier to represent visually on the restore screen. The expanding-collapsing view doesn't work when you have to go through twenty expansions to get to your last save. Thoughts?

____________________________
Stupidity kills.
Absolute stupidity
Kills absolutely.

Monkey
Level: Master Delver

Rank Points: 190
Registered: 03-21-2006
IP: Logged

Meh, I'd use a folder system instead of a branching system. But the principle is pretty much the same.

____________________________
lurking

Sillyman
Level: Smiter

Rank Points: 339
Registered: 09-08-2006
IP: Logged

Fafnir wrote:
The expanding-collapsing view doesn't work when you have to go through twenty expansions to get to your last save. Thoughts?

Yeah, maybe the designers could do something that's never been thought of before, especially not in default operating system dialog boxes like [gasp, shock] making the current node automatically expanded. Naaaah, that'll never work.

____________________________
Who, me?
FNORD

---

[Last edited by Sillyman at 09-18-2008 07:46 AM]

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

Monkey wrote:
Meh, I'd use a folder system instead of a branching system. But the principle is pretty much the same.

So exactly how does a tree of folders differ from a tree of nodes?

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

Briareos wrote:
So exactly how does a tree of folders differ from a tree of nodes?

folders either implies an actual file-system organization (which would be off in this case because all the saves are actually dumped into a database) or (more likely because of the parenthetical just listed) implies that nodes can be typed as containers or data, but not both. whereas in a node system, you kinda of expect that all nodes are data, and some are also containers.

however, from a UI perspective, he probably means "and then the user can choose which (arbitrary) node to stash the save into, rather than being forced to 'hang' it off of an antecedent save," thus allowing the user to organize differently from "saves starting from New Game X" to, well, whatever the user wants. this is, of course, possible in a system where all saves are implicitly also folders, but probably confusing unless you allow the creation of non-data containers with arbitrary names (i.e. folders).



____________________________

---

[Last edited by silver at 09-18-2008 03:20 PM]

Fafnir
Level: Smiter

Rank Points: 315
Registered: 11-05-2004
IP: Logged

Sillyman wrote:

Fafnir wrote:
The expanding-collapsing view doesn't work when you have to go through twenty expansions to get to your last save. Thoughts?

Yeah, maybe the designers could do something that's never been thought of before, especially not in default operating system dialog boxes like [gasp, shock] making the current node automatically expanded. Naaaah, that'll never work.

Look. Assume each level of folders is 1cm of indentation. At the end of a hold, it's not unreasonable (using the branching model that Robobob is advocating) to have amassed 50 levels of saves. (I would easily have had this many on my first playthrough.) Considering that the save selection dialog is about 10cm across on my (quite wide) monitor, that's a lot of horizontal scrolling needed to browse saves. Do you see my point now?

____________________________
Stupidity kills.
Absolute stupidity
Kills absolutely.

Sillyman
Level: Smiter

Rank Points: 339
Registered: 09-08-2006
IP: Logged

Aaah. Yes, yes I do.

____________________________
Who, me?
FNORD

RoboBob3000
Level: Smitemaster

Rank Points: 1982
Registered: 10-23-2003
IP: Logged

You're absolutely right about the display - it would get unwieldy and difficult to navigate fast. Regardless of how you would display it, I still feel that this underlying structure would be extremely useful to have in place.

Try this on for size: All saves will still be listed in chronological order. However, we add an additional "info" button somewhere (I don't have the UI available right now, so I don't know where it would fit). If you click on any save and then click on the "info" button, you are presented with a tabbed view. First tab features a scrolling list of all ancestors of the selected save. Second tab features a scrolling list of all first-generation descendants of the selected save.

Navigating down the tree will still be time consuming, but navigating back up the tree (which is a much more likely restore scenario, IMO) will be a breeze.

____________________________
http://beepsandbloops.wordpress.com/

Sillyman
Level: Smiter

Rank Points: 339
Registered: 09-08-2006
IP: Logged

Hang on... let's take that folder idea and twist it a bit (or not at all, depending on the original intent):

It's a tree of nodes that operate UI-wise like folders, except in a list (possibly also allowing actual folders). It starts showing top-level saves, along with how many saves they contain:

(42)Level 2: Entrance (autosave)
(55)Level 1: Once North
(10)Example Folder (folder)

Then, when you select one, it opens and the other ones disappear. (Plus, restore is enabled) However, it remains (along with, of course, the root directory) to allow going back easier, potentially with an indicator like (^), (^2), (^3), etc., and its contents are displayed beneath it.

This repeats until you reach an empty save or newly created manual folder, which leaves the other branches displayed, because there's no reason not to.

____________________________
Who, me?
FNORD

Nuntar
Level: Smitemaster

Rank Points: 4964
Registered: 02-20-2007
IP: Logged

It's come up in chat quite a bit recently that save management could do with an overhaul, and I knew there was an old topic for it, so I dug this up.

Browsing the topic, I see that others have proposed a tree structure for trying out various possibilities within one attempt at a hold, so that you can easily see which saves are "ancestors" of a particular save when you get stuck and want to go back. That's certainly worth supporting. However, my motivation for wanting a folder structure is different: I want to be able to keep saves towards an attempt at "ATK route, no shield" separate from saves towards an attempt at "DEF route, no altars" separate from... you get the idea.

Relatedly, I want to be able to turn off autosaves. I know they are very useful for first attempts at a hold, but for challenges they are worse than useless. You have to make manual saves anyway, because the autosave will be overridden as soon as you attempt a different challenge, so they just end up as extra clutter making it even harder to navigate your single folder.

As for how to implement a folder structure, Sillyman's idea is the best, but there is the question of what "top-level saves" means. The first save in a particular attempt? No use for TT, where nearly all challenges handle the first level the same (since you shouldn't use the first altar) so we'd still have everything piled into the same folder. No, the only way to make this workable is for the user to be able to designate a save as "top-level", which automatically means that any further saves starting from that one are saved into its folder. This would also apply to autosaves (if turned on), and if a particular folder is "active", an autosave would override previous instances of the same autosave in that folder, but not in other folders.

____________________________
50th Skywatcher

bbb
Level: Master Delver
Rank Points: 218
Registered: 10-07-2013
IP: Logged

It sounds like the model you are looking for is version control.

greenscience
Level: Master Delver
Rank Points: 164
Registered: 02-27-2015
IP: Logged

An improvement to the save system could be a useful feature for 1.3 so I'm bumping this thread to restart discussion on the design and implementation feasibility. I have not looked too closely at the code but it seems the current system manages a list of saves by hold and profile ordered by time, with everything being kept in a database. These are some of my thoughts:

One feature I feel would help is the ability to reorder saves more ergonomically. Right now moving saves around involves loading a save, saving a new one, then deleting the original. This can only move one save to the top and becomes tedious when shifting many saves. Drag and drop is an obvious technique for this but I rarely see it outside of the editor so I do not know how well the engine could process it. As an alternative could add buttons to move a selected save up/down a slot or to the top/bottom. Even better if that could work with multiple selected saves, possibly limited to a contiguous selection. Another factor to consider is whether to track order and time separately or modify the time for a save when moving it.

A simpler way of grouping saves is to use a tab or single level folder structure where saves are associated with a particular tab. For compatibility existing saves could be placed in a default tab. Having a way to move saves between tabs along with renaming would also be helpful. Since tabs should have unique names this would be relatively easy to handle in a database.

Tree or hierarchical folder view is more flexible but likely harder to implement in the current engine. Between the two a folder view is likely easier to implement since it can reuse existing code for importing/exporting while a tree view requires new elements and can take up space as levels become deep. Even so managing treelike structures within a database is complicated.

mrimer
Level: Legendary Smitemaster

Rank Points: 5197
Registered: 02-04-2003
IP: Logged

I appreciate the suggestions! I support making the play experience easier to manage.

Yes, these new behaviors would require updates to the database, which has been rather involved in the past. We wouldn't have to wait till a new major version (1.3) to make this happen, if a database table update were implemented. This is kind of a big deal, though, so the developer would need to think carefully how to make this work for pre-existing .dat files (either by revising their schema, or possibly by adding a new table, or some other approach I haven't envisioned yet).

Can you draw me a mock up of how you imagine a folder UI would look?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-06-2020 05:06 AM]

greenscience
Level: Master Delver
Rank Points: 164
Registered: 02-27-2015
IP: Logged

File: rpg save proposal.png (40.2 KB)
Downloaded 63 times.
License: Public Domain

This is a mockup of how a folder UI for saves could look. I chose a system where saved games would also function as folders but one where saves and folders are separate entities is also possible. Quicksaves appear purple, manual ones with no inner saves appear black, manual saves with inner saves appear green and optionally have the number of saves they contains in parenthesis. The left arrow would go up a level until reaching the root folder, which leaves the top bar empty and grayed out. The right arrow would go into green saves but be disabled on quicksaves since branch points should have a memorable name and quicksaves are overwritten.

The previous proposals seem to suggest making it so saving a game automatically puts it inside the save it was last loaded from or saved to. However as other have mentioned this creates deep and potentially unbalanced trees. Moreover it is unlikely that every single save represents a decision point. So my preference is to make it so making a save puts it at the top of the current folder and you can manually enter an empty save like a save with inner saves by clicking the right button. This should encourage shallower trees and provide more flexibility in how to organize decision points.

The other new buttons would allow moving a save up/down a slot or to the top/bottom. Additional ways to manage saves could be put into a new dialog opened by a manage button next to restore. In there you can have options for renaming saves, moving saves between different folders (be careful of moving a save within itself). Deleting a folder save could be handled in many different ways. It could delete all saves within it, move all inner saves to its parent, to another folder by reusing UI for the previous functionality.

---

[Last edited by greenscience at 10-07-2020 01:29 AM]

mrimer
Level: Legendary Smitemaster

Rank Points: 5197
Registered: 02-04-2003
IP: Logged

Thank you for the mockup and description.

I think I understand the ideas. Let me repeat back what I got from this topic so far and summarize everything I'd be thinking of designing into such a system at this point.

If I'm comprehending correctly, then for back-end support, we should probably add a new database table describing this structure, as opposed to extending the current saved game table schema. I think this wouldn't require code to migrate to the new table schema; the game would just create the new table if absent on startup.

With this approach, we could add this functionality into any game update.

If saved games act as folders, then we would have a DB table with:

<saved game id (primary and foreign key)> <parent folder id> <position # in folder>

I think that's all we need to model the structure.

* Now, when a saved game is loaded that belongs in a certain folder, then all new saved games created during play would also be assigned to that folder. Autosaves would overwrite matching autosaves inside the current folder.

This seems like optional behavior that players might want to disable. (Have it disabled by default?) Actually, folders wouldn't exist unless the player creates them manually, so this is probably unnecessary.

* Still only a single Continue save slot, correct?

Verbs:
* Creating a folder: yes, an empty "folder" saved game type could be supported for purposes of acting as a container to organize saved games within it. We could add a new button, Add Folder.
* Deleting a folder: Multiple options, as you say.
* Ordering saved games in a folder: yes, we can support mouse dragging of line items to reorder saved games in a folder.
* Moving saves between folders: not sure what UX is cleanest. I'd like to hear some more suggestions on this. Maybe an action to move a save up/out of the current folder, plus another action to select a save/folder within the current folder to place it within?
* Expand/collapse folder in the UI: maybe clicking or double-clicking (or Shift/Ctrl-clicking, etc) on a saved game acting as a folder could assume this action?

Display:
* A space or two of indentation in the names for each folder level.
* Numbers to decorate folder names with content information (e.g., total number of saved games within, or number of folders + total saved games; maybe # of layers deep within?)
* Probably expand the tree to select the "Continue" saved game slot by default, wherever it is. Otherwise, folders are collapsed until (double?-)clicked on.

* We could add a "Rename" button now to rename saved games. That can be done distinctly from adding the folder model.

* We could add an option to turn off Autosaves.


Do I have all this right?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-07-2020 10:58 PM]

greenscience
Level: Master Delver
Rank Points: 164
Registered: 02-27-2015
IP: Logged

Most of this sounds like what I have in mind.

The verbs section depends on whether saves and folders are treated as separate entities or saves could be loaded and behave as folders simultaneously. My design was based on the latter to be closer to the original idea of making saves be a child of the previous save, so there is no need for a separate Add Folder button and double-clicking should load the save instead of opening the folder. With the the concept of separate saves and folders having a Add Folder button and making double-click open a folder makes sense.

For the display my design was to show the contents of only one folder at a time. Previous posts had the concern that if you have deep layers of folders then showing them all in an expandable tree view would require horizontal scrolling and be difficult to navigate.

My idea for UX to move saves between folders is to copy the import/export dialog. It has two panels for showing the contents of a folder so you can use the top one as the source, bottom one as the target, and add buttons for moving saves. One tricky part is to check whether a folder is moved into one of its sub-folders.

These are just my thoughts and takes on previous discussions so it would help if others could give their input.

mrimer
Level: Legendary Smitemaster

Rank Points: 5197
Registered: 02-04-2003
IP: Logged

greenscience wrote:
The verbs section depends on whether saves and folders are treated as separate entities or saves could be loaded and behave as folders simultaneously. My design was based on the latter to be closer to the original idea of making saves be a child of the previous save, so there is no need for a separate Add Folder button and double-clicking should load the save instead of opening the folder. With the the concept of separate saves and folders having a Add Folder button and making double-click open a folder makes sense.

Ah, I think I'm thinking of a hybrid of these two, where
* saves could be loaded and behave as folders simultaneously, and
* folders that are not traditional saves can also be manually created as a container for saves

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

greenscience
Level: Master Delver
Rank Points: 164
Registered: 02-27-2015
IP: Logged

The hybrid version can also work. Need a way to distinguish between manual folder and save behaving as a folder, maybe by omitting date+time on the manual folder on top of text color.

Meta
Level: Master Delver
Rank Points: 106
Registered: 12-06-2016
IP: Logged

It is not necessary to update the database. We can treat save names as file paths, and then render the saves accordingly. This will only require some UI level changes, and is forward/backward compatible.

The easiest and simplest way to implement a tree view would be supporting sorting the saves by save names.

---

[Last edited by Meta at 10-10-2020 01:35 PM]

greenscience
Level: Master Delver
Rank Points: 164
Registered: 02-27-2015
IP: Logged

Using file path as key in database instead of having parent column is one way to represent hierarchical structures in databases. It depends on which representation makes it simpler to implement the operations we want and might request in the future. For example renaming or moving saves around could update many more database rows with the file path representation.

One consideration is what to use as the path separator. / and \ are allowed in save names right now along with all special characters on my keyboard, not sure about more language specific ones. Some of the ASCII control characters wouldn't be a bad choice as long as the database can handle then. Newline is also a candidate since using it in save names (by copy paste) prevents the part after newline from showing up, which hides the date and time at minimal. Then again some users might like this "feature".

bbb
Level: Master Delver
Rank Points: 218
Registered: 10-07-2013
IP: Logged

I think there should be a natural tree of saves, based on progress in the game. This structure can't be changed. (Except maybe to allow pruning the tree by deleting a save and updating its parent.)

There can be another structure of "named" folders, where you can bookmark saves from the main tree.

Is the whole game history available when playing the game? I would guess it is, since it needs to be used for verifying scorepoints on the server. In that case, it would be very nice to have a way to view demos. (The demos would have to be multi-room, and the UI would need a way to skip to the next room or next 10 (or N) rooms.) It should then be possible to create a savepoint in the game history at a later time. That would clean up the save file list in a different way, since you wouldn't need to save any time you think you might be before a branching point. It can also work as a form of multi-room undo.

mrimer
Level: Legendary Smitemaster

Rank Points: 5197
Registered: 02-04-2003
IP: Logged

Supporting tree views via fully qualified save naming is an intriguing idea. Performance to manage modifications to the tree in this fashion *should* be fast enough for user comfort.

Replaying your saved game like a demo is a nice idea and could be done. Not sure how much dev effort that would entail.

Undoing back to before the previous room is also possible to implement and probably not that much work with a naive implementation. (Anyone is welcome to submit a PR with this addition at any time.)

However, please note that in a large hold with a long move sequence (e.g., Tendry's Tale), it could potentially take tens of seconds to replay all moves leading up to the previous room. A way to mitigate this would be to cache a sequence of game objects during a long move replay (say, every 1k, 5k, or 10k turns, so not too much RAM is allocated). Then the entire move sequence doesn't have to be replayed each time you undo to a previous room -- just the tailing part of the sequence -- once this series has been cached.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 12-03-2020 02:24 PM]

mrimer
Level: Legendary Smitemaster

Rank Points: 5197
Registered: 02-04-2003
IP: Logged

For 1.3, I've added the core functionality for improved saved game management:

* Renaming saved games
* Option to sort saved games by name (lexicographically) instead of timestamp in the Restore Game list box

PR

This provides the user foundational support for maintaining their own tree of saved games, as Meta proposed above, or however they'd like to manage the list.

Before we go whole hog on a revamped UI, I'd like us to try out this functionality and get a feel for what gaps yet remain.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 12-03-2020 02:25 PM]