Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Timst]

Alright, I think no one posted something about that, so let's talk about saving.

Dwarf Fortress is a roguelike. Among other things, that means that it use a peculiar game saving process, in which you can only save to exit the game in order to do something else, but not to "protect" your game, which is the main use of saving in other games. The goal of this system is to show that every action has consequences that can not be cancelled.
However, the use of savescumming (a file operation that consist of keeping backups of the save files and using it to reset the game to a previous state, along with forcefully exiting the game by killing its process with the task manager when something go wrong) is well documented and it's safe to assume that savescumming your game is the norm rather than the exception. There could be a switch in the ini file which will allow you to choose between "realistic" (= current) system and a more practical / easy one.

A list of useful features for another save system or improvement to the existing one :

- Being able to save the game without exiting it.
- Being able to quit the game without saving it (only possible currently through the use of the task manager, a harsh and potentially dangerous method)
--> A confirmation screen should appear when choosing to quit without saving.
- Being able to quit the game directly, without going to the main menu first (described in an Eternal Voting suggestion)
- A link in the main menu to automatically load the last saved game, in order to save time and avoid errors when you have a lot of saved games with similar names.
- More settings to adjust the autosave (eg, monthly, every x minutes / hours, etc.)
- Maybe the use of differential savegames to reduce the time it take to save and the size of save files ? (Might require heavy coding)


And there's probably other features that could be added.

Now, I know that a lot of people are attached to the "if you screw up, there's no turning back" method, and it sure add some tension to the game. But I also know that most people often use savescumming for a variety of reasons, and since it is already technically possible, adding an easier and safer method to do it would be a neat idea.

[Pilsu]

Even if quitting without saving isn't added, the other stuff would be really nice.

[Dbuhos]

I support this, because the random crashes and I'm tired of exiting the game after every big task is completed.

[Josephus]

Yes, this has my approval too.

[Fourdots]

Have a response! TL;DR: I'm in favor of everything on your list except items three and six, and propose an additional confirmation screen for item two. I also explain what's wrong with item six (increased vulnerability to file deletion, compression taking up most of time it takes to save, and storage being really cheap).

Having to leave the game when you save isn't a major delay, although since it clearly is possible to trigger a save without having to leave the game being able to do so manually could be useful. Killing the game with the task manager is not dangerous in the least, unless you kill the wrong task (in which case, you're not being careful and deserve the consequences), although I will admit that being able to exit without saving would be nice (as long as there's a confirmation screen, as with abandoning the fortress, to stop people from pressing it accidentally). Having to go through the main menu (and press up then enter) to leave the game after saving is not an issue unless you don't realize that the menu wraps around (pressing up at the top option brings you to the bottom option), in which case you probably deserve the horrible torment of having to press down several times.

More granular control of autosave is good, loading the last saved game is good, and only storing the deltas would be great - however, it wouldn't reduce the time it takes to save (except perhaps in the case of not needing to store world information again). Deltas are mostly useful for reducing the amount of information you have to write, or move around. It would decrease the time it would take to save if using uncompressed saves, though, as the uncompressed information is, I expect, pretty much the same as what's stored in memory while the game is running (and, operating on that assumption, the reason it can take a while to save is due to needing to compress the data). If using deltas to reduce the size of save-files, you would wind up in the unpleasant situation of the first save file being very large while all future ones are pretty small (if using autobackup), and people then deleting the first one and breaking all of the other ones. Storage being as cheap as it is[1], I don't think that this would be worth the effort it would take to implement.

[1] You can get an 80GB USB hard drive for $30, or a 2TB SATA drive for $120. Most computers have DVD writers, and a stack of ten dual-layer DVDs (8.5GB a disc) is about $7. Given that most of my saved games are under 20MB, I think I am justified in saying that, where dwarf fortress is concerned, storage is cheap.

[dree12]

I agree with most of your suggestions, except the last one, and I don't understand the third one. The time it takes to save is completely negliable already, and a differencial would take MORE time and space. The reason is that DF can't keep track of differential DURING the game without slowdown (by a lot), so to create the differential on-save would be to offload all the variables to memory, read the previous savegame to memory, and do a diff on those savegames, storing the diff in memory, and then deleting and offloading everything. Quite evidently, it wouldn't take much coding, but it has a high chance of memory leakage. DF is also a 32-bit game, allowing it 3GB¹ memory at max. The fact that DF usually gobbles up most of its 3GB is the choking point.

With our current implemation, this is what DF does:
1. DF realizes it has to save (still using 3GB memory)
2. DF offload all memory (0 memory used, 100MB written)

With your suggestion, it will take much longer:
1. DF realizes it has to save (3GB)
2. DF reads old savefile and decodes it (3GB + 100MB - overflow, 100MB read)
3. DF resorts to offloading some memory to disk (2.9GB + 100MB, 100MB written, 100MB read)
4. DF runs a diff (2.9GB + 100MB + 20MB - overflow, 100MB r, 100MB w)
5. DF resorts to offloading memory again (2.88GB + 100MB + 20MB, 100MB r, 100MB w)
6. DF offloads the diff and clears memory (0 memory used, 120MB written, 100MB r)

And, if memory is full while it does that, paging (which will slow down DF more) must occur.

As you can see, it will take much longer to run the diff. Diffs are only useful to see changes at a glance. I'm not an expert at this though, so correct me if I'm wrong.

1-Sometimes it's 2GB

[Timst]

Very well, let's forget about differential saving then

My third suggestion could be explained as a "quit to Windows" option in the menu. Confirmation screens will be a good idea also.

Fourdots : Well, I never had problem with exiting the game by killing its process, but I heard it could trigger Nemesis save failures, so better be on the safe side.

[TomiTapio]

Random crashes make me save manually after giving nicknames (militia trainee, soldier) to 20+ migrants, or after making big workshop/stockpile changes.

I never savescum, as the best part of the game is the first two hours of a new fort.