I think separate servers are good as long as users have the opportunity to seamlessly switch servers. In other words your game might have 10 servers all hosting the same world but the player can switch to any server at any time. better than a single world because the players can manage population problems and better than instancing because it’s still a world and not a private area (which I prefer). DAoC type clustering is what I’m thinking of here.

If you are okay with zones, then you can do that. I don’t like zones, I like seamless worlds (World of Warcraft). City of Heroes handled their world instancing the same way that Toontown did, and personally I didn’t like it. In fact, EverQuest II creates instances of overland zones when necessary.

It’s an okay solution for zoned worlds, but it’s not even an option on the table for seamless worlds.

I also believe it screws with the community. There’s a bunch of research on what the maximum “community” size is (as perceived by a single person), and it isn’t a million. It’s not even 100,000. It’s generally below 1000.

If there are 1,000,000 or, more realistically for the average successful MMO, 250,000 players on one “server” (instanced set of zones), there’s no way you’re going to know most of those people.

There’s little benefit gained from cramming so many people on one server, especially because they’ll just form their own little micro-communities anyway because people will intentionally want to segregate themselves from those overwhelming numbers.

It’s not without benefits, though. You can be more likely to ensure that there are enough people around to form groups, especially for group-based dungeon crawls and the like. This is a good thing.

New players will always feel part of a community of some sort, because there will always be people around even if they are soloing (there’s a lot of proximity benefit to having other people around, even if you never interact with them verbally or physically in any way).

User Acceptance is very important in Software Development. This is not to suggest that each developer / designer needs to wade through the forums. There are many other ways for End User feedback/issues can be feed through to your development team.

A developer / designer should be interested in the way his/her work was received by the end user, if it’s being used as intended and if his/her work was fit for purpose.

#6 – Disagree. Key people absolutely do need to pay attention to community feedback, but the average team members needs to focus on their task list, not worry about message board debates. Some people can involve themselves in that level without being distracted, but some can’t. It shouldn’t be a requirement that they try. Their direction from above should be taking all that into account.

Apart from those quibbles, I agree.