The GAME command line parameter (and the console variable of the same name) should work similar to the way CLASSPATH works in Java: a list of multiple directories and archives to search.
Advantage:
Sharing of common files among mods (e.g. VWep). Files can be called <anything>.pak instead of pak<n>.pak. Would also work if other formats will be supported, i.e. ..\mymod\mydata.zip. Allows customization of the base game by simply changing the default config file rather than actually changing the files in the base directory. Avoids dangerous duplicate use of names like pak1.pak.
The current Q2 scheme assumes that all modifications are independent. Multiple mods sharing files in a resource database style, or adding to other mods become increasingly common. There is a rising interest in multi-mod integration and plugin-style coding of mods, which would be strengthened by actual use of Java in Q3, Trinity, or in mods like Q2Java.
Disadvantage:
None known.
Implementation:
I suggest implementing the way CLASSPATH works in Java, which sets a standard. A typical Java CLASSPATH might look like this:
.;c:\jdk\lib\classes.zip;c:\myclasses
This is interpreted as follows:
1. Look in the current directory (".")
2. Look in the zip file c:\jdk\lib\classes.zip
3. Look in the directory c:\myclasses
Used in Quake, this might work something like this (assume the game directory is called eraser):
.\eraser.pak;..\vwep\vwep.pak;d:\mycustomstuff
...which would be interpreted as (assuming paths are relative to "eraser", the name of the mod:
1. Look in eraser.pak in the current game directory (".")
2. Look in vwep.pak in the vwep subdirectory parallel to the game
directory
3. Look in the directory d:\mycustomstuff (whole different drive and
complete path!)
Implied is that if these three fail the game would then look for baseq3\pak<n>.pak, baseq3\, and the same on the CD, or an alternative is that ALL these have to be spelled out, i.e.
".\eraser.pak;..\vwep\vwep.pak;d:\mycustomstuff;..\baseq3\quake3.pak;..\baseq3".
This should be a setting that can be set from the command line and also read from a config file in the game directory.
Going strictly by the Java model this scheme loses the original feature of sequentially scanning pak<n>.pak through pak0.pak, but that could be added, i.e. with wildcards (as used in Java's package referencing): "..\mymod\mypak*.pak" would find mypak2.pak, mypak1.pak, mypak0.pak.
Effort:
Carefull planning, eased by a clear cut example from Java. Implementation requires reworked command line parameter parsing.
Related:
As Paolo Perrotta pointed out, handling of savegames, config.cfg, and autoexec.cfg has to be considered as well.
Submitted 980327, revised 980507, comments to Wesley T Morrison.