Chapter One: The Architecture of Starcraft Data Pros, Cons, and other Methods of Input In the overall scheme, my intent is to convince you that using SECWADs is the best method of distributing your custom to users, but that is only my opinion. So, to be fair, I'll try to point out some of the benefits and faults of this method, and others, such as Custom MPQs and directory emulation. Directory Emulation This is the one method of giving the Starcraft Engine custom input that we haven't talked about yet. Basically, you can replace most WAV (sound) and SMK (smacker video) files in the MPQs simply by putting them in those directories in your Starcraft folder. For example, to replace the first "response sound" from the Sarah Kerrigan unit, which has the MPQ location (Stardat.mpq) of sound\terran\kerrigan\ukewht00.wav, you can simply make that subdirectory tree in your Starcraft\ folder with your custom WAV as ukewht00.wav and Starcraft will load it instead; or to replace the first SCV idle portrait (displayed on the status bar), which is located in the Stardat.mpq location of portrait\SCV\TSCFid00.smk, you can simply make the sub-directory tree portrait\SCV\ in Starcraft\ and place your replacement TSCFid00.smk there and Starcraft will load it. This will work for any WAV file in the MPQ files (but not Install.exe) and all SMK files (even the movies on the CD). Unfortunately, it does not work for any other files, and is a bit of a pain to uninstall (since if everyone distributed custom sounds and portraits in this manner, players would have to keep track of a lot of different portrait\ and sound\ subdirectories to prevent files from one custom to overwrite those from another). Custom MPQs The major benefit to compiling a custom mpq is that they seem pretty "professional" (since Blizzard uses them too of course :). With a modified EXE, the player just needs to place two new files in their Starcraft directory and with one click, they're off, and no messing installation or uninstallation is necessary. However, there are drawbacks. First, there are many files that Custom MPQs (acting as patch_rt.mpq replacements) are not capable of replacing, such as BIN files in the Install.exe (screen layouts). But, to be fair, there are also files on the CD that they can replace that Stardraft currently can not, such as the Install.exe WAV files (music and campaign scenario sounds). Also, SMK files in custom MPQs can not be compressed, otherwise they will not function. This can lead to some hefty file sizes (though zipping it will compensate for most of it). Lastly, with the advent of tools like Stargraft which also patch EXE data at runtime, it may become too much of a hassle to toggle between a custom EXE, a custom MPQ, and a custom Stargraft PAT and/or SECWAD with a PAT inside. Nevertheless, Custom MPQs do have one major advantage over current Stardraft patches. You can add new files into a custom MPQ that weren't originally there and Starcraft will still read them. SECWADs The major advantage I think SECWADs have is that they are compact, easy to use, and, overall, smaller than the other two methods. With the inclusion of Stargraft PAT files, the user only needs one executable which does all its patching in memory so there is no residue left behind. However, as mentioned before, SECWADs can not currently patch WAV files in the Install.exe and can not push files into memory if there is not an original to replace in the MPQ to begin with (probably because Starcraft does not allocate space for the new file). However, SECWADs are still evolving, and with the reinvention of Stardraft later, we may see these options added. Which method or combination of methods you use to distribute your custom really depends on what you need to do. If you only require altered sounds and portraits then maybe the first method is the way to go; if you need to replace the game music, then you'll probably have to go with the second; but for everyday customs, and most in general, your easiest choice is probably the last. |
Copyright (c) 1999-2000 Jeffrey Pang.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the
Free Software Foundation with no Invariant Sections, with no
Front-Cover Texts, and with no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
[an error occurred while processing this directive]