If they think they're going to get some bragging rights because they finished everything faster than other people I think they'll find that others will be naturally suspicious of any advancement that seems “amazing”.

In multi-player games though, the server has to be the gatekeeper to every scrap of information. As the various first-person shooters have shown over the years, you can't even ship down information about another player's location on the other side of the wall. Somebody will try to hack things so they can see through the walls on their client side or whatever the equivalent is for your game if you let too much leak.

If your game really needs several thousand players to get going…because they need to create an economy or provide a viable game environment, but the game only has several hundred currently active users then you have a problem. So for me its really how do you solve any mis-match between design expectations and actual conditions.

Regarding problem 2, this sort of ties into the 'goal' issue that Tom also raised. Most MMORPG players are quite happy to suspend their belief and accept a stasis world, but these kind of setups often lead to unclear game goals…or the goal is simply to keep building up your character. If a game sets clear goals then that might help to retain players.

The lack of clearly defined goals would also appear to be a major factor in the reduced uptake of game playing amoungst females, at least thats what the literature that ive read says, and is highlighted by Toms wifes comment

As for how to deal with player churn, I think you need to consider this in the design stage and ensure that your game is not adversely affected by it.

Finally regarding point 3, i hold to the idea that “just because we can doesnt mean we should”. Namely just because we can make something complex, doesnt mean we should. The corrolory from einstein…”Everything should be made as simple as possible, but not simpler.”

Im sure we've all seen games where some special event appears to happen randomly with a very small chance, and as developers we can guess that what theyve done is simply generate a random number and compare it to some threashold, Yet amoungst the player base there are all sorts of beliefs and theories about how you need to do this , then that …then something else and it will increawse your chance of that event occuring….This exemplifies peoples innate ability to overcomplicate things, so rather than overcomplicate your game code, let peoples imaginations complicate it for you.

I prefer to hide (or eliminate altogether) as many of the variables as possible. Not only does this help keep the game interface simple, it also keeps the games code base simple, and allows room for the players to imagine the complexity. (in fact i may even hint at hidden complexity in the games helpfiles just to make sure that the seeds are planted)

Something like that would be a bit beyond my skill for the moment but anyone with that big a site must have some talent at getting the affects they want.

As for some of the other large-numbers problem, those would vary from game to game, as each has different styles. For myself, I generally prefer single-player with tacked on multiplayer features type games. I have seen large sites handle large numbers of users in that style and it works. The biggest problem I've seen in sites is inflation of virtual money, to be truthful, since sites with user shops and such often have no taxation or anything to balance money in a place where it is constantly being pumped in by new users. Users buy features which they then sell again to make more money– and the virtual coin goes through the roof like mad.

Regarding Problem #1, my game is essentially a single-player CRPG with persistence. Each player begins with his own world with procedurally-generated terrain, cultures, and quests. The player can invite other players into his world, perhaps to help with a hard quest or maybe every time he logs in (making it a sort of shared world in that case). Right now the player can invite up to two others, but I'm keeping an eye on how that's working to see if more might be practical. There's also a unified lobby where all players who are logged in can chat and view others' accomplishments.

On Problem #3 and issues of complexity, I tend to look at it from three angles: the complexity of the underlying systems; the complexity you present to players; and the complexity the players can elaborate from the given pieces. The original iteration of the Magic: The Gathering collectible card game is an example where the underlying mechanics took a lot of balancing, but the choices presented to players within the game were pretty straightforward at any given moment. Nevertheless, the potential combinations of those choices were really fertile ground for novel strategies and deck-building techniques. Personally, I think that as they added more mechanics over time, and thus more choices for players, the game became more difficult to learn and the potential strategies harder to hold in your head at one time.

The question of how much complexity to present to the player is the difficult one for me. I tend to want to abstract as much as possible of it away, but I suspect there are many players who really want to know what's going on under the hood. I remember Ultima Online originally having skill levels measured in whole numbers from 0 to 100, then later adding the ability to view the fractional skill levels (e.g. 70.25) at the insistence of the players. So maybe the best decision is to let players choose a level of detail that they're comfortable with.

A PBBG design problem for me is how you bring a sense of purpose to a persistent game. My wife's question about MMORPGs is always “What's the goal of this game?” And it's true that the goal is often “do quests so you can level up so you can do harder quests; wash, rinse, repeat.” With my design, I've tried to add some additional goals by having a world “winnable” at which point the player gets to enter a new unique procedurally generated world, perhaps with radically different terrain and cultures to interact with. As an exploration-oriented player, this particularly appeals to me.

A last challenge I'll mention is more of a technical design question, but it's the classic one of how much work you put on the server and how much on the client, realizing of course that if the client is a browser, as in the case of PBBGs, that the Javascript and XHTML are trivial for the user to inspect and the current values of Javascript variables and any cached images (such as maps) are also readily accessible for a user who know what he's doing. At the same time, the client's computer likely has a lot more unused processing power than your server at any given time and you also want to limit how much bandwidth you're using. Every game design decision ultimately comes down to the question of how I'm going to implement this in a way that discourages cheating but doesn't tax the server unnecessarily.