The Drawing Board

  by Logan Everett (E-mail Me)

#4 - DLL Files and Game Modifications

In my last editorial I explained the basics of a 3D game. Now it's time to go a step further and talk about the exceptions to our "engine & data" definition. Keep in mind that none of this information is specific to any one game, it's just a general starting point. In theory, any average Joe could come along and create a game that runs completely different from any other game in the past.

If you use Windows, as most of us begrudgingly do, then you have probably heard the term ".dll file". If you've fixed computers than you know that many applications require certain ".dll" files and won't run if the file is missing or corrupted. "DLL" stands for Dynamic Link Library. It is basically a library of functions (function meaning a list of commands for processing data) that are not stored in the ".exe" file.

Why would you want to put functions outside the main program? Well, let's say you have a function for putting a pixel on the screen. It is given a position and a color, then it tells the video card to put that pixel on the screen. Obviously, any program that wants to put something on the monitor would require this function. Instead of putting that function if every program (a little repetitive, don't you think?) we store it once in a ".dll" file. Then each program can easily Link to that function, much in the way a dictionary or encyclopedia would say "See Spider Monkey". It tells the computer the information is elsewhere.

Also, let's say a program has a long, complicated function that controls the Artificial Intelligence of a monster. If the game is released, and then we find out that in rare instances the function messes up and the monster starts banging his head against the wall, we have to fix the function and release a patch. I'm sure we've all downloaded a game patch before, it fixes bugs that the designers missed before they released the game. It's very unprofessional, but no one seems to have a problem with it these days... or at least the developers don't. But anyway, if we want to fix just that function, we have to give everyone a new ".exe" file, because that's where the function is. But in the process, we're also rewriting all the other functions even though we didn't make any changes. This isn't very efficient, and people can download the patch without ever buying the game.

Now let's say, we put all our artificial intelligence functions in a file called "ai.dll". Now, when we find a problem we fix it and release a patch that's just a new version of that file. We've cut the size of the patch file (and therefore the download time) by 80% and stopped people from stealing the game. Problem solved? Unfortunately, this doesn't completely solve either problem, because even ".dll" files can get big and people will always find a way around paying for a game. Oh well.

Last week I mentioned something called entities as a type of game data. Well, they are data... sort of. An entity is more of an interface between the data and the engine. Let's go back to our bedroom example and pretend there is a stereo in the room. When the player goes up to they press a key and hear some music. The physical stereo, the part we see, is a brush and textures. It's game data. The music we hear is also game data. In addition to those things, we need a "trigger" entity connected to an invisible brush. The player can walk through this brush, and when they do the trigger entity tells the game engine to play the music. The game engine then loads the music file and moves it to the sound card using specific functions. NOTE: Triggers are not always connected to brushes, or they can be connected to visible/solid brushes. Sometimes they aren't always called triggers, but it's a common name for that type of entity. Let's just say that our entity is called "trigger_sound".

Now, this effect was created by adding some data to the Map file that says "This is trigger_sound, this is the brush that it owns, and this is the music it should play. Enough said, get on with your life." In this way, it is game data. But, to create trigger_sound, someone edited a .dll file and set up a function for this purpose. This function probably just calls a bunch of other functions from deeper inside the game engine, but it produces the desired effect. In this way, an entity is a part of the game engine. So, we say that entities are both engine and data combined. They are the overlap of the two. In older games, like Quake for example, the entities were all defined in a compiled script (written in "Quake C" for that particular game) but newer games usually use a ".dll" file for this purpose. The question remains, how does one make a "mod". A "mod" is a modification of the original game. It can be designed for single or multiplayer (assuming the original game was designed for both). For example, Lithium for Quake 2 adds new weapons and items for multiplayer games. Within the Quake2 directory on your computer is a subdirectory called "baseq2". This subdirectory contains all the game data. When it starts up, it knows that the default data folder is baseq2 and it looks there for all the data. If you create a new subfolder called "mymod" you can use a command line parameter (text that goes after the name of the program when you run it) to tell the game to look there for the data instead. Keep in mind that if the game is looking in the mymod folder it CAN NOT go back to the baseq2 folder unless you exit and restart the game. If you still want to have a grenade launcher in your mod, all the sounds/models/skins/entities must also be in your folder. For this reason, most people don't just build a mod from scratch. Granted, the game developers have to because they are creating the very first mod for their game. But, in most cases people edit this original game data and pack it all back up in a new folder.

One last note on mods. A mod can do more than just change the entities. It can also create a new HUD (Heads Up Display - the information around the edge of the screen that tells you how much life you have, etc.) and new commands to bind to keys on the keyboard. When all is said and done, a mod can make a completely new game experience that simply uses the same quality of 3D and sound as the original, if someone is willing to put that much time into it.


Page Updated: 1/24/00