[Scummvm-devel] Global menu save/load dialogs
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
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
> - 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?
More information about the Scummvm-devel