An Unreal "package" is a collection of related objects such as textures, sound effects,
and scripts which are grouped together for convenient distribution and use.
For example, in Unreal, textures are stored in texture package files, which use the ".utx" extension.
A .utx file contains many (tens or hundreds) of textures which are part of a similar theme,
such as the "SkyCity.utx" texture package.
Unreal's file format is based on packages because packages enable the game engine and content to be
developed modularly. Artists maintain their textures in .utx files; the programmers working on the
engine and game maintain separate packages of UnrealScript classes; people in the Unreal community
can create and distribute their own packages online; and so on.
One package may refer to objects which are contained in another package.
For example, an .unr level package may refer to textures which reside in various
external .utx files; sounds in other .uax files; and music i in a .umx file.
We say that the level file is "dependent" on the other packages.
To load that .unr level file successfully, you need to have all of the other .utx,
.uax, and .umx files which that level refers to. If one of those packages is missing,
you will not be able to load the .unr file.
All Unreal package files are stored in the same binary file format, but they use
different extensions to identify their type:
.UTX files are packages of textures.
.UAX files are packages of sound files.
.UMX files are packages of music.
.UPX files are prefab for UT 2003 and 2004.
.UNR files are game levels.
.UKX files are animations (UT 2003 and UT 2004).
.KA files are Karma data files (UT 2003 and UT 2004).
.USX files are packages of Static Meshes (UT 2003 and UT 2004).
.U files are packages containing UnrealScript classes and objects
(like textures, sounds, and meshes) they contain.
When the Unreal engine needs to load a package, it looks in the subdirectories listed in
the [Core.System] section, in the Path#= list. The relevent lines of the clean (unmodified)
Unreal.ini file look like this:
[Core.System]
CachePath=..\Cache
CacheExt=.uxx
Paths[0]=..\System\*.u
Paths[1]=..\Maps\*.unr
Paths[2]=..\Textures\*.utx
Paths[3]=..\Sounds\*.uax
Paths[4]=..\Music\*.umx
When you try to load a package by its raw name (such as "SkyCity"), the engine first searches
in the CachePath for a matching package downloaded from the Internet; then it searches in each
of the numbered directories in order (0, 1, 2...) for matching files.
For example, it looks for \Unreal\Cache\[some funky name].uxx, then \Unreal\System\SkyCity.u,
then \Unreal\Maps\SkyCity.unr, then \Unreal\Textures\SkyCity.utx -- and the file \Unreal\Textures\SkyCity.utx
does exist, so it uses that file.
Because of this storage and search scheme, you must not create two packages with the same base name,
which only differ by extension. For example, you must not create a texture file named SkyCity.utx
and a music file named SkyCity.umx. If you do that, the engine will always fail to load one of the
packages and give an error.
All Unreal package files (.utx, .uax, .umx, .unr, and .u) use the exact same file format,
and are processed in exactly the same way by the engine.
The only reason we define different extensions is for convenience, and to interoperate with Windows cleanly.
For example, .unr files are known to contain levels, so we associate the Unreal icon with them,
and set them up so right-clicking on an .unr file in Windows launches Unreal.
And, UnrealEd knows that .utx files contain textures.
The meanings of these file extensions are purely superficial.
They all use the same file format.
Whenever you save a package file to disk, the file is internally stamped with a GUID
("Globally Unique Identifier"), which is a 128-bit number which is guaranteed to be unique.
In single-player play, this GUID is never used and is irrelevent.
However, when you connect to an Internet-based server, the server sends a list of packages
that are required for gameplay there (for example, the level it uses, any texture packages
it uses, any sound packages, etc). These packages are identified by name and GUID.
If you don't have one of the packages required by the server, the package file is automatically
downloaded to your \Unreal\Cache directory, and given a filename based on its GUID.
A typical \Unreal\Cache directory looks something like this: Directory of F:\Unreal\Cache
06/02/98 03:37a < DIR > .
06/02/98 03:37a < DIR > ..
06/02/98 03:37a 8,932 2306087A11D1E2FD4F00DBA5CAA00349.uxx
06/02/98 03:38a 8,932 2401042A11D1E2FD4F00DBA5CAA00381.uxx
3 File(s) 8,932 bytes
698,601,472 bytes free
Packages stored in the \Unreal\Cache directory are identified by their GUID rather than the
package name given to them by their creator, to avoid conflicting names.
For example, there are bound to be a ton of levels on the net called Test.unr, a ton of textures named
Walls.utx, etc. The GUID scheme avoids conflicts.
In UnrealEd, each time a package file is saved, it is assigned a new GUID. This way, each version of
a package is guaranteed to be tracked and cached separate from other versions. This is good, because
it prevents people from trying to play on a server using different versions of a level.
This is bad, because if you simply load a texture file, resave it, and copy it to your UnrealServer,
all of the players who come to your server will have to re-download the package.
Therefore, we recommend modifying your package files only when necessary, and releasing them only after
enough testing and use that you know they're not going to change and force redownloading
a day later -- especially with large package files.
Packages enable an open plug-in architecture for easy community and licensee extensibility.
Packages make the Unreal engine expandable in content, UnrealScript code, and C++ code.
Packages help to improve the modularity of the code and reduce interdependencies.
Packages make it much easier for licensees to separarate the Unreal engine from the Unreal game.
Packages simplify Web-style downloading of content in Internet play.
Core The high-level framework Unreal is built on, similar to the MFC core or the Java
Virtual Machine. The Core package contains the definitions of object, class, subsystem, script,
property, name, and the object manager. The core is indepenent of any notion of a game or 3d engine.
Engine The Unreal 3d engine, including support for vector math, actors, physics, collision, interaction,
cameras, and networking.
Editor The UnrealEd 3d editing environment with geometry editing, realtime lighting, and actor
editing support. Render The Unreal rendering engine implementation. Window The platform-specific
code supporting Unreal. Galaxy The implementation of Unreal's sound system (UAudioSubsystem) running
on top of the Galaxy sound system for Windows. It is possible (for example, when porting Unreal to
another platform) to completely replace the Galaxy package with an implementation of another sound system.
GlideDrv Unreal 3d hardware support code for 3dfx's Glide library.
UnrealI The Unreal I game implementation.
WinDrv Windows viewport and client driver.
SoftDrv Software rendering driver.
Fire Fractal fire and water effects.
IpDrv TCP/IP networking driver.
Copyright © 1996 Epic Games |