Design from Tech or Tech from Design
A point addressed many times throughout this treatise is the effect of the codebase and its limitations on what content and systems you are able to implement in a computer based RPG. A designer may have a cool idea, but when he props it, the code team says, "Never happen," "Requires new tech," "Not possible given our development cycle," etc. These are valid arguments, and some pie in the sky features will never make it into a particular game system because of them. However, eventually the designer gets sick of hearing these things, and so begins to only propose things he knows have a good shot being implemented given the restrictions of the code. As a result, all of the new content winds up looking pretty much the same, with no innovative characteristics.
There is an analogy to this situation that I have personally bitched about for years, in the field of musical composition. At its purest level, the act of musical composition (the design phase) is done purely in one’s head, and the subsequent translation to paper and copy is only a method of communicating the mental sound-picture to players who can then execute it. As the composer gets more tools (tech), he can easily slip into the trap of basing all of his ideas on what his tools can do. One current example of this attitude in the music industry is the use of sequencers as a composition tool. An over-reliance on the sequencer (tech) to determine what you can compose (design) results in very similar, boring music, since you tend to avoid things that are difficult to express using the sequencer (tech limitations).
It stands to reason, therefore, that it’s possible to conceive more interesting and innovative systems if you don’t consider the practical limitations of technology during the initial design phase. However, because tech limitations are a reality, not all of the cool ideas you come up with on the design side are going to make it into a product that has a reasonable development cycle. Pushing this issue causes problems in the form of contempt between the design and tech teams as follows:
Design: "I want to implement this feature, it’s really cool."
Tech: "This will never happen if you want this game to ship in this decade."
Design: "But I NEEEED this! Do it!"
Tech: "Screw you buddy."
This problem becomes even more pronounced in a persistent world system post-release. A suggested feature from design that’s supposed to be patched into the existing code is even more subject to the limitations of technology, especially if that technology was released over a year ago. Rewriting your entire engine because you want to implement something new is very risky and financially not feasable.
Tech gains contempt for design because design is obstinate and unrealistic. Design gains contempt for tech because tech is viewed as lazy. In fact, either or both of these could be true. These problems have to do with personnel decisions and human resources, and are outside the scope of this document. Basically, though, having a tech and design team who are compatible and have a similar vision of making a really cool game is a good thing in some cases. Like, if you want to make a really cool game.