Just to be clear, my quoted comments were trying to explain what I thought Raghar was saying, not necessarily my opinions :).
You appear to be missing the point that “game design” is an entirely separate kettle of fish from “application design”. Requirements gathering, spec’ing, etc are all part of app design (they could be part of game-design too, in which case you are doing two sets of each).
Perhaps because game development is not about implementing an idea but about implementing a game-design, which is so much more complex than a single set of requirements / use-cases / etc that it (traditionally) is treated as an entirely separate process in and of itself?
The way that it’s usually described (lazily) in the industry (i.e. in lectures, articles, face-to-face, etc) is something like: “rather than only having requirements, we have an extra thing we have to manage called “putting the fun in”, and that’s not encapsulatable and becomes a parallel/separate process to the sofware engineering/design”. Most people don’t bother trying to explain it beyond putting some phrase in inverted commas with the word “fun” in there somewhere, with the implicit assumption “you know what I mean”.
Well, my suggestion was that the workload was getting beyond your capabilities as in individual (no matter how great you are…). But I can see a separate point that if you really had a game design completed then you wouldn’t need to spend much time picking particular technologies - because the game-design has already given you enough information to generate additional requirements on-the-fly.
c.f. Star Wars Galaxies, where the team was run from a 100+ page game-design document. Whenever questions came up about impreciseness in the software requirements, or about “should we adopt algorithm/library/technology X instead of the Y we were planning?” the game-design doc was used as “the bible” which would answer the question without allowing room for competing opinions - it’s say was final.
Probably my attempt to extend the analogy tripped up :).
You are certainly in a minority when compared to commercial games developmers, then. Whether your way of looking at things is right or wrong (I’m not qualified to have an opinion on that! Ask me again when I’ve managed 10’s of games projects ;)), it’s not how others do things. Personally, I’m inclined to agree with that majority on this subject: my experience strongly supports the view that if you don’t separate game-design from software-design then your game has a much higher chance of sucking as a game (i.e. being boring, unsatisfying, or unaddictive to play), even if the software engineering side is perfect (no bugs, short dev time, etc etc).
dot-com companies, where the “feelings” of the client were taken on board more explicitly, there is a part of the software design process that is similar to this gameplay stuff? But personally I struggle to find neat equivalents in the traditions of software engineering. When talking to investors, I usually describe it as “usually, when software is being written competently, it is solving some problem or need - such that even though the client usually doesn’t know precisely what they want, at least it’s possible to analyse it and work out what they want and give it to them; in games development, there is no such need nor problem, there’s nothing to analyse, you can only invent. This demands different (additional) processes”.
It looks like a statement to me, not a question :D, an oppinion about a subject formed on no facts about that subject, precisely the definition of the word misconception ;).