QuakeEd

🇮🇪

QuakeEd is the level editor designed by John Romero and John Carmack to create the levels in Quake. Having its source code, in version 2.0, released on May 18, 1996 by John Carmack, this was the official editor used for the vanilla game as well as the first Quake editor to be released in some form to the public; the QuakeED's source code was available about a month before the first shareware release of the game. Carmack did not include all the resources needed to build maps such as the textures and models, instead stating that he would wait until the game shipped to release a set of development tools for the general public. Carmack planned to write a new editor with Windows NT and OpenGL after Quake shipped. Carmack also suggested possibly porting QuakeEd as a separate shareware product for Windows if he could get a reasonable royalty rate from NeXT.

Due to the above, QuakeEd was simply released as source code that could be read and be used as a guide by fans that wished to create their own editors. However, Carmack considered the knowledge to be gained from this to be limited, due to the entire program being written in objective-c, which is of little use to most people. Regardless, some of the technical stuff, especially in regards to 3d models, he figured was important enough to release to the community.

At the time of Quake's release, NeXTSTEP workstations were considered considerably more powerful than the general user machine and was what id Software used to design the game. Essentially, this meant that most users could not run QuakeEd even if they desired to due to the differences between consumer operating systems and NeXTSTEP. Windows NT or GNU/Linux, according to Carmack, would make for difficult ports. Even on NeXTSTEP, Carmack states that he never had the time to optimize QuakeEd as well as he wished, choosing 8-bit mode causes the texture view to lag significantly as it is dithering from 24-bit textures. On the other hand, choosing 24-bit mode results in a lot less screen real-estate and extremely slow line drawing due to the limitations of XY view. QuakeEd required 32 MB of RAM, more than double the amount needed for Quake, and required a 1024x768 display at the minimum.

As OpenGL and Direct3D were not heavily popular prior to Quake's release, Carmack released his own libraries for texture loading. Even Carmack admitted that this code wasn't good and that future editors should just use one of the already available library packs.

The editor outputs a .MAP file, a file type that was relatively compatible with any file created during the length of Quake's development. According to Carmack, the .BSP format changed more than a dozen times. Carmack expressed that he wished for future designers to simply use the formats created here to allow for better compatibility. To process the file into a .BSP level, the user needed to compile the editor using three tools, all of which were released to the public to create their own levels. Compiling was a relatively demanding task for computers of the time however and could take over ten minutes, especially those using the "vis" program. According to Carmack, id Software was using quad-core CPU systems with 128 MB RAM, a ridiculously powerful system in 1996. Dual-core systems were not commercially available until 2001 and quad-core systems only began appearing a decade after Quake's release. The other programs "qbsp" and "light", were less intensive but still could take a bit of time to compile if the level was large enough. Carmack joked that university computers would be under heavy load, since they were some of the only computers of the time that could benefit from "vis" and "light" being multi-threaded.

The main program, "qbsp", takes a solid geometry description .MAP file and converts it to a more optimized file that Clips what the player does not need to see at any given time, thus improving frame rate times tremendously. This program was single-threaded and was extremely RAM intensive, but generally would only take a minute to complete. The next program, "light", would add light-maps (determining the level of brightness of various areas) to the world, which would generally take a few minutes to run. The final program, "vis", is essentially a more complicated form of clipping take creates a Potentially visible set from a lengthy series of calculations. A full "vis" was extremely CPU intensive, but depends entirely on the complexity of a level, meaning an extremely simple level may only take a minute. However, there was one unspecified level made by id Software that took over an hour to "vis" on their 128 MB RAM quad-core CPU system. Needless to say, "vis" is generally only intended to be run on the final creation of a level.

According to Carmack, there was no limitations whatsoever on the geometry even though Quake mostly consists of simple axial blocks. Brushes could carve away from the subtractive world and "qbsp" would chop up the level information as needed when translating the file into a level.

QuakeEd always specifies the world as Entity 0, meaning that there is always at least one entity in the world, and defines entities as either a collection of brushes or a non-modifiable object such as a Monster. These entities could be given information using a key/value pair. specifying such information as the classname of an entity or the brightness of a light. Unlike later editors, QuakeEd only has an orthographic view from the top (XY) and a 3d view. To place items vertically, in the Z axis, the brush or entity would be moved up or down on a Z-axis slider.

A selected brush is drawn with a red outline. This selection is not cleared when a new map is loaded, meaning selections can easily be ported from level to level. Simply clicking on a brush in camera view would result in whatever texture being selected being added to the face of whatever was being clicked on. Every brush loaded into the map would always be given a default texture, it was impossible to create invalid data like the infamous HOM effect in Doom. Textures naturally align themselves, meaning regardless of angle or the relative scale of the textures there will appear to be no seams on the textures. The user could offset the textures by 16 pixels at a time on any on the three planes.

The level files themselves hold the textures. Though this carries the negative side-effect of making the level files much bigger than they would otherwise be, it also makes it extremely easy to import new graphics. The palette of Quake is drawn from a .WAD file, which can be specified by a "wad" key to point to the particular palette wished to be used in the level. The "qbsp" program takes all textures in the level and converts them using the palette in question, which is thrown along with the original map file in the end .BSP file. This means that the .WAD files included with Quake are never referenced by the game.

There was also an input field that allowed for more obscure textual commands to be used, most notably "texname", a command that would list the names of the textures on a selected brush. Essentially, this was used to track problems in the event that a texture got taken outside of a WAD file.

Levels
See Category:QuakeEd levels

Unofficial Port
Utilizing the source code, Tomas Talius quickly ported the editor to Windows NT (which means the editor ironically works better in modern Windows operating systems than what was common in 1996) to utilize OpenGL functionality. With the quick rising popularity of other editors such as WorldCraft or Quest, however, QuakeEd mostly became a novelty as opposed to an editor used to design custom levels.

1.2

 * Added menu item under the Camera to center the view.
 * Can also center the Z-Checker, which determines what intersects with the Z-plane.
 * Given a proper program icon instead of the default compiled one.
 * Can change render style from accurate to fast.
 * Added world light levels for X,Y,Z planes.
 * Rewrote most of the documentation.

1.0

 * Ported to Windows from 2.0 code by Tomas Talius.