Re: [Alephmodular-devel] TS Draft: File abstraction

[Woody Z. I. <woo...@sb...>]

On Monday, January 27, 2003, at 10:02  AM, Br'fin wrote:

> Ok, I've done some more changes and been trying to think more things  
> through. Here's my updated design document for the file abstraction. :)

Five comments... and then some standard me-style tangential 
increasingly-off-topic blathering.

1.  First off, well done!  This is looking like some pretty good stuff 
to me.

2.  Just a reminder that there ought to be a way to enumerate the 
entries (probably optionally matching a type) in a directory.  (This 
probably will be later fleshed out in the "stub interface for now" for 
directory desc's.)

3.  Should the Unknown file type really never match anything, including 
Unknown file type?  I understand the reasoning - if you can't tell what 
type it is, you surely can't tell whether it's the same as some other 
type you don't recognize - but I could see it being useful in certain 
circumstances to be able to, say, enumerate all the files in a directory 
that *aren't* recognized as some other type.  Maybe this uses a special 
enumeration call rather than the Unknown type designator, etc.  Shrug.

4.  Perhaps there should be a distinction drawn in the interface between 
"looks like" a type (quick to determine from extension/Type Code/etc.) 
and "really is" a type (requires examining the file contents to be 
sure).  I know you proposed a 'toggle', which might work out, but having 
this explicitly exposed in the interface will make programmers think a 
little more about what they're really working with (which may be 
particularly good for files that Look Like, say, Shapes or something, 
but Really Are, like, umm, a film file).

5.  Should types be hierarchical?  (Is this already implicit in your 
design?  sorry...)  That is, I mean you talked about a general "Shapes 
file" identifier that encompasses several specific Shapes-file 
representations I think, but I got the impression there was a strict 
two-level hierarchy there, probably with the general identifiers and the 
specific identifiers in two separate matching spaces.  Instead, should 
there be a more general, potentially multi-level matching mechanism 
that's a bit like, perhaps, class inheritance?  So one can ask for 
things matching some more general type and get things of various 
specific types that are subtypes of the general type?

Of course hmm kind of harkening back to some of my earlier notes in this 
regard, I'd advocate hiding the distinction between a Shapes file and a 
Sounds file etc. as much as possible, and treating all such files simply 
as 'archives of objects'.  An m2-format Shapes file happens to provide 
only objects of type M2 High-Level Shape, M2 Low-Level Shape, M2 Bitmap, 
M2 CLUT, etc. (whatever's in there), but in the future potentially some 
single new-format archive file could contain Shapes information, levels, 
terminals, etc. all together.  This means that instead of caring about 
what type a file *is* (except for finding the appropriate file-decoder 
to use), we care about what kinds of objects (and there could be many, 
per file) a file *provides*.

So, if we play an M2 Level, it refers (thanks to the M2 Level Unpacker 
object) to the monster type M2 Trooper, which the engine finds in a 
'bio' somewhere (possibly compiled-in, possibly not).  The bio (right?) 
refers to the M2 Trooper Shape information etc., which the engine 
locates one way or another in some M2-format Shapes file.  The user 
chooses only the level (possibly implicitly, by starting to play a 
scenario, or by linkage from another level); the level determines the 
Bio; the Bio determines the other objects needed.  The user never deals 
with any of this "Environment" nonsense (though there ought to be a 
mechanism for optionally explicitly overriding one thing with another, 
so that the user can choose to play M1's Waldo World Arena with all M1 
standard stuff but using his own "Jetpack" physics model instead of the 
normal M1 physics model - or M1 Waldo World Arena with M1 weapons and 
wall textures etc. etc. but with all major Pfhor replaced with Moo 
Hunters, or whatever... this latter would probably require some sort of 
configuration file be created and specified; I wouldn't expect to be 
able to set up a situation this complex in the game's UI).  Note that 
this approach allows for future (significant!) expandability/flexibility 
without compromising support for existing files as-is.

The M2 Shapes loader (etc.) could be told what names to use for the 
objects it finds by an additional external naming file.  This way 
existing scenarios could use their standard data files as-is, but could 
provide differently-named objects by way of these drop-in add-on files.  
(Perhaps these naming files could specify which files they apply to by 
checksum etc. so that there could be a standard distribution of them, 
covering all existing scenarios that folks have bothered to create 
naming information for - but without of course requiring that the user 
actually *have* all the scenarios already.  This way users can download 
and use existing scenarios - in their existing distributions - but AM 
can still benefit from the generalized referencing.)

Yeah I'm going to keep advocating this 'runtime dynamic linking of game 
objects' model because I feel strongly that it's The Right One.  :)  At 
least, until it's sufficiently refuted or a stalemate appears (as in the 
SDL-as-baseline-platform debate).

While we're at it, should we talk about the possibility of keeping some 
sort of table of properties about files?  Like a quick index of what 
we've determined various files to Really Be, a unique identifier for the 
file contents a la the 'checksum's role in Bungie's formulation, to 
locate the correct file (for film playback, netgame, etc.) even if its 
name has changed, what objects the file provides, etc.?  Ehh, probably 
not, these operations are probably used infrequently enough that it's 
not worth keeping a separate table.

Well hmm I mean, I had pictured storing this table on disk, which is 
probably a bit unnecessary, but OTOH caching/memoizing the results of 
operations like Really Is in memory (during a single run of the 
application) may be appropriate...?  Not that this has to be addressed 
now of course, just thought I'd mention it before it left my brain again.

Woody