Am Fri, 20 Jan 2012 00:36:11 +0100 schrieb Kiith-Sa <[email protected]>:
> You can get D:GameVFS 0.1 here: > https://github.com/kiith-sa/D-GameVFS/downloads > For basic introduction, see the tutorial in the README at > https://github.com/kiith-sa/D-GameVFS and the API documentation in the > package. I didn't check your code, but does it handle case-insensitive Windows OS as well as Unix like? Looking at the archive files of the game F.E.A.R. I noticed that at some point they started using lower case exclusively (and that game only runs on Windows). Maybe it was easier to compare directories and patches that way. The stacking of directories can also be used to patch the game, of course. What striked me as strange in said game, was that they added the game server/client code (for single player as well) in archives, but the main executable, DB driver or video codec where plain files in the base directory. So the latter got overwritten with every update, while the former just added up with each patch level, so at patch 1.08, there were 9 version of them - irreversible yet, unless you archived the old main executables as well. I'm not trying to say that an update should generally overwrite previous files, though. Just that their system didn't make sense in every bit. The separate archives for each update had one clear benefit: The first expansion was created at the time of 1.07, and they could just link in the base archives + updates up to 1.07 without running the risk that later updates to the main game would interfere with that expansion. They used a config file in the main executable's directory that listed in ascending priority, the directories or archives that should be used. They didn't reuse the main executable for expansions though, so those went into sub directories with their own configuration file that linked in base game and patches using ../some_archive. Also they split their archives, both to stay below 4GB and to have localizations (voices) in one easily replaceable file, which may be have been handy at release time. Did you think of ways to probably even switch the language from a menu? From your example in the readme, it isn't immediately clear what the names 'user', 'main' and 'root' are used for. I assume that StackDir inherits from FSDir which is a nice design, but I'd probably expect things to work out as in F.E.A.R. or Quake where these things are implementation details. In other words, the game *never* attempts a write access into it's data files, and there is only one file-system root, not necessarily a singleton. This root object then offers methods to mount directories or archives. auto fs = new FileSystem(); fs.mount("main"); // can be directory "main" or "main.zip" fs.mount("user"); // overrides main now Something like this would be nice to 'seamlessly' extract an archive to a directory with the same name. But you may have your own ideas there. Writing archive files can be difficult as some archives may require recompression or check sum creation over the whole archive. I guess most developers just release their game with read-only archives and development happens with full write access on the extracted directories through external tools (unless the game is the level editor). -- Marco
