Quake3World

Hi everyone,

as a favor, I am presently helping out a friend, with an article on modern game engines (SDKs), specifically for Far Cry (Sandbox, CryEngine), Doom 3 (D3Radiant, Doom3 Engine), and Half-Life 2 (Hammer, Source). I have the part of writing about the D3 and HL2 engines.

Audience: Novices interested in 3D engines (potential mappers), Mappers looking for the next engine "challenge", and to some degree Modders, looking for the engine most suitable for their needs.

Goal: It is my goal to provide a quick introduction to the D3 and HL2 engines, describe the SDKs, touch on the main features of the Editors (compare Interface/Features), e.g. what is the design philosophy (i.e. additive/subtractive geometry?, explained in a easy to understand way), lighting/shadows models, sound, AI, etc. Hopefully this will help motivate folks to start e.g. mapping.

I have only started to read up on all the below, so I am nowhere nearly an expert on the engine related topics. It would greatly help me improve my article to get feedback on the many larger/smaller issues/advantages that *real world* experience has taught you.

Please note: I am *not* trying to start an engine war. I am trying to collect information to paint an objective as possible picture of the present status of modern engines.


To start off, it would greatly help me to be made aware of reading material I should look into, to get an overview of the SDKs and engines. The below is mainly for Doom 3 mapping (but I am also looking for the appropriate info for Half-Life 2/Source):


General

a) What Doom 3 community forums can be recommended (e.g doom3.org)?

b) What documentation is there on the Doom3 SDK?


Editor

c) What features of D3radiant (as a "modern" editor) stand out compared to older editors (GTKradiant), but more importantly compared to Sandbox and/or Hammer in your opinion? (I am trying to nail down the new "real time" editing features, and how practical / timesaving these actually are)?

d) D3radiant lets you manipulate geometry on a per polygon basis (nothing new, Q3radiant heavily relies on this), but some editors like Far Cry's Sandbox do *not* let you do this. How important is per polygon manipulation still for D3engine editing? Does the import of "material" created with external Modelers, take up a larger part in the Mapping process now?


Engine

e) What is possible with the Doom 3 engine, that merits mentioning? (Since this is a Q3A forum, anything not possible with Q3A would be a good starting point). Missing features also merit mention IMO, e.g. I really miss shader lighting.

f) What are the strengths of the D3 engine compared to CryEngine/Source? What are the disadvantages/limits? Please use examples to undermine your thoughts. Some topics of interest in this compare: Terrain, Indoor Areas, Large Outdoor Areas, "Model" LOD, AI, "CutScenes", Facial Animation, Sound, Multiplayer, Single-Player, Collision Detection, Lighting, Shadows, Bumpmapping, Event Handling...

g) What kind of new mods are there that are not strictly a Shooter variation? E.g. can the engine be turned into a totally different gametype (non-Shooter)? Is the latter being done? What gametypes are the a inherent strength of the D3 engine?

h) What is the basic concept behind the D3 engine (mapping, optimization)? (IIRC Q3A was BSP driven, in part with geometry LOD, maps need to be leak free). D3 is a dynamic lighting centered engine, without LOD, using low poly geometry with bumpmapping to "simulate" detail? E.g. is it still BSP driven the way Q3A is, or is the engine going some middle path (using other optimizations)? Please correct my possibly wrong simplifications.

i) Far Cry provides a scripting languages (LUA) that helps Modders make quick changes to many features of the game. Unreal engines have UnrealScript, even Quake IIRC used to have a scripting language. AFAICT Doom 3 "simply" lets you program in C++ and does not come with a more "high level" scripting language (please correct me if I am wrong). Is this a disadvantage for Modders? Is the presence of a scripting language actually relevant for Modders? E.g. how difficult is it to add new content to the D3engine, pointers: Change HUD, Change the User Interface, add new (animated) weapons, etc. Does Source/CryEngine make things easier?


Workpaths

j) What import/export modules does the D3 SDK support? For what Model editors (are other external tools supported)? Is it possible e.g. to use "free stripped down versions" of commercial Modelers (e.g. like gmax, Maya Personal Learning Edition, ...) with D3. How "easy"/well does this import/export workpath work? Is it buggy/complicated?



Should some kind soul be in the know on Half-Life 2 specific information please post it here (e.g. links to documentation). I am also looking for "the" HL2 forum? As mentioned the above is mainly related to the D3engine, but I have equivalent questions about the Source engine. Should you have lookedinto several of the mentioned engines, feel free to comment on HL2/Source related issues to the above questions.


Your insights appreciated. Thanx.

AEon

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 refering 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 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 consided 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 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.

Can't find the original article anymore... it was on devmaster.net... but it was a comically flawed article on a Source versus Doom3 engine "technical" comparison. I suppose that's why the site pulled the article from it's pages.

I did find the "aftermath" however:
http://www.devmaster.net/forums/index.p ... topic=2665

I did find this very similar article. Equally disappointing:
http://www.whutdufuk.com/?post=632287876827187500

So that's what not to do.

As always, thanx for the feedback.

I am presently reading up the information at http://www.iddevnet.com (link found in your FAQ at d3w.org) and it is making my head swim. I am still sorting out tidbits here and there and hope to get a consistant picture soon. Will read your feedback very carefully.

BTW what is die official name for the doom3 editor, I have read:

D3Radiant
DoomEdit

and a few other names?

Well, I guess it would have to be "Doom Radiant", or at least that's what it says in the Doom3 level editor.

Though on iddevnet (which is an official id Software page) it's listed as DoomEdit.

As far as I'm concerned, Doom Radiant or DoomEdit is used interchangeably and those are the only two official names.

BTW, there's currently a D3 wiki that we're working on. It's in the early infant stages so I'm reluctant to post the link at the moment. There will probably be some sort of announcement at D3W when it's about ready to go public.

Isn't the official name DoomEd? Does have a ring to it.

One additional point... id Software engines seem to have very long lives which you really don't see with many other game engines. The Q1 engine and the slightly modified Q2 engines were used for very long periods of time... even being used by the original HL game (the new Source engine even has some reminents of the original Q1/Q2 technologies in them).

The Q1/Q2 engines were only replaced by the Q3 engine which even after 6 years running, it proved that it can still compete with newer engines. MoHPA is proof of that... absolutely amazing graphics for something built on 6 year old technology.

The Doom3 engine will probably last for at least as long as the Q3 has been around.

Other engines seem to fade away or need to get replaced with newer versions of the same engine.

You seen Q2:Evolved? Quake 2 looks amazing, with real-time lighting. Take a look in id-legends, in the "guess what engine this is" thread.

Yes, I've seen that, very impressive... but they're modifying the engine source code into something not entirely Q2.

What I meant in my last post was that even without changing the Q3 engine code, games like MoHPA running off the same engine can (almost) give current engines a run for their money.

But you're right, Q2:Evolved = 1337!

obsidian,
good point... will try to keep that in mind, that id engines indeed live quite a while.

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.

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

Yes, indeed.

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

Jup, very useful.

obsidian wrote: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.

I am not quite sure (I tested DoomEdit about 6 months or so ago and forgot , but IIRC there were more things that worked in real time. I downloaded the SDK and will test this, just to make sure I have all the "real-time" features covered.

About the learning curve. For a q3a mapper probably quite true. I learned Far Cry mapping, very much different, fairly quickly as well, but much like you put it, actually making a "good" map, was a totally different matter.

Interestingly while mapping for q3a again, I did not really miss the real-time lighting, since I normally do not go in and tweak lighting, but try to develop a systematic way to place light sources, to give a overall "OK" lighting. When editing for UT2003 (3 intense days) I always had trouble getting the lighting to look good, whereas compiled light always "felt" better... probably it's just because ydnar's q3map2 simply rocks

obsidian wrote: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.

Good point, will mention that effort. AFAICT, you are right Sandbox is Crytek only and so is Hammer from Valve. Either the developers fix things, or they do not get fixed at all. Will check this out for Hammer, to make sure though.

obsidian wrote: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.

Ironically, it took me quite to while to actually understand and miss the per polygon editing in Sandbox. You start off manipulating your terrain, place vegetation, and tons of models making outdoor maps. So that you don't immediately miss your "personal geometry". What you do is use existing Models (for walls, floors, ceiling, fences), much like lego on a grid. And that does take some getting used to. I never really did much indoor editing though.

If you want to add your own geometry, like the tests I was doing for AEglow (or something like AEneon), Sandbox and the CryEngine are simply the wrong engine to do it. Back then, about 12 months ago, there wasn't even a SDK, so even if you wanted you could not add new models.

But when it comes to Terrain and Vegetation, to create breathtaking *editable* landscapes (not some weird meshes built in a modeling tool, see D3 or HL2), the CryEngine really shines IMO.

obsidian wrote: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.

I meant models. I.e. how much more dependant (by choice or by necessity) a D3 mapper now is from external Modeling tools. In Q3A I never ever used a Modeling tool, for Far Cry I looked into Gmax and Wings3D, but found out those tools are just not my thing.

Nice definition of D3 Material and Shader.

obsidian wrote: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.

Aha.

obsidian wrote: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

Interesting. Well a few obvious things the D3 engine is missing out of the box is a Terrain engine that lets you edit terrain in real time, massive use of Vegetation (or plain models), LOD seems to be missing as well, e.g. you can't use massive amounts of geometry, no fallback to lower polygon counts. IIRC shader lighting (like in AEneon) is not possible either. Please correct me if I am wrong.

Sure you can probably "upgrade" the engine by clever coding, much like what ydnar did for q3a (q3map2), but when comparing engines, possible features or probable features don't really count IMO. It's more like what does the engine actually do out of the box. I am not quite sure, D3 had ambient lighting right? (I mean something like static light sources. Far Cry differs between static and dynamic light sources, the latter being a *lot* less expensive).

Note: In re-reading the last 2 paragraphs I noted that seem to have used the term "engine" correctly, since if you have all the source code you can do what you want, but the question usually for Modders is what can the "game code" do, right?

obsidian wrote: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

Hmm... well AFAICT terrain is simply some polygon mesh created in a modeling tool, DoomEdit's per polygon editing features can't (or aren't used for this). Again I am only guessing from what I saw in D3 and a few maps I looked at in DoomEdit.

Personally I do not doubt that the D3 engine is limited when it comes to Outdoor maps, but since Doom3 does not show it, it seems to not be *really* made for them? E.g. how would long viewing distances like in Far Cry work, without a built in efficient LOD model? Sure you can push more polygons, but without LOD? Or would the "game code" let you do that?

Hmmm... From observation in the game, I noted several quite open areas in the game, and those worked well. Alas I have no idea what "tricks" and/or limitations were in place to make that possible.

Pardon my ignorance, but could you sum up what the Doom3CanDoItToo project is doing, and how successful they are.

Again... if a engine is flexible enough, e.g. if it lets programmers actually access and modify "core" features, then this is indeed a *big* plus, and I would certainly want to mention that in my article. But I would also point out that it would again not be out of the box, and would require "extensive" work to add it. (Re-Read: Basically I am asking about the limits of the "game code").

obsidian wrote: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.

Oh... that certainly merits a mention. Reading up on the SDK reminded me of all the powerful scripting a user can to create his/her own interface quite quickly.

obsidian wrote: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.

Oh... I have a table of "features" I will need to put together, and will post that here, to make sure I am actually mentioning all the things correctly. I have indeed trouble differing between what you call engine code, game code and game assets. Especially the way you grouped some of them.

"Terrain, model LoD, cutscenes, collision detection, event handling are considered game code."

Aha... so for the game D3 it was decided to not specifically support real time Terrain or Model LOD? (Pardon my ignorance, I may be confusing the missing geometry LOD with Model LOD).

Does this mean a Modders, using the SDK will be able to add efficient Model LoD or Terrain?

"Other stuff like sounds, bumpmapping and facial animations are considered as game assets."

Hmm... to me assets are stuff like materials, textures, models, sound files.

Bump Mapping, to me is engine code.

I am not sure about facial animation, but I would have considered that part of the engine code or game code. Could you explain the logic behind this?

As this may be, you are of course right, that comparing engines via a "feature list" is pretty much like comparing apples with oranges. Especially since there usually never is a actual level playing field that would let you compare features in an objective manner.

This is the reason I am interested in "real world" comments, from folks that actually worked with the "game code" (SDK), and how they fared with certain features. I.e. as I mentioned the use of Terrain is an integral part of Far Cry (CryEngine), whereas in D3 it is not. Or you can do many things geometry-wise in DoomEdit directly, that you can only do via Modeler for Far Cry. So both can "do" the things, the question is what features are more convenient for the Mod project you plan to do.

obsidian wrote: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.

Good that you mention this. IIRC Q3A had more limitations in this respect, compared to D3, since more things where part of the game engine (other than the examples you mention above)? It would probably be interesting to mention such limitations (and if they are actually painful limitations per se or if one can circumvent most of them).

From reading the SDK info, several things, i.e. the network code are "game engine", but modifiable in part via "game code", more so than q3a? What are other "features" have been opened up to the Modders, that used to be restricted to the "game engine"?

obsidian wrote: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.

Thank you for that wonderful explanation. I had been vaguely aware of this, but did not fully differ. I had always made me wonder were the boundary between SDK source code and the actually game engine source was. The above clears that up nicely.

IIRC there used to be another way to differ between game code and game engine, efficiency. I.e. even if you actually could "shadow" engine functions via game code, the game code would not be fast enough?

obsidian wrote: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.

See my facial animation comment. I understand "models, textures, materials" as assets as well.

I am not sure about animation, if you mean bik movies, then yes. Would model animation control be game code though? The code to play e.g. bik animations or wav/mp3 files is game code as well? (Trying to get a better picture).

I think it should be mentioned though what formats the engine supports (models etc, importers/exporters), because this influences how "happy" folks will be with an "engine", if their fav Modeler is properly supported or not.

obsidian wrote: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.

Hmmm... will try not to mix up the 3. I am not so sure about "technology that they are using is revolutionary" part. Lighting-wise that may well be the case. Trouble is I am no engine expert, so I can't say if the CryEngine or Source at their core are less - let me put it this way - "flexible".

One could point out though that since the folks I am addressing (mappers, Modders) will only be able to work on the "game code/asset" level, so that this should be the main topic (i.e. the SDK).

Since this is an introductory article, you are right that I should make it clear that I am not actually comparing the engines, but more the game code (game assets to a lesser degree) and mention the game engine only in the sense, where there may be limitations imposed by the not free game code source.

Since the article for D3 and HL2 is only about 15K long, and aimed at "the interested" and not the hardcore croud, a few things will need to be simplified / skipped. Hmm.

obsidian wrote: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.

Ah... with the insight you shared above. I would probably be smarter to ask: What other gametypes are possible with the Doom 3 SDK changing only the provided game code? Obviously if you have "all" the code (game engine) you can code anything you want.

So on the game code level, what is possible in Doom3? My guess, probably much more than with Q3A. Examples (existing mods) would be wonderful to help illustrate the flexibility of the SDK.

obsidian wrote: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.

IIRC there was something about the use of VisAreas (Far Cry uses them to define volumes / connections between areas) that was introduced in D3, that differed from what we used to know from Q3A (where solid geometry was basically the only way to block visibility).

obsidian wrote: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

Since I never modded, and only change scripts (materials) I never came across it. Thanks for clearing that up.

obsidian wrote: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

Good to know. Read that in part at iddevnet.com.

obsidian wrote: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.

Will try and do just that. I am not quite sure where one can read up on the "raw engine". The "game code" compares are basically what the SDK lets you do.

obsidian wrote:Hope that helps.

You saved my article from being a really embarrassing show of ignorance (in not differing precisely enough between engine, game code, and assets). I hope you have the time to look into my comments above, to help me understand the situation even better.

Other comments welcome.

Thanks.

P.S. Luckily, I am still in the "article research mode"

^misantropia^ wrote: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.

Interesting, that was my feeling, that the engine + game code cover the minimum set of features to make D3 work.

I hope to be able to get a list of these "features" put together.

Moo, obsidian?

Sorry, been busy this weekend. I'm going to put my thinking cap back on and let it steep in its natural juices for a little while. I'll be back later with some more thoughts.

Note: I'm not writing these paragraphs in any particular order, I'm just reading your last post (which I have printed out on paper) and typing this in Notepad. So sorry if my response jumps around a bit between different subjects.

Learning Curve:
I haven't used the FarCry engine - but from what you're telling me, designing a map is entirely different from the other game engines. While I assume it's easy for terrain, it sounds as if you're trying to make a Q3DM style map it would be quite difficult. I suppose it has to do with a different purpose - FarCry terrain maps vs. a mixture of interior/exterior bases or gothic castles. I was really just commenting on my experiences with Q3/D3 editing compared with Unreal editing, which I found much more difficult to start off with.

Modeling:
With Doom3, you don't have to be dependant on models if you don't want to. Mapping is roughly the same as Q3, drop a brush here, add a patch there and if you want, pop in a few models here and there for detail.

LoD terrain:
Certainly, LoD terrain is missing out of the box for D3, but that doesn't mean that support for it can't be done. If you look at the game, 95% of the game took place indoors, with the occasional area where you had to go outside or at least be able to look outside at the martian landscape. So in that regard, it was pretty pointless to waste developer resources programming LoD terrain when its performance benefit to the game would have been marginal if at all. Compare that with FarCry where 95% of the game took place outdoors. Obviously programming some sort of LoD terrain would have been a major performance boost for that game, so they spent a fair bit of developer time making sure that it worked seamlessly.

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.

Even ydnar didn't have access to the engine code for Q3Map2. All the improvements that he made are strictly isolated to the Q3Map program executable (which is independent of the actual game engine). The vanilla Q3 engine always had the capacity to do all the neat lightmap features that were implemented with Q3Map2, they were just untapped since at the time, they were not required for the commercial release of Q3.

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?".

You were asking about the limits of the game code... we haven't really found any as yet.


Game Assets - a little more defined:

Facial animation depends largely on the models themselves. Looking at the HL2 animations, they are incredible partially due to the amount of polygons that they modeled to the faces. More polygons means that you have more control over subtle parts of the face so you can differentiate between a smerk or a smile or a grin. From that perspective, that's game assets. Most animations are done in the modeling program, for example the run cycle for characters are timed from within the modeling program and the script simply tells the character when to initiate the run cycle and then when to stop. The rest of it has to do with how well you can control and time sequences of model animation through the use of scripting. I'm no expert in this regard, but animation scripting would be considered as part of the game code along with all other kinds of scripting. It basically lists the sequence of animation cycles to start and stop.

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.

I suppose you have to compare the core game engines by themselves first (not easy since there is very little documentation on the technology themselves - they're sort of secrets that are kept by the respective companies). A game engine is fairly hard to understand since it's not something that you can really see when you are playing the game (which is why people have a hard time writing about them). It takes all the game code, the game assets and everything else going on and determines the best way to optimize the stuff and sends all that data to the videocard. Some people look at a game think, "oooh... look at those amazing bumpmaps, much better than that other engine" and not realize that perhaps with some small game code changes or something as simple as using a higher resolution bumpmap images may change their perpective completely.

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.


I may have missed some of your questions above... this is turning to a bunch of lengthy replies so it's easy to miss important stuff. Let me know if there's any questions unanswered or needs further clarificiation.

BTW, you may want to talk to Kat, rich_is_bored, iceheart, BNA! or some of the other people at D3W, they are sure to be able to give you some further insight since they do know quite a bit more of the details of D3 editing than I do.

obsidian wrote: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.

That is pretty much the way I would want to put it, since any real "hard facts" about the engines are not readily available. The game code and what comes with it on the other had is quite apparent.

obsidian wrote: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.

Right, I am sticking pretty much to game code compares only, read the actual implementation of the games the modders/mappers will need to work with.

obsidian wrote: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).

FC, right, it uses different radius "brushes" to highten/flatten the terrain, you basically paint the height into your terrain in real time. Hope to keep that clearly mentioned as well, that some features my not be present in the game code, but can be added.

obsidian wrote: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.

Thanx... will say something like the the above, to give a good reason why LOD was not added.

obsidian wrote: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?".

Will mention that as an example of how seemingly obvious "facts" may be quite wrong, and that the engine is a lot more flexible than one might assume.

obsidian wrote: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.

Ah... makes sense.

obsidian wrote: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.

Actually, since I am starting to take a more practical stance by now, I don't find it as difficult to compare. As long as I do *not* try and pull a cheap "this is better than that", I should be ok. Basically I am only planning to mention the strengths, and what these are good for, and at times mention that this or that is more complicated to do, or not possible out of the box. The modder can then see how game code was implemented, and decide what things he does *not* want to have to code himself. I hope this is a "solid path" to take.

Personally, and I hope I can add that at the end of the article, it all boils down to what *you* the mapper oder modder like. E.g. if you like the nice sunny terrain of Far Cry and the way the AI behaves, and are not really interested in that much indoor areas, then Far Cry can well be a good choice. As mapper e.g. if you definately could not care less about per polygon hit detection, and would prefer to map for a game that *is* playable via ISDN, D3 is dead, plain and simple. There might be mods that change the net code (but again IIRC that was part of the unchangable D3 engine code), but then you would have to map for that mod, and not DM maps that run on vanilla D3. I mention those just to show how I see things.

A ambitious mod team would probably very carefully check the game code of every game, to see what set of features best matches their mod and then decide.

obsidian wrote: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.

That was basically the plan.

obsidian wrote: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.

Bingo.

Thanx for the feedback... now I need to gather some more "hard" facts and write something up

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

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

Now you know what LEM moderators do in our spare time...

It's just that they are long posts and then you quote large sections of the long posts. Anyway, keep talking about the interesting stuff.

Note the main discussion on D3 is happening over at Doom3world.org in my thread with the same topic:

Modern Game Engine Mapping - Compare Article

I am presently trying to get a compare table filled/correctly. Any help therewith appreciated.

Plus for those interested, tons other D3 related discussion happening in that thread as well.

Thanx.


P.S. Started a discussion on Half-Life 2/Source/SDK over at the VERC Network Forums > Half-Life 2 / Source Engine > Source Mapping forums, in this thread: HL2 Modern Game Engine Mapping - Compare

I hope the HL2 croud is as helpful as the folks here and over at d3w.org.

Does this have anything to do with Architecture Mag?

Hex wrote:Does this have anything to do with Architecture Mag?

Nope, it's for a German Magazine. Once the article is out I will try an post some links, though since it is in German that may be less than useful for the more English croud, I guess

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.

obsidian wrote: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.

CET its 6:17am, went to bed 2am, could not really sleep much. It seems the editor spared a bit of more time, Monday morning (at the very latest), seems to be possible as well. And good that that be the case, because I will probably have D3 covered today, but HL2 is still way off... sigh