[MUD-Dev2] [Design] Where are all the amateur MMORPG devs?

[Mike Rozak]

John A. Bertoglio wrote:
> With a graphic mud,
> no matter how sophisticated the tool set, an amateur effort will almost
> always look...amateur. The skill set to build a credible world with custom
> graphic content is just too broad for most potential hobbyists.
> Snip...

Your E-mail got me thinking about a few issues (some of which are just 
reworded versions of yours):

1) It's a LOT of work to create a graphical world, which REQUIRES players to 
form large groups to accomplish their tasks. As a guestimate, to make an 
exact clone of a professional MMORPG, you need 10x the volunteers, due to 
lack of time/experience. Thus, to clone WoW you'd need 1000+ volunteers.

Leading an army of volunteers is like hearding cats because they don't have 
a paycheck to keep them following the leader, only the vision/goal.

Which leads me to think of an concept, which I'll mis-relate to the Dunbar 
Number (http://en.wikipedia.org/wiki/Dunbar_number). My variation is: "The 
more focused and popular a vision/goal is, the more volunteers that can be 
sustainably organized to achieve it."

Thus, if I were to espouse a vision/goal of "Creating a WoW clone down to 
the last pixel," I'd get an army of volunteers, and they'd be "sticky" 
volunteers.

However, if my goal were to "Make the best MMO ever", which is vague and 
fuzzy, I'd start out with a lot of volunteers, perhaps 1000. And then 
there'd be a split over some feature (butter side up vs. butter side down), 
and there'd be two teams with 500 each. Eventually, each of those would 
split over a dispute. Ad infintum, until  there were hundreds of groups all 
trying to create "The best MMO ever, but with feature XYZ."

To point out a example of "Creating a WoW clone down to the last pixel", 
just look at Linux. The original goal of Linux was to "Create a free clone 
of Unix", which is clear, concise, and a good rallying point. This then 
became, "Create a competitor to the evil empire, Windows", which is also 
clear, etc.

What this implies is that (a) you can get a large group of volunteers to 
create a clone of a popular product, but (b) you can't get a large group of 
volunteers to be creative since they'll fragment into smaller groups.

(c) Graphical MMO projects fail because large groups of volunteers (needed 
to actually complete a MMO) fracture into small groups (< 10 people), and 
they all eventually give up because they don't have the manpower 
individually. (I'm guessing that fracturing stops around 5-10 people because 
by that point "friendship" is often strong enough to keep the group 
together, despite the goal being fuzzy.)

(d) Text MUDs can be completed with 5-10 people, so there are more text MUDs 
despite there being many more potential MMORPG authors.

By the way, I've just described politics 101 (sound-byte vision to lead 
"volunteer" voters), marketing 101 (sound-byte slogans), and why armies are 
divided into platoons (friendship).



2) Providing a default world is good (but a double-edged sword).

A large default world provides sample code/graphics, which makes creating a 
new world easier because there are lots of examples to start from.

A large default world can attract players right away. Around 0.1% to 1% of 
players(?) join the development team, so lots of players produces more 
developers/builders. More developers/builders means more content, which 
means more players. Positive feedback cycle.

This would be PERFECT if there were only one version of the default world. 
However, the easier (and better) the default world is to set up, the more 
versions of it that will be created... And thus begins stock MUD syndrome. 
Eventually, there will be so many copies of the exact same world, that 
players will be divided up amongst them all, and so are the developers. 
Ultimately, no meaningful changes get made to the default world because 
there aren't enough developers in each.

Thus, if a stock world is too easy to set up (and too good), then there will 
be zillions of stock worlds, all identical, and all with only one person on 
the development team. The single developer will get frustrated with his/her 
lack of progress and give up. The player base, in general, will get 
frustrated with the stock MUDs all being identical, and never come back.

So there's some sort of balance between the size/quality of the default 
world, and how succesful the toolkit ultimately is. Too small (aka: don't 
attract many players or provide much sample code) and the toolkit fails. Too 
large (aka: lots of copies of the world are made) and the toolkit also 
fails.

How big was the default Diku world? 2000 rooms?