[MUD-Dev] Graphical Mud-in-a-box musings
Brian Hook
bwh at wksoftware.com
Thu Jul 5 17:18:30 CEST 2001
Okay, I'm still running with this one.
I can think of three interesting products, each of which may have
issues.
1. "MyMUD"
A package of tools, clip art, and scripts that allows anyone to
create and host a MUD. A tile editor much like NWN (I think), and
allows for first or third person rendering. The package is sold
effectively as a direct competitor to NWN, without the
non-commercial use restriction. If you host an open server, you
must connect/ping the master server to verify you have a legitimate
copy (and, of course, this would be hacked out within hours, but you
gotta try....) Optional "world packs" are made available as a form
of secondary income. No programming APIs are provided. Basically
it's a "fill in the blank" style of MUD.
2. "BuildYourMud.lib"
A package of tools, clip art, and libs that allows a programmer to
build a server and client fairly trivially. Significantly lower
level than "MyMUD" and requires significant development effort to
build. Of course, the big plus is that you have a lot of
flexibility.
3. "MudWorld"
Full service commercial MUD hosting service, including aspects of 1
and 2. Tools, binaries, sample art/scripts/data, etc. are provided.
Billing services are provided with a revenue sharing program.
Member MUDs use the tools to build their unique worlds, and may
optionally charge for usage. Charges can be swept through the
provider, who in turn skims a bit of money off the top before
disbursing it to the MUD operators. Obviously there would be some
logistical issues to sort out (like who is responsible for CS,
hosting, etc.) and there are some analogs to Web hosting/ad revenue
sharing programs which may turn off some. But I think this would be
an interesting model since it would allow the creation of a bunch of
smaller, commercial graphical MUDs that can compete with the "big
boys" through different gameplay styles instead of, say, raw
firepower (Content, technology, etc.). And, alternatively, the
provider could just provide the tools for a fixed fee and allow the
MUD developer to handle their own billing, etc.
I think #3 is an interesting and viable business model, but it would
require a significant up front investment and would entail some
risk. I think #1 would be so low volume as to be unviable, and #2
would be even worse.
Brian Hook
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list