Knowledge Base - Script Introduction
Introduction
A script is a set of commands that can be run either when a level starts or by interaction from the player. These commands are the same familiar commands that are used with sectors, lines and things, but they are in a written form that can be executed in a batch. A batch file, as it were, of ZDoom commands. In addition to these commands, there are a set of verbs that can be used for decision making and looping.
ZDoom uses Hexen's Action Code Script, or ACS. In fact, the ACS compiler, ACC is used to build the object file that is used in the wad. In this introduction I will go through the different elements and explain the "big" picture. In subsequent lessons, I will concentrate on the specific features of scripting.
A script is simply a text file of commands. You can use any editor you like to create the script as long as it can create a text file. The script file is usually named XXX.acs. Once a you create the script, you must compile the script into an object file, XXX.o. It is the object file, not the text file that is inserted into the wad.
Some editors offer the ability to create scripts right in the editor such as WadAuthor. In this case, you don't need an external editor and WadAuthor will also compile the script and insert it into the wad for you. I'll have a complete lesson on scripting and WadAuthor at a later date.
In the wad there are two lumps normally associated with scripting: SCRIPTS and BEHAVIOR. The scripts lump, if it exists, is the source code of the script. This is a nonstandard lump and is used by level editors to easily store and retrieve the scripts. The scripts lump is ignored by ZDoom. What ZDoom uses to run a script is the compiled version and this is contained in the behavior lump. If you create a script in notepad, for example, and compile the script using ACC then it must be inserted into the wad in the behavior lump using WinTex or some other wad tool.
Each map has its own script and behavior lumps. If a map has 32 levels, then there will be 32 separate script and behavior lumps in the wad (if the script lump is used). This is how the engine knows what script to run for what map. However, a script can also be used for a different map than the current map by specifying a map number in the script. In this case the script is queued and will run when the player enters that map. This will be covered in more detail later. Several scripts can be run at the same time, each script using a bit of processor time.
As I have already stated, scripts basically enable the level designer to run the sector and linedef commands in a "batch" mode. What this offers is greater flexibility for the level designer. No longer are we limited to one line, one action. If a switch needs to do four things, all four things can be done in a script with a single line. Scripting offers the level designer the ability to make decisions in the game world and execute appropriate actions. Maybe you want three endings to the game? This can be done in a script. Scripting should be used to enhance the game world, to create atmosphere and interaction and to immerse the player in your world.
Scripting is not only for the programmer. The level of intelligence needed to make a Doom map in the first place is the only requirement to create scripts. :) Believe me, if I can do it, anybody can. The key is to not worry about the script, but to worry about the game world. What kind of world do you want to create? Don't get caught up in the "can this be done?", syndrome. Rather think of everything you want to do and then worry about the scripting. You can always adjust the picture after you have taken the snapshot. And it may surprise you to find out that you may be able to do al lot of what you want.