Table of Contents
It is important to be aware that there are three main parts of modern first-person shooters, all of which you can modify. The following list summarises these parts and how modifying them can affect the game.
The engine is the part of the game that computes all of the 3D graphics and takes care of other low-level issues such as sound, networking and receiving input from the keyboard and other peripherals.
Modifying the engine may result in vastly different appearance (some mods for Quake have made it appear drawn as if it were a cartoon, or pencil outline drawing, for example). It may also improve the output of sound and/or networking capacity.
Gamecode is the high-level code that determines how the gameworld works. It controls things like how the player interacts with doors and buttons, how the weapons and powerups work and the behaviour of monsters.
Modifying the gamecode can introduce new enemy or friendly characters, upgrade or replace weapons, items and alter the way that the environment (doors, slime and so on) works. Modifying the gamecode to create new gametypes is one of the most popular ways of developing with modern computer games and is relatively easy to do thanks to the high-level nature of the gamecode language (“QuakeC” in this case).
The engine and gamecode are pointless without content that can be supplied to the user. The maps, textures (graphics applied to the 3D environment to increase realism), models (3D shapes of enemies, items, weapons), skins (textures applied to models) and sounds presented to the user are collectively known as the game data.
Modifying the data alone can have a striking impact on the game, from adding new environments (maps) to making existing ones appear quite different. Different player and enemy models can also change things quite a bit (and are popular online). Sounds (such as the mindgrid expansion pack) can improve the player's experience significantly and alter the feel of the game.
A “Total Conversion” of a game with this architecture is a modification that replaces all components of the data, gamecode and engine with modified versions. We welcome anyone to create TCs that turn AudioQuake into the accessible 3D game they've always wanted to play!
When running, the game “AudioQuake” is actually made up of the following semi-separate parts:
ZQuake is a mainstream QuakeWorld engine that has been made accessible by a series of small modifications. The maintainers have kindly allowed it to be used by the AGRIP project as the basis of AudioQuake.
The standard QuakeC gamecode has been customised to include a library of accessibility features. It is here that 90%+ of the AGRIP code runs.
A front-end to the engine that helps users set accessibility options and provides a channel for text-to-speech data to exit the engine for further processing before it is rendered. This allows us to provide high-level processing on text generated by the game that is inappropriate for the engine to deal with. It facilitates the use of multiple speech/braille back-ends, though this has not yet been used.
To build yourself a working release, you'll need the code for all these parts of the game, as well as the game data. The data is the sounds, models, maps and textures that make up the game world. The gamecode directs the engine to play/render the data at the appropriate time (for example, the gamecode for the D5k tells the engine when and where to play sounds that correspond to items in the map).
Building the supporting tools and documentation will be covered in later parts.