I don''t think it''s fair to call the design consistency issue laziness. I''m sure in some cases it is, but I''d think in most it''s due to the fact that design is untestable on the page! I mean, you can have proofreaders and good organization, but there''s no way to run a debugger on your design.

In many cases, anything beyond PacMan seems to beg for design bugs to crop up. The devil''s in the details, as they say. Just last night I discovered a design bug like that ("on page 16 is says radar is obsolete, but on page 36 one of the units is a radar tower!!!") If I were to do the equivalent in code, my program would crash!!!

--------------------
Just waiting for the mothership...

That''s true, Wavinator. It is unfair. And I''m not one to talk, as I''ve been too lazy to even get a single game up and running. So there you have it. But I would like to ask someone w/ more experience in direct game programming- is it that different than other OOP? It would seem that you can program an in-game object as, say, a C++ object, and it should behave the same way every time. I prefer the simple, elegant solution (rather than hacking out for weeks and weeks the properties of each window), and as far as I can see, this would work.

I''m not even talking about "atmosphere" or "story" gaffes here, like the radar example. Those, to me, are forgivable. Even Homer''s "Iliad" had these kind of inconsistencies. (in a few parts, he would kill off the same character several times in a single battle!) I''m talking more about gameplay issues, and the principle that a certain object in your game shouldn''t suddenly exhibit new behaviors that go totally unexplained.