a) I'm pretty sure you mean http://www.doom3world.org above? That's certainly the largest D3 community editing forum on the planet.

b) Official id Software SDK and support at http://www.iddevnet.com

c) "Real-time" editing is absolutely amazing. Especially for tweaking lighting. You can move a light a single grid unit across and you'll be able to see the result. Other engines, you have to compile, wait, wait, wait, run the game, realize that you have to tweak it again and start the process all over again. D3R also has one of the shortest learning curves compared with other editors (just like GTKradiant), it's something where new users can easily learn the basics of how to create a simple room. With the complexity of the D3-engine, learning how to create a complete map for D3 is another story though.

As well, D3R also has a parallel branch under production. GTKradiant 1.5.0 has D3 support and as you know, the GtkR team has been excellent at implementing new features and bug fixes to GTKradiant. I'm not sure if other editors have this kind of semi-official open source editor development projects. I doubt it.

d) Not sure how Sandbox works, but I can't imagine creating a map not from a per polygon basis. How do you create your levels then? Does everything need to be imported as models or something? If that's the case then definitely it's easier being able to change geometry from within the map. Especially when creating a layout of a map, you can rough something out and very quickly change it as needed.

What kind of "materials" are you referring to? The term "material" for D3 refers to the new kind of "shader" files. "Shaders" now refer to pixel/vertex shaders which are kind of like small OpenGL scripts that creates those cool glass
distortion and heat wave effects.

D3 models are still very similar to Q3 models. You assign the name of the D3 "material" (similar to a Q3 shader file) to the model surface. The material file then takes care of all the different stages: diffuse, normal, specular, height, other special effect stages, and links to pixel/vertex shaders.

Overall, this makes setting up the surface of a model very easy since you just set the name of the material in the modeling program and then export. Any changes to the material will get attributed to all models (or brush geometry) using the material. And of course, material files are still just simple text files that are easy to edit. Calling vertex and fragment programs could not be easier. You just specify the .vfp file and away you go.

e) In terms of missing features, nothing really. Anything currently not built in as a feature can be added as a mod. Even lightmaps are possible for the D3 engine, you just need to create a mod. Tr3B just created a deluxel (new, more advanced form of lightmaps) mod for D3. See here:
http://www.splashdamage.com/index.php?n ... ic&t=11634

There are a lot of misconceptions with the D3 engine that people have in terms of it's limitations. It's been posted everywhere that the D3 engine is limited in doing outdoor maps due to the unified per-pixel lighting system. Not true as shown by the Doom3CanDoItToo project. See here:
http://www.doom3world.org/phpbb2/viewforum.php?f=57

One thing that the D3 game code has that other games don't is the amazing console scripting features used to create all those cool interactive computers. The D3CDIT project has an interactive "Asteroids" arcade game programmed into the map - a game within a game! With the extent of the SDK and the "open" nature of the engine, there really isn't a whole lot that people can't do so long as they aren't limited by hardware. I suppose that is the greatest merit of the D3 engine.

f) Be careful when comparing game engines with respect to your list of features. Some of that is considered engine code, others are game code and the rest is game assets. Lighting and shadows are considered engine features. Terrain, model LOD, cutscenes, collision detection, event handling are considered game code. Other stuff like sounds, bumpmapping and facial animations are considered as game assets. Terms like multiplayer and single-player is pretty broad, they are the experience of the player when taking all the above features collectively. Stuff like network/internet play is a bit limited with the D3 game since they chose to take all sorts of stuff like per-poly hit detection and physics into consideration, so there is a huge bandwidth issue (which is why the game is limited to 4 players - think the expansion supports up to 8). Quake 4 based on the D3-engine will likely do some pretty big changes for online play.

The game engine is something that can't be modded (because no commercial game engine software developer will be releasing the source code anytime soon - they want to make money on licensing deals). It's the foundation technology that determines how vertexes/polygons are drawn and optimized, how texel and pixel information is processed, light drawing implementation and optimization, and other display effects. It's the basic core that powers how information is sent from the game to the video card for processing.

Game code is stuff that is programmed for the gaming experience of that particular title. This stuff is easily mod-able with the D3 engine since the source code is released with the SDK. For developers, this is a launchpad from which they can modify for their own titles, but there is no real limitation in terms of how far they want to take this. Almost everything that people might consider as part of the engine is really just game code. You can totally replace stuff like the physics engine with your own physics code if need be.

Game assets are stuff like models, animation, textures, materials, etc. IMO, you really don't want to add this stuff into your article since it has nothing to do with the topic at hand.

Basically, be very careful in differentiating between engine code, game code and game assets. Mixing the 3 will make your article a garbled mess as you are trying to compare apples to oranges. It just doesn't work. I've already read a bunch of "detailed engine comparison" articles that are totally flawed because of this mistake. D3 does have the most advanced game engine on the market... hands down, simply because the technology that they are using is revolutionary. Game code is a toss-in-the-air between the major competitors of D3, FarCry, HL2 and Unreal. They all have their advantages/disadvantages.

g) Again, if you're really up to it, you can make the D3 engine anything you want. A racing game, flight simulator, you can probably even do a strategy type game. After all, look at the Quake3 engine. We have Q3rally as a racing game. If you've played Medal of Honor: Pacific Assault (heavily modified Q3-engine if you'll believe it), one of the episodes involves flying a fighter against a bunch of Japanese fighters in dog fights and assaulting an aircraft carrier and destroyer. The platformer mod is kind of a fixed-camera view mod, so I'm pretty sure even a strategy game can be made like Warcraft III. It'll be a lot more work since the game code is essentially targeted towards FPS games, but if you're really up to it, a total game code conversion can do pretty much anything.

h) It's still very similar to Q3. It's a derivative of BSPs but more advanced and much better optimized. As I understand it, portals are created in a different way than Q3 hints. Can't give you more details than that ATM, since I have limited experience with D3 portals.

i) Where did you hear that? D3R has a built in script editor. The D3 scripting language is designed to "feel" like C++ but is definitely easier to learn and if you already know C++ as most programmers do, it really shortens the learning curve. It's a very powerful scripting language that gives a lot of control to the developers. See the iddevnet link below:
http://www.iddevnet.com/doom3/script.php

j) Most models are just normal ASE's (3dsMAX ascii format) or LWO's (Lightwave Objects). So pretty much any modeling program can be used as long as you can export to different formats (most modeling programs can - or easily do so with a plugin). D3 also has MD5 objects (I think for player and weapon models?). Conversion is similar to the Q3 process of taking the model and feeding it though BSPC except I believe that it gets fed through the main Doom3.exe

Overall, don't make the same mistake that those "other" article authors made in comparing unrelated things (section "f") and you'll do fine. Compare the raw engine by themselves - technology and optimization. Then compare the game code and features that 3rd party game developers can use as a basis for modification. Then compare the editing tools available.

Hope that helps.

What obsidian said

The D3 engine is pretty bare-bones, consisting of the renderer, sound and net code and not much more. You can build about anything on it: per pixel lighted Civilization IV? Check. D3Rally? Check. Mortal Doombat 3? Check. You get my point.

From this aspect, D3 and FarCry are completely different in that the game code was designed for different purposes, so they don't quite compare... again, it's kind of like apples and oranges. You can't really say that the FarCry engine is better for LoD terrain nor can you say that Doom3 engine is better for indoor environments. You can say that the FarCry game is better for LoD terrain and the Doom3 game is better for indoor environments because they were programmed for two different experiences.

The Doom3 game didn't need to do phenomenolly well in outdoor environments nor FarCry need to do detailed interiors - simply because it wouldn't affect gameplay for those respective titles. I'm sure that you could mod both games to do equally well for both indoor and outdoor environments. So if you're writing about the 2 engines strictly as they are out of the box, I'm not sure how well that will reflect for developers comparing the 2 engines. So you can see that this is the problem of differentiating game code with engine code again.

A terrain mesh is just a bunch of triangles stuck together to look like a hill or riverbed, whatever... just like how a wall is just a bunch of triangles stuck together to look like a wall. If you wanted to, you could create a terrain mesh in D3 using brushes or patchmeshes or import a model just like how we do them in Q3, creation method doesn't matter since the game engine just interprets all that as a bunch of vertexes, edges and triangles... just seems as if using a modeling program is easier than the old fashioned triangle soup method. I assume that FarCry has some sort of terrain mesh editing tools in the editor to specifically modify the height and terrain blending of terrain. Doom3Radiant doesn't have that built in (but mod-able).

Interesting bit about LoD in D3... like I said in my previous post, D3 doesn't have any LoD since they found that it looked kind of odd as the shadow volumes that were projected would change as the LoD increased or decreased. Shadows after all shouldn't change shape. Unlike Q3, patchmeshes in D3 don't have LoD - it was disabled for the reason above. If necessary, third parties are welcome to add LoD for patches, models or terrain.

The D3CDIT project was created to dispell some of the myths going about the so-called limitations of the D3 engine. One of which was D3's ability to create large outdoor areas. The D3CDIT map creates a city square, featuring a few city blocks of buildings and other things that you would expect to find inside a small European city. To the largest extent, they are working with stuff precoded into the game code and they haven't done much as yet with modification programming. But the general concensus to most of the, "can D3 do this" questions is, "yes, with some modifications to the game code, why not?".

Bumpmapping - well when you listed this, I thought you meant the actual normal/heightmap art files. Per-pixel lighting with bumpmapping is indeed part of the engine.

How I would go about this:
I suppose for any engine or game code comparison, it would be extremely difficult since there is no level playing field to compare them. The two games are designed for different purposes and so some features are omitted since they weren't necessary for the particular game title. This means that it's very difficult to compare them to each other since there's very little in common to actually compare with.

Then you need to compare the built in game code features, though you will have to note that developers should be able to implement a lot of features that are not built in using some modification programming. Then compare the features of the editing tools, SDK's and other developer resources.

Overall, taking everything into consideration... it really depends on what kind of game you want to make. The SDK and everything gives the developer something to base their own code off of when creating a total conversion project.

This thread contains the longest posts I've seen in this forum.

Does this have anything to do with Architecture Mag?

Hrm... 5:17AM GMT... If you're posting this now in your time zone, it either means that you're an earlybird... or you were burning the midnight oil trying to finish the article.

Hope it's going well. I have a tendancy to get writer's block whenever I have an urgent deadline.