[MUD-Dev] business models
Matthew Mihaly
diablo at best.com
Tue Feb 15 16:38:55 CET 2000
On Tue, 15 Feb 2000, Sellers, Michael wrote:
> David Bennett wrote:
> > Muds (and games in general) are always going to be a low paid field, so in
> > general the people that end up in this sort of field are people starting
> > out thinking it will be fun. Or people who cannot get employed elsewhere
> > :) Although there are a few fanatics that stick with it.
>
> I disagree, partly. MUDs will split increasingly I think into two main
> categories: hobbyist/labor-of-love games for which there is essentially no
> pay; and professional, well-backed games for which there is adequate pay.
> Increasingly, game industry salaries (including those for MMPOGs) are
> approaching parity with the rest of the software industry. (Of course there
> will still be low-paying jobs in the no-mans-land of startup commercial
> MUDs, but I think they're going to have a more difficult time staying afloat
> as time goes on.)
I've started a new thread title, because this really doesn't have anything
to do with code bases anymore.
Interesting Mike. I'd be interested to know your reasoning behind
saying that the startup commercial muds will have a more difficult time
staying afloat as time goes on. I believe you are wrong, though that
belief isn't extremely strong. I believe that your belief is predicated on
the idea that small muds possess the same business models as the big muds,
whereas this isn't the case (or shouldn't be the case, if you want to make
any money as a small mud). Big muds don't go for big profit margins (well,
everyone does I suppose, but they certainly aren't expecting 80% margins
I'd imagine), because they don't need to. 10% of 12 million a year is a
lot more than 50% of 500k a year. Of course, the amount you risk to
produce that 12 million in revenue is much larger than what is required to
produce the 500k in revenue (unless you just made a game that no one
wanted to play, or that you didn't market at all).
The big games aim largely for numbers of customers. They appeal to the
lowest common denominator in order to appeal to the largest audience
possible. A small commercial mud like mine is never going to be able to
compete if we took the same approach. But there's no need to. The funny
fact is that we small text muds charge WAY more on average than the big
graphical muds. The big muds are not that dissimilar, and so price alone
becomes quite a big thing. I know when EQ went to $10/month (less if you
buy in bulk, I'm told), lots of people in the higher-priced Meridian 59,
for instance, complained and quit, because it was more expensive.
$10/month from a customer. Very hard to make money off that without a lot
of customers. On the other hand, and by way of example, we had a single
customer spend $2000 at an auction of magical items last week. At
$10/month, that's 200 months of playing time. (you think UO/EQ/AC will
have any customers paying continuously for nearly 17 years?) Obviously
that customer is not average, and I realize that the big graphical games
sell tip books, etc (or so I'm told. I don't own one), but hell, that's
$2000 right now, not spread out over the hypothetical 17 years. I really
don't think UO/EQ/AC have particularly intelligent charging models.
Now, I agree that the bar gets raised for startup commercial graphical
muds, and I think that's inevitable, because I think eventually the market
for commercial text games will be killed off. You very well may be right
about graphical muds, largely because graphics good enough to satisfy the
players are going to cost you a lot more than text good enough to satisfy
the players in a text mud. Even here though, I'm not sure. At the minimum,
you're going to need either a) a lot more seed money or b) bring on more
people as partners, who will put in sweat equity for awhile. I may attempt
a start-up graphical commercial mud at some point, but I'm unsure right
now.
--matt
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list