Slashdot Mirror

The part that is not generally available are the maps from the game itself. The engine is available, but you have to download and put together your own information. With the proliferation of doom and quake sites this is not a problem.

John's original intent was to release the source code for each game engine a year after the game was released or when the next game engine was released. Doom and DoomII use the same engine, more or less and when quake was released John released the Doom code, actually a bit later since they had to have someone go in and clean out the third party software and clean up part of the code.

And now for some URL's

PlanetQuake probably the formost user site online for quake and doom related material. Any player of these games should not miss this site.

Quake 2 coding list.

id Softare id software's main website

id's source code archive

planetquake's finger information Latest .plan files from the gaming industries top game designers.

Where to find the Doom source

Cdrom and more files, look for various id titles

Lando

The part that is not generally available are the maps from the game itself. The engine is available, but you have to download and put together your own information. With the proliferation of doom and quake sites this is not a problem.

John's original intent was to release the source code for each game engine a year after the game was released or when the next game engine was released. Doom and DoomII use the same engine, more or less and when quake was released John released the Doom code, actually a bit later since they had to have someone go in and clean out the third party software and clean up part of the code.

And now for some URL's

PlanetQuake probably the formost user site online for quake and doom related material. Any player of these games should not miss this site.

Quake 2 coding list.

id Softare id software's main website

id's source code archive

planetquake's finger information Latest .plan files from the gaming industries top game designers.

Where to find the Doom source

Cdrom and more files, look for various id titles

Lando

There are at least two things that you can do when attempting to reverse engineer a piece of software. The first one (not legal in several countries) is to decompile the code: take a debugger or decompiler and check what instructions are executed. The second one (legal in most countries) is the "blackbox" approach: consider the software as something that produces some output(s) depending on its input(s), and try to guess what is inside.

This second approach is the "real" reverse engineering. By carefully crafting some inputs and observing the outputs, you can often draw some conclusions about how the software behaves. With some patience and a lot of trial and error on simple inputs, you can find some patterns in the software: stuff that does not change, stuff that changes depending only on one of the inputs, and so on.

In the good old days (well, five years ago), I was the author of DEU (Doom Editing Utilties), the first program that was able to create new levels for Doom. I also contributed to Matt Fell's Unofficial Doom Specs and Olivier Montannuy's Unofficial Quake Specs, the documents that describe the WAD and PAK file formats and other internal details about Doom and Quake. Almost everything in the Unofficial Doom Specs was gathered by reverse-engineering. It was only later (with the release of Doom II) that id Software released some information to the community, presumably after they saw that editing Doom levels was a very popular activity. I am grateful for id Software's support of the editing community in their later games, but the first informations about Doom had to be found the hard way.

Most of my efforts in decoding Doom's WAD file format (and later Quake's PAK file format) involved an hex editor for viewing and editing the raw files, and custom tools that I built along the way for making editing easier (or tools that I received from other people, like DEU 3.0 from Brendon Wyber). A key thing is also to share as much information as possible with other people who are progressing on the same front because you often get more in return than what you found by yourself. For WAD files, it was easy to find that the file was organized a bit like a tar archive: a header, a directory containing names of objects and offsets within the file, and the data for the objects. Then the trial and error starts: try to guess what an object might be, modify a few bytes, run the game and see what happens. If your changes produced something useful, write it down and share the info with others. If the game crashed, try again. Repeat until you have understood everything.

Sometimes, you will find data structures that you do not understand. That was the case for Doom's NODES, SEGS and SSECTORS data. If you share enough information with others, maybe someone will have an idea and find that the data structures are related to something that they know. This is exactly what happened for Doom: Alistair Brown and a group of students from Bradford suggested that the unknown data might be a BSP tree. After reading some papers on that topic (I didn't know anything about BSP trees), I was able to implement a first BSP builder in DEU. And then it became possible to create brand new levels for Doom, instead of only changing the textures and location of the monsters as we did in the first few months. Releasing the source code for the tools has probably helped a lot. Other people were able to create their own tools based on that, and then the next reverse-engineering steps became much easier when the other games based on the same engine were released (Doom II, Heretic, Hexen, Strife,...)

Ah well... The good old times... Sigh!

There are at least two things that you can do when attempting to reverse engineer a piece of software. The first one (not legal in several countries) is to decompile the code: take a debugger or decompiler and check what instructions are executed. The second one (legal in most countries) is the "blackbox" approach: consider the software as something that produces some output(s) depending on its input(s), and try to guess what is inside.

This second approach is the "real" reverse engineering. By carefully crafting some inputs and observing the outputs, you can often draw some conclusions about how the software behaves. With some patience and a lot of trial and error on simple inputs, you can find some patterns in the software: stuff that does not change, stuff that changes depending only on one of the inputs, and so on.

In the good old days (well, five years ago), I was the author of DEU (Doom Editing Utilties), the first program that was able to create new levels for Doom. I also contributed to Matt Fell's Unofficial Doom Specs and Olivier Montannuy's Unofficial Quake Specs, the documents that describe the WAD and PAK file formats and other internal details about Doom and Quake. Almost everything in the Unofficial Doom Specs was gathered by reverse-engineering. It was only later (with the release of Doom II) that id Software released some information to the community, presumably after they saw that editing Doom levels was a very popular activity. I am grateful for id Software's support of the editing community in their later games, but the first informations about Doom had to be found the hard way.

Most of my efforts in decoding Doom's WAD file format (and later Quake's PAK file format) involved an hex editor for viewing and editing the raw files, and custom tools that I built along the way for making editing easier (or tools that I received from other people, like DEU 3.0 from Brendon Wyber). A key thing is also to share as much information as possible with other people who are progressing on the same front because you often get more in return than what you found by yourself. For WAD files, it was easy to find that the file was organized a bit like a tar archive: a header, a directory containing names of objects and offsets within the file, and the data for the objects. Then the trial and error starts: try to guess what an object might be, modify a few bytes, run the game and see what happens. If your changes produced something useful, write it down and share the info with others. If the game crashed, try again. Repeat until you have understood everything.

Sometimes, you will find data structures that you do not understand. That was the case for Doom's NODES, SEGS and SSECTORS data. If you share enough information with others, maybe someone will have an idea and find that the data structures are related to something that they know. This is exactly what happened for Doom: Alistair Brown and a group of students from Bradford suggested that the unknown data might be a BSP tree. After reading some papers on that topic (I didn't know anything about BSP trees), I was able to implement a first BSP builder in DEU. And then it became possible to create brand new levels for Doom, instead of only changing the textures and location of the monsters as we did in the first few months. Releasing the source code for the tools has probably helped a lot. Other people were able to create their own tools based on that, and then the next reverse-engineering steps became much easier when the other games based on the same engine were released (Doom II, Heretic, Hexen, Strife,...)

Ah well... The good old times... Sigh!

Most of the sound effects you hear in video games come from commercial sound effect collections that one can buy (come on CD, usually).

You didn't really think that people played around with sound generators and such at every game development house, did you?

Good grief, that'd be a tremendous waste of time and effort.

So, no Ambrosia (probably) doesn't own the sound effects in most of its games, id doesn't own the shotgun/door/whatever sounds in Doom or Quake, Bungie doesn't own any (to the best of my knowledge) sounds in the Marathon series, etcetera.

Since Ambrosia folks seem to be watching this thread, you guys want to clear this up further?

Idsoftware has all there games onfile here

did you know there was a QNX port of doom? I didn't...
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"

Yes, the G400 is quite a bit faster than TNT2 or Voodoo3, at 32b color depth and high resolutions. At lower resolutions, it doesn't do as well as those cards.

But if you can play Q3 smoothly at 1280x1024, why go back to 800x600? :)

My reference is the recent Q3T benchmarks of various video cards by Id. The original data can be found at Id, and here's some analysis done at Shugashack. (I don't completely agree with their analysis, but I might be confused about an issue or two. Like all analysis on the web, use it as background, but make up your own mind when you have the data. The G400 is definately damn fast on high res, high quality settings, though.)

John

Who would use Kaffe when they could get the real mccoy from Sun for free

Id software for one (well almost). While they where evaluating using java for QII (long time ago now) JC was talking to transvirtual about using Kaffe...but it never happened, for technical (coding in java at that time) reasons.

Trying to make any correlation ("psycho killers are attracted to this stuff") frankly offends me. While I was in high-school playing (violent) video games, the children who later became violent criminals had no interest in them. They were more happily occupied torturing insects, small animals and other children, shoplifting and committing random acts of vandalism.

In fact, if you look at murders nationally, the majority falls outside of the Doom/Quake playing populace. You're more likely to find that where:

G is the # of people who play Doom/Quake.

Gm is the # of murders these gamers commit.

N is the # of people who don't play.

Nm is the # of murders committed by them.
That (Gm/G) is far lower than (Nm/N). One might even suggest from this that Id Software promotes mental health. After all, if you don't like Doom, something must be wrong with you...

Go here to find quake3 servers for all your gaming needs.

And no, my suggestion isn't mirror it immediately - I hope you will have already done that.

What I'm going to suggest is that if you want to test the game, try a server other than id's. The night that the Mac version of Q3Test came out, the test servers (which Tim Willits said were on the same machine as the FTP server, for some stupid reason) were severely lagged. I don't think anyone other than the id employees had under a 500 ping.

There's a good server list on the id page at:
http://underworld.idsoftwa re.com/cgi-win/q3aservers.exe/

Quake has had a long-standing problem with kernels around 2.1.115 or so and later. Probably the best solution (seeing how everything else works okay) would be to get the latest driver from Id Software. Quake 2 is currently at rev 2.30.

--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)