============================================================================= _ ///// ///// ////// ///// ///// __ _ _ _ ___ | | _____ // // // // // // / _` | | | |/ _ || |/ / _ \ ///// ///// ////// // ///// 2.1 | (_| | |_| | (_||| < __/ // // // // // \__, |\__,_|\___||_|\_\___| ///// // ////// ///// ///// |_| ============================================================================= The Most Sacred and Most Unofficial Quake Technical Specification. As derived by Nezu the Unworthy (montanuy@dmi.ens.fr) From the holy Long Words of the id Gods found in an Ancient Scroll retrieved by the Vandals and read according to the Lores of the Cavemens. --------------------------------------------------------------------------- Sure, go ahead. But all that info is way outdated. Everything has changed. -- John Romero --------------------------------------------------------------------------- List of Contents 0 Introduction 1. New WAD file 1.1 Directory 1.2 Pictures Format 1.3 Wall Textures Format 2. Level Maps 2.1 Organisation 2.2 Level 2.3 Sectors 2.4 Walls and Skies 2.5 Texture references 2.6 Planes 2.7 Vertex 2.8 Nodes 2.9 Visibility lists 2.10 Light maps and lighting 3. Entity Models 3.1 Organisation 3.2 Animation 4. Sound Capabilities 5. Network Capabilities 6. Miscellaneous Information 6.1 The Quake programming language 6.2 Definition of entities 6.3 Definition of light maps 7. Final word --------------------------------------------------------------------------- 0. Introduction Yes, I know what you're saying. It's not possible. It can't be. It's another ridiculous hoax. A complete nonsense. Probably some llama's joke. Well actually, if you feel that way, you're right: So don't read that specification. It's obsolete, outdated, completely imagined from scratch and doesn't even bear any remote relations to Quake. All my imagination. Go back to DOOM editing, and assume you've been very clever! --------------------------------------------------------------------------- Legal Warning Quake is a Trademark of id Software, inc, hereby acknowledged. The technical details presented here are all Copyright id Software. This document is not an official id Software publication. Do not bother id Software concerning the contents of this file. This document is copyrighted. You are not allowed to publish it via any electronic or non-electronic means without the explicit consent of id software. You are not allowed to put any part of this document on non-free support (like magasines, newsletter or CD-Rom) without my prior consent. In no event shall I be held responsible for any degradation of your health, wealth, mental sanity or social relations. All rights reserved. No guaranty. That's life! --------------------------------------------------------------------------- Thanks This document would not have been possible without the hard work of id software (of course) and some hackers whose name is not to be made public without their consent. I think I did my share of hard work, but it was considerably easier than what any of them did. So mainly thank them, not me! Special Thanks to Jens Hykkelbjerg for the HTML version. --------------------------------------------------------------------------- 1. The new WAD2 format It is expected that the WAD2 format is only temporary. Quake will probably directly read common picture and sound formats. However, stuff like MIP textures and Alias models might not be very easy to store in a traditional file format, so it is still possible that WAD remain in use. 1.1 Wad Directory // WAD Header struct QKHEADER { char Magic[4]= "WAD2"; // Name of the new WAD format long NbOfDirEntries; // Number of entries long DirPosition; // Position of WAD directory }; // Directory struct QKENTRY { long Start; // Position of the entry in WAD long Wsize; // Size of the entry in WAD file long Size; // Size of the entry in memory char Ident; // Entry identification char Cmprs; // Compression short Dummy; // Not used char Name[16]; // 1 to 16 characters, '\0'-padded } Dir[NbOfDirEntries]; // like in DOOM 1.1.1 Entry identification The field Ident in the directory identifies the entry. It's a single byte, which give 256 possibilities. Only 3 are actually used for the moment. 0x40= '@'= Raw bytes (Console, Color Palette) 0x42= 'B'= Pictures (for status bar) 0x44= 'D'= MIP Textures (for 3D brush models) 1.1.2 Color palette Format This format is Exactly the same as in DOOM: struct RGB {char R; char G; char B;} Palette[256]; 1.1.3:Console lump format Modifying this console lump is of very limited interest, anyway here is the format: The console lump is a similar in structure to the flat pictures of DOOM. It's a simple lump of color indexes: char Console [192][128]; //This means it's a 128x192 array The first 64 rows are devoted to the decription of the character font (each ASCII character below 0x80 has a 8x8 cell attached to it. The characters below 0x20 are special). The rest of the picture is made of four 64x64 quadrant: one grid, and threes other with somewhar random texture. These might be some background for the maps. Who cares actually? 1.2 Picture Format The pictures will probably used for everything concerning the status bar (animations, numbers, ...). They are not used for sprites, countrary to DOOM. This is essentially the same format as in DOOM, except that the picture is drawn by row, not by columns, and that 16-bit numbers are used, because a screen is 320 or 640 wide. // Picture header struct QKPIC { long Width; // Picture width long Height; // Picture height long Row[Height]; // Offset to the rows, from start of picture } // Each column is a set of lumps, placed one after the other. // if for a lump Hpos=0xFFFF, then it's the end of the set. struct PICLUMP { short Hpos; // Horizontal offset short Count; // number of pixel char Pixel[Count]; // pixels color index (in current palette) char Dummy[Count&1]; // to align the structure PICLUMP on 16-bit boundary } 1.3 Level Wall Textures The MIP Textures are very special pictures, made of a set of 4 pictures, scaled by 1, 1/2, 1/4 and 1/8, in order to avoid the Aliasing effect that made DOOM walls and floors look so jerky in the distance. Those textures are used to cover the walls, the floors, the ceilings and the skies surfaces. Actually, they just cover any surface. Those textures are NOT used for sprites or Entity models, so those models are not (yet?) protected from ugly Aliasing effects. 1.3.1 Texture names The names of textures can contain up to 16 characters. If the texture is not animated, the name can be anything, provided the first character is not '*', the asterisk. 1.3.2 Animated Texture names If the texture is animated: * the first character is '*' * the second is '0' plus the frame number of the texture * the third is '0' plus the number of frames So for instance an animated sky will be composed of 3 textures: 1. *02cloudsky 2. *12cloudsky 3. *22cloudsky 1.3.3 Texture Lump format When stored in a WAD, the MIP textures are made of just one lump, containing a header, then the texture scaled by 1, then by 1/2, then by 1/4, then by 1/8. //Texture header struct TEXHEAD { char Name[16] // Texture name, useless. To be removed? long W; // Width long H; // Heigth long Scale1Pos; // pointer to Tex, scaled 1 long Scale2Pos; // pointer to Tex, scaled 1/2 long Scale4Pos; // pointer to Tex, scaled 1/4 long Scale8Pos; // pointer to Tex, scaled 1/8 } // At offset Scale1Pos, from start of file // Picture, scale 1 char Tex1[ W*H]; // At offset Scale2Pos, from start of file // Picture scaled by 1/2 char Tex2[ (W/2)*(H/2)]; // At offset Scale4Pos, from start of file // Picture scaled by 1/4 char Tex3[ (W/4)*(H/4)]; // At offset Scale8Pos, from start of file // Picture scaled by 1/8 char Tex4[ (W/8)*(H/8)]; All those Tex1, Tex2, Tex3, Tex4 represent color indexes, And the picture is 256 colors. The picture palette is usually indicated in the begining of the WAD that contain a set of textures. The color palette index zero is used to represent transparency. 1.3.4 Texture Anti-aliasings (Nonsense ahead. Go get some Aspirin) The sampling theorem states that when you sample any signal (sound, picture, anything) the highest frequency contained in this signal must be at most one half of the sampling frequency. If there is any frequency above that, the sampling process will map it into a lower frequency, thus creating a terrible mess into the sampled signal. This mess is called Aliasing. When you try to display a picture on a smaller space, you increase all the frequencies contained in that picture, and thus risk Aliasing. That's basically what happend in DOOM at long distance. Now, all you need is only to low-pass filter the picture, with a cut frequency equal to half the sampling frequency. Easy! But... There is no DSP on the video memory, so those calculations would take too much time. It's much easier to pre-calculate 4 scaled down pictures, that can be used across the most common range of scales: infinity-1, 1-1/2, 1/2-1/4, 1/4-1/8. Below 1/8, there will be some aliasing... Here is how the right texture is selected in Quake: int R_MipLevelforScale(float scale) { if(scale>= 1) return 0; // 1 and above. no aliasing. if(scale>= 0.4) return 1; // shouldn't it be 1/2 ? if(scale>= 0.2) return 2; // shouldn't it be 1/4 ? return 3; // down to 1/8 (below, aliasing!) } --------------------------------------------------------------------------- 2. Level Map structures The level structure looks fairly complex, but it contains only the minimal amount of information. In that respect, it is much cleaner than the level structure of DOOM. It seems clear that with Quake, id has learnt how to make almost optimal use of 3D BSP tree. This 3D structure is real simple compared to the formats used by 3D Studio or even POV, so conversion should be possible. However, Quake will also necessitate 3 special structures which are not common to 3D graphic packages: 1. A 3D BSP tree, optimised for speed (minimum number of face splits, and minimum number of nodes and leaves). It's not that hard to calculate, but it's hard to optimise correctly. 2. One visibility list per leaf, also optimised for speed (only the leaves that can actually be seen from another leaf should be there). It will probably require rather tedious calculations. 3. A light map, that is used to make the rendering of surfaces more realistic. I have no idea how this can be handled. 2.1 General description of levels A Quake level is basically organised around a huge BSP tree. All is derived from the BSP tree, and all depends on the BSP tree. So if you don't like BSP trees, forget about making Quake editors. Of course, if you intend to edit Quake levels, chances are that you will never have to deal with the BSP tree itself. What you will edit is a rather complex 3D map, a bit like those of DESCENT, except that almost any shape is allowed, not only combination of cubes. Quake will require a very clever 3D editor, because there seems to be quite a lot of things to calculate that can't entirely left to the user, light ambient lights, alignement of light maps and texture offsets. 2.1.1 Level boundaries: The levels are considered by Quake only as a kind of entity, like any other entities, and it seems possible to put one level inside another. Although this sounds a bit strange, it could be useful in order to 'smoothly' transit from one level to the other. In DOOM or even in HEXEN, there is only one level displayed at the time, so transits between levels must be done via teleports. This may not be the case in Quake. 2.2 Level organisation So here is the level organisation on a file. As mentionned before, it is a huge BSP tree. All the components of this tree are detailed below, but first here is a general description: the BSP tree is made of nodes, starting with a root node, which has two childs, which in turn have two childs, and so on, as you go down the branches of the BSP tree. The nodes only represent a way to partition the space, they do no ever appear in a level. Some of the childs are extremities of the branches. They are called BSP tree leaves, and in fact each branch must be terminated by one leaf. Those leaves are in fact portions of the actual 3D level, and usually they represent portion of rooms. So to any leaf is associated one or more surfaces, that represent the actual walls, floors, ceilings and sky for this portion of level. Those surfaces are defined by a plane in which they lie, an ordered set of vertex, that define their boundary, an constant base light level, a single texture, and a light map and offsets for the texture. The textures are defined by a reference to a picture or a set of animated pictures, some base offsets, and some flag that say if they must be flipped horizontally, vertically or both. I seriously doubt you could make any sense of the above, so there is some more details, to add to the confusion. If by the end of this chapter you still don't understand how the level are organised, go play DESCENT to increase your experience with 3D volumes :-) 2.3 The Tree Leaves (Sectors) The tree leaves are the Quake equivalent of the sectors in DOOM. You can imagine them as rooms, or part of rooms, where the monsters, players and object will be placed. Actually the tree leaves are the equivalent of the Sub Sectors: each sector in DOOM is decomposed by the BSP into smaller and simpler convex sub sectors, that contain only part of the sector lines. Technically, each tree leaf, made of some surfaces and bound by the BSP node split lines, appears in 3D space as a convex polytope. Think of them as big rooms without any corners where you can hide from any part of the room. (Sorry, I'm just trying to be AOLicaly correct). Well, if you don't understand the above, I'm real sorry but the best you can do is go ask your mother for a system upgrade. Technically, a tree leaf is defined by * A bounding sphere (an origin point and a radius) * A list of Surfaces (a first surface, and a number of surfaces) 2.4 The Surfaces (Walls, floors and skies) The surfaces represent the visible boundaries of a tree leaf. The surfaces are the Quake equivalent of the Sidedefs of DOOM, in the sense that they tell what sector boundaries look like. Depending on the name of their texture, they will appear are a sky texture, or as a wall or floor (that can eventually be animated). Note also that though the skies are ordinary wall textures, they are drawn in a very special way, that make them look like skies. That is basically the same trick as in DOOM, except that it doesn't need to use a F_SKY fake sky marker. The surfaces will be rendered as a texture-mapped polygon. The texture somewhat takes into account the distance, for better realism. Technically, the polygon is split based on the inverse of the distance, and fragments are mapped linearly. The texture mapping also takes into account the orientation of the surface, because calculations of points in texture space is done by selecting only 2 coordinates among the three coordinates of the points. So depending on the orientation of the surface, the most representative set of coordinates must be chosen. Technically the surfaces are defined by: * The plane where they lie in, (for distance calculations) * An indication that they are on the front or back side. * A set of vertex, ordered, to that the segments from one vertex to the next actually represent boundaries of the surface. * A texture, and a rectangle in texture space, so that the same texture may be used differently for many surfaces * A constant light level, a style of light, and a light map that is part of the general level light map. 2.4.1 Open Passage ways When a surface is just a passage way (like a hall, a door, or a hole in the floor) and need not be covered by a texture, it is just... ignored. There is nothing that describes it in the level structure. This is a contrast with DOOM, where that kind of passage had to be indicated by two sided lines. There is no 2 sided surface, unless you want to create a transparent wall (and even then, it would be made of two independant surfaces). 2.5 Texture definitions The texture definitions are not actual textures, but rather special references to the true textures. One or more texture definition can point to the same texture data, and it will look somewhat different each time. There is no equivalent of this intermediary texture definition in DOOM. Each texture definition contains: * the name of the actual texture (that could be animated) * two offsets in the texture's picture space * an indication of the scale of the texture * 3 flags that say if the texture must be flipped horizontally, vertically or if if horizontal and vertical must be exchanged. 2.6 Planes definitions The planes are used as split planes in the BSP tree nodes, and as reference plane in the Surfaces. They are the Quake equivalent of the DOOM Linedefs and Segments. The planes are defined by a normal vector and a distance. This normal verctor must be of norm 1. The plane equations are used for distance calculation and to determine if a given vertex (of a surface, or an entity) is on the front side or the back side of the plane. It is highly recommended that if a node and some set of surface use the same plane equation, they point to the same plane definition. 2.7 Vertex definitions The Vertex as the Quake equivalent of the DOOM vertex. the only difference is that they are in 3D, not in 2D. There can only be 12 vertex per face, and in fact, 16 vertex when taking into account the clipping of the face by the BSP planes. In fact, there are so many limitations related to this 16 number of vertexes that we can expect it's only temporary. 2.8 BSP tree Nodes definitions The nodes are the Quake equivalent of the DOOM nodes and also of the DOOM blockmaps. They are parts of a 3D BSP tree, not a 2D BSP tree like in DOOM. The nodes are used for level display, placements of entities and collision detections (and maybe even more). So there is no need for a blockmap in Quake. Technically, nodes are defined by: * A plane that split them in two * A bounding sphere (origin point and radius) * A front child node (or leaf) * A back child node (or leaf) The root node of the BSP tree is the first node in the list of nodes (in DOOM, it was the last node). The front child node (and all the nodes below it) is entirely contained in the half-space that is in front of the split plane. The back child node (and all the nodes below it) is entirely contained in the half-space that is in the back of the split plane. (The 'front' and 'back' of a split planes are defined by the plane equation giving a positive or negative result for any given vertex) If the split planes reference is -1, then in fact the node is a tree leaf, see the definition above. 2.9 Visibility list This tricky structure is the Quake equivalent of the REJECT map of DOOM. And yes, it will take ages to calculate (I hope not!). Unfortunately, it is much more important than the REJECT map, since it can be used to make the level rendering much faster. This is due to the fact that sectors are now the leaves of the BSP tree. The REJECT map in DOOM was only used to control the monster's behaviour. It could not be used for rendering, since it was sector based. So it can be expected that the REJECT special effects of DOOM (blind monsters and such) are something of the past... though in fact, screwing the visibility list is a very good way to obscure some areas of the levels. But I'm not sure Quake will be of much fun in blindfold mode. Basically, the Reject map is an array of bits, one array per tree leaf. The bit number n, if set to 1, tells that when laying in the tree leaf, one can see the leaf number n. When the player is in a leaf, the engine finds all the leaves that are visible from that leaf, and tag those leaves. Then it tags back all the nodes that are above the tagged leaves. That way, only the part of the BSP tree that is really visible will actually be tagged, and later displayed. 2.10 Lighting Quake apparently uses some static light model: there is no Gouraud or Phong shading calculated in real time. However, the constant light level of surfaces may possibly be updated in real time (as when you walk around with a torch, or open a window). Note that recent information released by id software indicate that the light mapping and shadowing in Quake would be done dynamically. The fact that everyone thinks it's damn impossible to make any dynamic shadowing on a 486 or pentium is only a minor concern. So chances are that the description below is outdated. I hope so at least! The way Quake makes it's surface lighting so realistic is a bit special. It works with each surfaces independently of others, and the lighting is calculated once for a set of similar surfaces, so it can't possibly be Gouraud or Phong. Yet, it might be much more realistic! The basic idea behind the Quake lighting is to take into account 3 things: * A constant light level * A special thing called type of lighting. * A light map, which is no more than a basic light level, for each texture pixel. Constant light level The lighting principle is that of so-called 'flat shading'. There is one such light level for each surface, and we can assume it depends on the orientation of the surface, and on the static light sources defined before the level is calculated. I suppose that a good Quake editor would let the user define some sources of lights (windows, torches, sky) and then do the lighting calculations once and for all, for all surfaces. Of course, this is fairly primitive (no way to move torches, to switch off lights) but then again the game engine could possibly update this static light in real time, under certain conditions. Type of lighting This strange attributes seems to translate internally into some kind of multiplicator for the light map below. Apparently, it only multiplies the light level, it doesn't affect the colors. I supppose it's here to give a bit more variability to light maps. Light Map The light map, basically, is a byte field, one byte per pixel of the texture. This byte give the light level of this pixel. This allows for some fairly realistic apparent surface irregularity. However, the light map is not defined for each pixels: it's only one light value every 16 pixels, and it is bilinearly interpolated in the intervals. Also, the light maps are shared between surfaces. Pixel Lighting Using the pixel's color index, and the light level calculated as: light(x,y) = lightmap(x,y) * lightstyle[style] + constant light This light level is used to select an internal color palette. Then using the texture's color index and an index in this palette, it's possible to find the actual lighted color. This mechanism is basically the same as in DOOM, except that there is 256 (?) color palettes, not 32. This mechanism takes into account both 8-bit or 16-bit color palettes, so Quake will look better on 16-bit per color display, but will still run on 8-bit per color display. Dynamic light mapping Franckly I have no idea how this could work. However, the static light mapping is already so calculation intensive that I wonder if, after all, a simplified dynamic light calculation wouldn't be as fast. Descent is supposed to do light calculation fer every vertex of the cubes, and then apply linear mapping between the vertex. A similar technique could be used in Quake, but it would probably involve much more vertex calculations. 2.11 Model format This is the format of the model, when stored in a single lump. DELETED BECAUSE OBSOLETE The format will probably be some ASCII. 2.12 The Quake 3d engine: rendering of levels (Thanx to Jens for some critical reflexions) I'm not going to explain in details how the Quake 3d engine works. It wouldn't be fair to id software, and anyway I still don't understand a lot of critical features. Also, if such an explanation was to be read by the conceptors of Quake, chances are that they would die laughting, and I don't want to take that risk. Let's say only that the Quake 3D engine looks like an ordinary texture-mapped polygon engine, where the polygon sorting is not done via classical backface elimination and distance sorting, but by using a BSP tree. Countrary to DOOM, there is no ray-casting, so some surfaces are sometime rendered, then later overwritten by closer surfaces. Hence the visibility list is critical for this engine, otherwise it might really crawl. The Quake engine bears definitely no relation to the Descent level display engine, though there might be some similarities with the engine that display the vessels of Descent. The Quake engine keeps a list of clip 3D planes that is used to avoid rendering too much of the non-visible surfaces. There is apparently no polygon-clipping in screen space. Probably the conceptors of Quake judged that the cost of 2D polygon clipping was too high, compared to the use of a simpler, though less efficient, painter's algorithm. Well, this description gives only the general features of the Quake engine, and actually don't make a lot of sense. Here are some temporary conclusions: * There is apparently NO limitation to the 3D engine of Quake. * This engine could be faster than the engine of Descent, and at least won't crawl on large rooms, like Descent does. * The shapes of the levels should be rather critical. Chances are that if the level parts are very far from convexity, then the engine might crawl. I hope not. This part will be updated later. --------------------------------------------------------------------------- 3. The 3D Alias Model Format Alias models are used for entities (players, objects, monsters). 3.1 Organisation of Alias Models An alias model is made of: * a skin (a flat picture) * a set of skin vertex (vertexes positionned on skin) * a set of triangles (the model layout) * one or more set of 3D vertexes (one set per animation frame). How doe it work? First imagine a wireframe model of the entity, made of triangles. This gives the general shape of the entity. For instance, imagine you have the general shape of a cow, made of triangles in 3D space. * the set of 3D vertex is the vertex that bound the triangles. * the triangles are defined as made of 3 particular vertex * there is no coding for line segments, planes or surfaces, all is implicitely defined by the triangles. Then, on each of those triangle, map one small triangular area of the skin of the model. For instance, imagine you have that flat carpet made of the skin of a cow. Cut a small triangulat piece and put it at the right place, on the 3D model. What you made is just a mapping between the list of 3D vertex and the list of vertex on the skin. It happens that in an alias model, the index of the skin vertex (in the list of skin vertexes) is the same as the index of the 3D vertex (in the list of 3D vertex, for a given frame). That's all Quake needs to display your model, with texture mapping. 3.2 Animating alias models The animation is not done by changing the skin picture, countrary to sprites. Rather, the animation consists in providing one set of vertex positions for each frame of animation. That means that the animation is still based on frames, like in DOOM. It is not based on compulation derived from a physical model of the entity. So the frames of animations had better be calculated carefully, or they will look unrealistic. Since skin vertex positions are not changed, and the skin texture is not modified, and the triangles remain the same, it also means that the entity can move but it can't change colors, or get some blood stains... unless some of the triangles are pushed in front of others, during the animation. 3.3 Rendering of alias models The rendering of entities is a bit mroe complicated than the ordinary back-face elimination and triangle sorting that is common in games like X-Wings, Terminal Velocity or the like. It doesn't use a BSP tree like (so they say) in Descent, but it takes into account the BSP tree structure of the Quake levels. I'm not sure the description below will make a lot of sense to you, but it will be enough to get a general idea: It's basically a combination of BSP tree rendering, painter algorithm and 3D clipping. When Quake needs to display an entity, it first determines the hightest node in the tree that splits this entity. Then starting from this node, it decomposes the entity in non-overlapping parts, using the split planes of the BSP tree nodes. That way, one entity part ends up in each tree leaf. Then, when the whole level if being displayed, each leaf will be painted first, then the entities parts in this leaf will be displayed, after being sorted according to distance. When displaying an entity, Quake first elimitates the back faces, then clip this entity taking into account the nodes split planes, and the view clip planes. That leaves a set of triangle, that are sorted (using a very trivial method) and displayed using the painter's algorithm, and of course texture mapping of the entity skin. Yes, I know. It's more than confusing, and probably sub-optimal, so don't trust this description too much. The important point is the conclusion: * Do not map many triangle to the same 3D area, that will slow down the rendering. * The more convex your entity, the faster it will be. * The triangles will be sorted according to distance of the closest vertex, so if your entity is very complex, with partly overlapping triangles, chances are that some triangle will be sorted the wrong way. General conclusion: the simpler the better. Hardly a surprise. 3.4 Alias Model format DELETED BECAUSE OBSOLETE The format will probably be some ASCII. All you need to know is that there is only one picture, and that frames are done with vertex, rather than with changes in the picture. --------------------------------------------------------------------------- 4. Sound capabilities This area is being investigated. I'm not a sound expert. The Sound is definitely stereo, and definitely takes into account the source position (in 3D) toward the player. The sound can use the Sound Blaster (damn! what a surprise!), and I'm totally incompetent to say if it can run on the GUS. There is no music whatsoever. Fetch some NiN CDs, and that will do the trick. This part will be updated later. --------------------------------------------------------------------------- 5. The network capabilities This area is being investigated. However, no result will be published here: the network capabilities of Qu*ke are presumed to be a trade secret of id software, and revealing any technical details about it may hurt id. Let's just say that Quake maintains a representation of the world were entities can be added an removed dynamicaly, and players can log in at any moment. Not really surprising... It is not known if the player's characters are preserved, like in MUDs. It is not known if the 3D models can be sent by the server to the clients, so maybe you won't be able to run around in Quake disguised as Blackadder, unless everyone uploads your great graphics beforehand. This part will be updated later. --------------------------------------------------------------------------- 6. Miscellaneous Info Here you will find some obsolete descrition of various stuff that don't make a lot of sense yet. 6.1 The Quake Programming Language This language is very similar to C. It is loaded dynamically by the server, read, and most probably transformed in an internal representation. The names of variables in the code are reminiscent of MUDs code, and there is all reason to beleive Qu*ke will be MUD-like. Of course, there isn't much code compared to even the simplest MUDs. There is code that describe how the Qu*ke server should handle the clients, as they join an existing world. BTW, they can join dynamically, like in DESCENT. And they can join the level they wish. The Things are all represented by C-like objects, with a set of attributes whose name are fairly intuitive (frags, velocity, health...) and the language provides a set of functions of the basic stuff. Vectors values are represented as character strings like "1 2 3", and can be added, scaled and multiplicated. The attribute think is used to tell or what code function the object shall apply. The attribute nextthink is used to tell when the next call to the object's code shall happen. Like in DOOM, the Object/monsters will be implemented as finite state automats, based on frames. But you won't need DeHacked to read them. The Objects frame tables are provided in the code (with a special macro structure, that expands trivialy into code) Programmer's Corner The language seems syntacticaly clean, but there seem to be no strict type checking anywhere, so odds are that any complex code module will be real difficult to debug. Not to mention the 'goto' lying around. I wonder what happen when one mixup frames from different monsters... Apparently the language is entirely event driven (not a surprise) and timers can be set for certain events. Mind the event loops! No details will be given on the actual code: the parser and probably the language were rewritten by id, for more efficiency. It is not known if some fair level of AI can be implemented using this language. I seriously doubt it is possible to manipulate some accurate representation of the world. Quake isn't really a wargame, is it? ;-) 6.2 List of Entities the *.key file contains object class definition, with default parameters. These classes are written as a list, in some LISP-like language, except that the ( ) are { }. Attribute include the class name, the color, the 3D model, the size of the object (a scaled cube, not a sphere), the light, the style, the actions (use, touch, think) the movement mode, the sensitivity to gravitation... That's what it looks like, somehow: { {classname "bestiole"} {color "1.0 0.9 0.4"} {orgofs "64 64 80"} {size "32 32 70"} {model "s_bestiole"} } 6.3 Light maps This information is probably totally outdated. The light maps were a trick used in early versions of the Quake engine. It was a way to implement some cool shadows without too many calculations involved. Countrary to what was supposed initially, it bears no relation to dynamic changes in the light level. Example: ccmdefabcdefgmmmmaahijlkmmaamm 9 BOUGIE (third variety) See the level description to know how these light maps are used in levels. They don't seem to be used with entities. 6.4 Player Movements There are some reasons to believe that there is no restriction in 3D movements Quake. 6-axis movement seems technically possible, and at least the movement internal structure allows all combinations, and the graphic engine is not restricted to any rotation. Here are the known movements: turn left/right, up/down, move front/back strafe left/right, up/down no key is defined for roll turn, jump, climb, fly. This may/should change. 6.5 The Language of the Gods The language of the Gods, countrary to common Tleilaxu beliefs, is C. It was C in DOOM, it is C in Quake. Let's just say that the code if id is characterised by... the absence of almost all security tests. That means that if the data structures are not 100% perfect, the code will bug or crash without warning. This is especially true when you deal with indexes. Don't even make a mistake on an index, in a file. It can be noted that the code was not optimised at all and used floating numbers (and thus, used the floating point unit). This makes it especially unsuitable for 386 (no surprise) and in fact unsuitable for anything below an helium-cooled 300 Mhz 686, with 500k of primary cache and 20 meg of s econdary cache. However the code was certainly completely rewritten and optimised since these first experiments, and it will run at decent speed even on a DX2/66 (Or, shall I say, DESCENT's speed. At least.) --------------------------------------------------------------------------- 7. Final Word This material is provided to you as general information. You are in no way obliged to believe anything of the above. * This specification contains all the information that I estimate I can make public without bringing any trouble to id software. Don't ask for more. * If you want trustable information, you'd better wait for the official specifications from id software. Chances are that they won't have reliable description themselves, until Quake is nearly finished. * If you intend to write a game as cool as Quake and think that it would be very clever to get some technical information from me, then you are taking some serious risks. I'm not supposed to keep your name secret. Last remark: this document was written quickly, and I'm not that proficient in English. So it's full of mistakes. Nezu the Unworthy --------------------------------------------------------------------------- Come visit my Home Page for the last updates to this specification. --------------------------------------------------------------------------- List of cool Quake Related pages: * Jen's Quake page. * Colin's Quake page. * Jos's Quake page on the Doom Gate. * Hank's Quake Rumor Mill.