Game Development Reference
In-Depth Information
that the logic behind a game engine is a computer's logic for the most
part, but tailored to how that individual game is structured. In other
words, a lot of that decision making is ef ectively out of your hands—you
have to work within the limitations that you're given.
Keep in mind we all work with computers and machine logic every day.
We use DAWs and other programs in order to make music and to design
sounds. And we all have to deal with the limitations of what the tools can
do. Limitations are a fact of life and game engines are no exception.
As far as getting the sound into the game—audio i les are regarded by a
game engine as an asset, essentially no dif erent from any other asset, in
basic principle. Most game engines will have one central area where all
of the assets are stored—this is usually some kind of folder or directory.
In order for the game to use the asset it generally has to be in the
directory. In high-level development studios with a lot of team members,
the directory will likely reside on a central server and the assets will
be copied to it. In these cases version management through a tool
like Perforce will be almost mandatory—with so many team members
working on the game submitting changes, the ability to revise stable
changes to the codebase becomes essential.
Getting the sound into the game can depend on a lot of factors. Probably
the most obvious question is whether you need to be concerned with
doing the importing of the sound in the i rst place. So let's say you
are tasked with this importing—the next real obstacle is whether you
can. Many game engines (especially for 2D games) are actually almost
completely code based and have no editor to speak of outside of their
IDE of choice or a common text editor. Thus putting the sound in the
game in that case is literally copying the sound to the main directory
or subdirectory of the game project. The game code then has to know
where exactly these i les reside (in technical terms applicable to coding
this is called the i lepath).
The remaining category is the more GUI-driven game IDEs like UDK and
Unity, and here you can easily import an asset of any kind, including
sound i les. Once imported you may be able to use the game engine
to adjust qualities of assets depending on your design desires. For
example, is your sound a sound ef ect or a music i le? Is it regarded as
a 3D sound or a 2D one? Do you want to compress the sound in the
engine? And so on . . .
Once these questions are answered we need to move into how the
sound is triggered, and here we have to get at least a bit into naming
conventions again. This is the common ground here—what you
call the sound i le is extremely important to a programmer, and the
codebase might be organized in a very specii c way. For example, let's
