I think the main disagreement here is that Ben seems to be suggesting that any "properly designed" game intended for a small set of players should properly scale up to 1000''s..

I''ll agree that an MMP engine, designed like that from the start, SHOULD be able to, but only because the architecture is designed in such a way to do so. Making this design that strong takes more time to meet those requirements - it''s not lazy coding to make it only work well for two - it''s simply not taking extra time to add features that are not required for a two player game. Not all alrgorthms scale that well - more inventive precaching schemes need to be devised. It''s not lazy to use a simpler scheme if the time isn''t important.

Here''s a bit more of a different example: Most consumer cars are not capable of going the speeds, and handling the stress, of a fast NASCAR style race - that doesn''t mean the car''s junk, it''s just less expensive in order to do a less stressful job. Same thing with planes - they''re not all designed to go super-sonic, and that''s because they don''t need to because the money to do so is not economic.

A more code-oriented example: A server designed to support 1000 or 2000 players can still lack features - is it distributed? Does it support fail-over if a comp. in the cluster dies? Does it support in-process binary-updates? is the hardware hot-swappable in case a PS or HD dies? Can a coherent backup be made w/out stopping the server?

It all comes down to time / money investment, as well as a previous poster mentioned: Targeted code vs. over-enginieering (making a 2 player game that CAN scale to 1000''s is over-enginieering if the specs only call for 2 players).