Well, I could, but it wouldn't mean shit to me, so I'll take your word for it, Ratty.

I'm no game engine guru. Really, you don't need to know squat about programming not to notice what I'm talking about. I don't have the source handy anymore so specifics aren't on the tip of my tongue any more, but for example, you'll notice class names are extremely Quake 2 specific. You don't have abstract types for various kinds of AI, you have classes for RobotMechCommander or FlyingTooperThingy (I don't remember the names of Quake 2 monsters but you get the idea). It seems to me that things that are usually filled out in game code are actually done explicitly in the engine source code, in Quake 2 at any rate (which is actually weird since the Quake engine game code components and QuakeC are really excellent). There are other weird Quake 2 specific things in the code too, but that's just one that comes to mind.

I recall two high profile games that licensed Quake technology and then switched to another engine when they figured out it how much work it would be to try and adapt it to their own games. One was DNF and I forget the other one. id has said on a number of occasions that engine licensing accounts for just a small fraction of their revenue. The real bucks come from the games they make, so their strategy of making a game just for themselves, just for the game they're working on is a sound one. I'm not criticizing it. I'm just pointing out that a good engine is a relative concept. There are benefits and liabilities to be weighed in engine architecture. I most definitely recognize the benefits but I'm suggesting people not forget the liabilities.

A side note on Quake engined games. I notice two constants with these games that bug the hell out of me. The first is the sniper rifle. If you move while zoomed in with the sniper rifle in any quake engined game, you unzoom. You can only stay zoomed in if you're standing still. Only Quake engined games do this in my experience, and they ALL do it. It seems unlikely that developers just decided they liked that "feature" and that they ALL kept it in. I have to wonder if all the sniper rifle code is embedded in the engine code rather than the game code. I'll have to remember to take a look someday. The second is the save menu. I have always found it unintuitive and also unresponsive. Sometimes I click on a save slot and it won't save, like I'm not clicking on the right pixel or seomthing. And other menu annoyances, but all the Quake-engined games I've played do this. Now putting the menu code in the engine source would be insane, IMHO, especially considering, again, just how good QuakeC is, but I suspect that's just what they did.

Why are you assuming that they don't place things where they do the most for gameplay? And why are you assuming that there is a conflict between good looks and gameplay?

I'm not making that up. That's what the designers said they did in a couple of Doom3 interviews. They placed the monsters where they would look their best, even though they wanted to do otherwise a few times. That also answers your second question.

The Doom3 engine would probably be great for other dark, shadowy, horror games that take place largely in small cramped corridors and rooms and occasional small outdoor areas. But for other games I think developers would do weel to look elsewhere.