I admit that I also missed the Voice of Saruman sequence (although something akin to it may be in ROTK EE), but having Shelob in TTT would either have not worked, or would've had to have been changed so much that it wouldn't resemble what was in the book.
The reason being that having 2 climaxes of that nature (Shelob and Helm's Deep) would simply be unsustainable. In a book it can work, especially as the two stories are seperated into individual books, rather than interwoven as they are in the film. But in a film they would simply undermine each other. This is why they added the scenes of Frodo and Sam being taken away by Faramir - it introduces a new tension, but one of a completely different nature to that of Shelob.
I know this has been said many times before, but it is quite important - these are the film versions of LOTR, not the books. The rules for what will work in a film, as compared to a novel, are vastly different. Sometimes unfortunate, but it has to be lived with.
My point is that a bunch of programmers familiar with the Q3 engine will aclimate themselves to the D3 engine more quickly. You have to understand an engine before you start writing code for it.
I agree with the latter part of this, but not so much the former. Largely because I believe, primarily through experience, that having intimate knowledge of a system (or, in this case, engine) can often lead to a slower understanding of a new system. Why? Because you'll go into working on the new system with a good deal of assumptions and beliefs regarding how it will work, only to have those beliefs made invalid. Thus, you not only have to learn a new system, but also actively undo all the assumptions that you had in equating it to the old system. This can sometimes be very hard - even (sometimes especially) if it was the same person/people who wrote the code for both iterations.
This was my point with the Daikatana example. They appeared to have the belief of "Well, they're essentially the same engine, so it shouldn't be hard to port our stuff over". As I said - a dangerous, but probably unconcious, assumption.
Now, if you have stated that people who are fimiliar with older id engines will be more likely to use them again because they have a relationship with id, or that there is something that they like about their design process, I would agree. However, I don't believe that they will necessarily be able to aclimiatise themselves to the new engine just because they used their last one.
Actually publishing conceptual and technical info with source for the current engine is more self-serving than releasing the old engine. It was absolutely in the companies financial interest. Again, you have to keep in mind that a large piece of id's business, maybe the larger piece, is to license their engines not to sell their own game.
Nah. If they had released technical info that had been along the lines of "Here is how you make a model for use with our engine" or "Here is the SDK for our engine so you can write mods for it" then I would agree with you. But they were giving away source for things that would already been known by people working in the industry (BSP trees, Z sorted spans, etc are hardly anything new - they've been around for decades). The people that this would have benefitted were those in the community at large - ie. individuals who want nothing but to learn, and probably couldn't afford an id engine if they saved every penny they had for 5 years.
They can afford to open the previous generation's source because they want a large body of programmers familiar with their engines. This puts pressure on developers to chose an id engine over someone else's.
Would be good in theory - if each different generation of theirs engines where similiar. For better or worse, they are often not. The obvious case here being the jump from Doom to Quake, but even each iteration of the Quake engine has had significant changes that would make a change over far from trivial.
Case in point would be Daikatana - if anybody was going to be "familiar" with id's engines, you'd think it would be a former co-owner and employee. Originally Daikatana was designed and written using the Quake engine, which John Romero had been working with while it was being develop. Then, when the Quake II engine made it's first appearances, Ion Storm decided to change over to it; afterall it would give them coloured lighting, hardware acceleration and it was based on the Quake engine, so it couldn't be that hard, right?
Unfortunately, as they found out, the differences between the two were enough so that large sections of Daikatana had to be thrown away (see this, if you want to check that out). Admittedly there were many other issues with Daikatana's development, but even Romero himself said that basically 11 months of coding with the Quake engine were useless once they switched to Quake II.
Plus, id have done other things, outside of OSS, that have contributed to the community. Michael Abrash, who worked on the Quake engine, was also writing for Dr. Dobb's Sourcebook at the time. The subject of his articles? The tech that was going into the Quake engine - often with sourcecode. To put this in perspective, this was over 6 months before Quake was even released, yet there they were showing code on how to do BSP tree generation and rendering, descriptions of their lightmap system and so on and so forth. Stuff that, essentially, ended up in the game when it was released about half a year later. Hardly in their company's best interests if they want to be purely self-servicing.
Hmmmmm... that's starting to sound like a id fanboy rant, but there you go....:)
Not necessarily. This all depends on how it's implemented. Sure, you're going to undergo some performance hit, the question is whether or not it is significant or not. The abstraction should still be built very close to the target API - there's no reason to have it support everything and the kitchen sink - but several of the more common APIs have enough similarities (case in point, notice how Direct3D became more and more "OpenGL-like" during it's evolution) that you can primarily target one, but keep one or more others in mind while doing the design.
I'm not saying that you _have_ to support every API under the sun from the start, merely that it is quite possible to have a design such that a game is not tied to a given API to the point of a port being a major effort.
Cases in point - Quake 2 and Unreal. Both supported multiple renders at release. Quake 2 had both a software and OpenGL render. Unreal had a software and Direct3D render (and an OpenGL renderer too). Without some level of abstraction internal in the engine this would have been a major effort to do. As it is, it still isn't trivial, at shipping. Here, I am talking about merely designing an engine such that it allows for easier porting in the future.
As a side note - if you want to look at bad examples of this, check out Ultima Ascension. Ran fine on a 3DFX card, but the Direct3D performance was abysmal. May have been resolved in later patches (I don't know as I had a Voodoo 2 at the time), but at shipping it was pointless to even try on anything by a 3DFX card.
...Linux is a pain to develop a good game client for. DirectX games are not easily ported, and most games are DirectX. This means most professional game developers are fluent in DirectX. DX makes things a lot easier than writing for every sound/video card out there.
Well, I'll put aside the fact that any developer worth their salt should make abstractions, such that they don't expose anything DirectX based to the engine directly, rather the engine talks to a layer that handles the DirectX calls for them (the upshot of this being that it's easy to simply drop in a new abstraction layer if you want to add support for a different API, say OpenGL, thus making porting relatively easy). But, implying that under Linux one has to code for every video/audio card directly is simply ignorant (yes, you didn't _say_ that as such, but it is easy to read that into it).
There are many different APIs that one can use to achieve uniformity. The obvious ones that are brought up often being OpenGL and SDL. But there are others - OpenAL, HawkNL, OpenIL... a very long list of choices that one can employ to avoid having to code anything vendor specific and at the sametime often have the benefit of being able to use said APIs on multiple platforms (all of the ones listed above support Linux, Mac OS X and Win32, to name but a few). Plus, some of these APIs, outside of being Open Source are supported, or even developed, by IHVs directly.
Quake3 for Linux sold dismally, while people were buying the Windows version enough to be dunking the CDs in their coffee. And the Linux client was released first: if ever there was an opportunity for a killer-app game to help boost Linux, that was a great time.
Stated quite clearly in there is that vendors were pushing the Windows version of Q3 much stronger than the Mac or Linux versions (for obvious reasons) - to the extent that the Windows version was available first. Reading between the lines it's quite obvious that what is being said is "If you want to support Linux, _don't_ buy the windows version of Q3 and then simply d/l the binaries - wait until the Linux version comes out at the shops". Not surprisingly I doubt many people did this, as they wanted to play thei new game _now_. What is quite clearly the case though is that the Windows version was available before the others, not the other way around.
Loki went out of business by doing the smart thing: bootstrapping itself with porting Triple-A titles from Windows, to earn some cash and develop a library to live on. Who's going to look at the Linux market and see it as viable when id and Loki can't make a good go of it?
As has been debated many times - Loki went out of business largely due to mismanagement, _not_ due to lack of support. Publishers and distributers aren't looking at id and Loki and saying that "Linux isn't viable", they simply _aren't_ looking at all since they are entrenched in the Windows market. They need to be made aware of Linux in the first place.
Linux users are habituated to not paying for Linux software, as a rule... taking on the burden of developing the same thing without that help, for a community that likes their software free (both kinds of free),... that's a lot to expect.
This is a fallacy that I think needs to die. The belief that "All Linux users won't pay money" is just absurd. Sure, there are zealots out there who refuse to use any software that isn't Free (as in speech) and distributed under the GPL, _but_ here's the thing - _those people aren't the ones that people will market things at in the first place_ (they didn't buy Windows either, afterall, so they just fall off the radar). The point here is that Linux is becoming more mainstream, and as it becomes more mainstream the percentage of zealots compared to the community as a whole will _decrea
Slashdot Mirror
Unfortunately - it wouldn't have worked.
I admit that I also missed the Voice of Saruman sequence (although something akin to it may be in ROTK EE), but having Shelob in TTT would either have not worked, or would've had to have been changed so much that it wouldn't resemble what was in the book.
The reason being that having 2 climaxes of that nature (Shelob and Helm's Deep) would simply be unsustainable. In a book it can work, especially as the two stories are seperated into individual books, rather than interwoven as they are in the film. But in a film they would simply undermine each other. This is why they added the scenes of Frodo and Sam being taken away by Faramir - it introduces a new tension, but one of a completely different nature to that of Shelob.
I know this has been said many times before, but it is quite important - these are the film versions of LOTR, not the books. The rules for what will work in a film, as compared to a novel, are vastly different. Sometimes unfortunate, but it has to be lived with.
I agree with the latter part of this, but not so much the former. Largely because I believe, primarily through experience, that having intimate knowledge of a system (or, in this case, engine) can often lead to a slower understanding of a new system. Why? Because you'll go into working on the new system with a good deal of assumptions and beliefs regarding how it will work, only to have those beliefs made invalid. Thus, you not only have to learn a new system, but also actively undo all the assumptions that you had in equating it to the old system. This can sometimes be very hard - even (sometimes especially) if it was the same person/people who wrote the code for both iterations.
This was my point with the Daikatana example. They appeared to have the belief of "Well, they're essentially the same engine, so it shouldn't be hard to port our stuff over". As I said - a dangerous, but probably unconcious, assumption.
Now, if you have stated that people who are fimiliar with older id engines will be more likely to use them again because they have a relationship with id, or that there is something that they like about their design process, I would agree. However, I don't believe that they will necessarily be able to aclimiatise themselves to the new engine just because they used their last one.
Nah. If they had released technical info that had been along the lines of "Here is how you make a model for use with our engine" or "Here is the SDK for our engine so you can write mods for it" then I would agree with you. But they were giving away source for things that would already been known by people working in the industry (BSP trees, Z sorted spans, etc are hardly anything new - they've been around for decades). The people that this would have benefitted were those in the community at large - ie. individuals who want nothing but to learn, and probably couldn't afford an id engine if they saved every penny they had for 5 years.
Would be good in theory - if each different generation of theirs engines where similiar. For better or worse, they are often not. The obvious case here being the jump from Doom to Quake, but even each iteration of the Quake engine has had significant changes that would make a change over far from trivial.
Case in point would be Daikatana - if anybody was going to be "familiar" with id's engines, you'd think it would be a former co-owner and employee. Originally Daikatana was designed and written using the Quake engine, which John Romero had been working with while it was being develop. Then, when the Quake II engine made it's first appearances, Ion Storm decided to change over to it; afterall it would give them coloured lighting, hardware acceleration and it was based on the Quake engine, so it couldn't be that hard, right?
Unfortunately, as they found out, the differences between the two were enough so that large sections of Daikatana had to be thrown away (see this, if you want to check that out). Admittedly there were many other issues with Daikatana's development, but even Romero himself said that basically 11 months of coding with the Quake engine were useless once they switched to Quake II.
Plus, id have done other things, outside of OSS, that have contributed to the community. Michael Abrash, who worked on the Quake engine, was also writing for Dr. Dobb's Sourcebook at the time. The subject of his articles? The tech that was going into the Quake engine - often with sourcecode. To put this in perspective, this was over 6 months before Quake was even released, yet there they were showing code on how to do BSP tree generation and rendering, descriptions of their lightmap system and so on and so forth. Stuff that, essentially, ended up in the game when it was released about half a year later. Hardly in their company's best interests if they want to be purely self-servicing.
Hmmmmm... that's starting to sound like a id fanboy rant, but there you go.... :)
Not necessarily. This all depends on how it's implemented. Sure, you're going to undergo some performance hit, the question is whether or not it is significant or not. The abstraction should still be built very close to the target API - there's no reason to have it support everything and the kitchen sink - but several of the more common APIs have enough similarities (case in point, notice how Direct3D became more and more "OpenGL-like" during it's evolution) that you can primarily target one, but keep one or more others in mind while doing the design.
I'm not saying that you _have_ to support every API under the sun from the start, merely that it is quite possible to have a design such that a game is not tied to a given API to the point of a port being a major effort.
Cases in point - Quake 2 and Unreal. Both supported multiple renders at release. Quake 2 had both a software and OpenGL render. Unreal had a software and Direct3D render (and an OpenGL renderer too). Without some level of abstraction internal in the engine this would have been a major effort to do. As it is, it still isn't trivial, at shipping. Here, I am talking about merely designing an engine such that it allows for easier porting in the future.
As a side note - if you want to look at bad examples of this, check out Ultima Ascension. Ran fine on a 3DFX card, but the Direct3D performance was abysmal. May have been resolved in later patches (I don't know as I had a Voodoo 2 at the time), but at shipping it was pointless to even try on anything by a 3DFX card.
Well, I'll put aside the fact that any developer worth their salt should make abstractions, such that they don't expose anything DirectX based to the engine directly, rather the engine talks to a layer that handles the DirectX calls for them (the upshot of this being that it's easy to simply drop in a new abstraction layer if you want to add support for a different API, say OpenGL, thus making porting relatively easy). But, implying that under Linux one has to code for every video/audio card directly is simply ignorant (yes, you didn't _say_ that as such, but it is easy to read that into it).
There are many different APIs that one can use to achieve uniformity. The obvious ones that are brought up often being OpenGL and SDL. But there are others - OpenAL, HawkNL, OpenIL... a very long list of choices that one can employ to avoid having to code anything vendor specific and at the sametime often have the benefit of being able to use said APIs on multiple platforms (all of the ones listed above support Linux, Mac OS X and Win32, to name but a few). Plus, some of these APIs, outside of being Open Source are supported, or even developed, by IHVs directly.
Quake3 for Linux sold dismally, while people were buying the Windows version enough to be dunking the CDs in their coffee. And the Linux client was released first: if ever there was an opportunity for a killer-app game to help boost Linux, that was a great time.
Not true. Check out...
John Carmack's Finger
Stated quite clearly in there is that vendors were pushing the Windows version of Q3 much stronger than the Mac or Linux versions (for obvious reasons) - to the extent that the Windows version was available first. Reading between the lines it's quite obvious that what is being said is "If you want to support Linux, _don't_ buy the windows version of Q3 and then simply d/l the binaries - wait until the Linux version comes out at the shops". Not surprisingly I doubt many people did this, as they wanted to play thei new game _now_. What is quite clearly the case though is that the Windows version was available before the others, not the other way around.
Loki went out of business by doing the smart thing: bootstrapping itself with porting Triple-A titles from Windows, to earn some cash and develop a library to live on. Who's going to look at the Linux market and see it as viable when id and Loki can't make a good go of it?
As has been debated many times - Loki went out of business largely due to mismanagement, _not_ due to lack of support. Publishers and distributers aren't looking at id and Loki and saying that "Linux isn't viable", they simply _aren't_ looking at all since they are entrenched in the Windows market. They need to be made aware of Linux in the first place.
Linux users are habituated to not paying for Linux software, as a rule ... taking on the burden of developing the same thing without that help, for a community that likes their software free (both kinds of free),... that's a lot to expect.
This is a fallacy that I think needs to die. The belief that "All Linux users won't pay money" is just absurd. Sure, there are zealots out there who refuse to use any software that isn't Free (as in speech) and distributed under the GPL, _but_ here's the thing - _those people aren't the ones that people will market things at in the first place_ (they didn't buy Windows either, afterall, so they just fall off the radar). The point here is that Linux is becoming more mainstream, and as it becomes more mainstream the percentage of zealots compared to the community as a whole will _decrea