[Scummvm-devel] Global menu save/load dialogs

Max Horn max at quendi.de
Tue Nov 11 11:15:07 CET 2008


I just noticed that I should reply to some points in the starting post  
of this thread, so  I do that now.

Am 10.11.2008 um 10:57 schrieb Filippos K:

[...]

> Now, it would be also great if all engines that support the GMM save/ 
> load dialogs would have some sort of unified save games. In  
> particular:

Let me state on thing: One of the main design points behind the whole  
way we handle the "unified" savestate support is the desire to *not*  
force engine authors to adapt their code (and potentially screw all  
users with existing savestates). Instead, we wanted to provide a "high- 
level" API and let Engine authors decide how to best implement it.  
Requiring Engine authors now to change their internal implementation  
after all kinda goes contrary to that idea; if that's the plan, then  
we should have designed some things very differently from the start, I  
think... :)


> - It would be great if save game indexes would not be used at all

I agree with that -- indexes make it difficult for users to copy  
savestates between machines. It also means we have to points of  
failure when saving/loading -- e.g. we might be able to modify the  
index file, but not to store the save itself, which easily results in  
an invalid index. Ooops. And it's easy to work without and index, too.  
So for any new engine, I would *highly* recommend working without an  
index file. In fact, I am tempted to make this an requirement.

However, changing existing engines to not use an index anymore is  
problematic. The main problem is not to punish the user when doing  
this. Each engine doing such a thingwould have to implement code which  
detects "old" saves and tries to convert them automatically to the new  
system. This is a lot of work, and if not done with great care, may  
lead to data loss for the user. Bad PR, not a good thing

So it *can* be done, but is it really worth it?



> - It would be nice if save game extensions would be 3 digits, which  
> would allow us to use 1000 save slots in all engines. Currently,  
> there are engines line cine which only support 10 save slots,  
> because their save/load dialogs are very limited

Why would we need this? The generic code asks the MetaEngine how slots  
map to filenames anyway -- no need to force a common naming scheme, is  
there? I feel that the 99 slots provided by SCUMM are far more than  
enough :). Heck, for most people, 10 are enough; I only need more  
because I tend to keep dozens of test saves around :).



However, there is one thing about savestate naming I'd like to point  
out to all Engine authors: Highly consider adding the game *target* to  
the name of your savestates as a prefix. We do this in SCUMM. Second  
best is to use the gameid. At the very very least, use the engine name  
as a prefix.

Only this way can we avoid clashes between multiple incompatible  
variants of the same game, and worse, clashes between different  
*engines*. Assume for example that an engines needs to store a file  
called "index" -- it's not unlikely that another engine needs to also  
keep such a file. Voila, big problem. This problem would not exist if  
everybody used a prefix.

You should only use the gameid or engine name as prefix if you are  
absolutely sure that the file is interchangeable between all variants  
of the gameid, resp. between all game variants supported by your  
engine. Even then, ask yourself: Does it make sense to share this file?

In particular, I am quite unhappy about the "SAVEGAME.*" files used by  
Sword 1. :( We even have an open bug report on that, I think.


Maybe this as well as the advice on not using an index file should be  
kept in the Wiki somewhere; maybe we should add it to the Engine  
HOWTO, or add an "Engine best practices" page listing this, and  
linking to the advance features page, too?



Bye,
Max





More information about the Scummvm-devel mailing list