[MUD-Dev] Libs for 3D Client/Servers
bwh at wksoftware.com
Tue Jul 3 15:23:57 New Zealand Standard Time 2001
I'll try to clarify a bit what I'm talking about. Note: I'm not
really thinking of doing anything like this, but I was curious if
there was, in fact, a market for such a package. This came up in a
conversation between myself and a gaming Web site manager, and we
were talking about the industry in general and what people wanted,
etc. I mean, I'd LOVE to do something like this and I'm pretty
confident that if I tried to avoid the very large scale issues that
MMOGs have to deal with I could, but that would require a
significant time commitment on my part with no associated income.
Hey, if someone wants to bankroll it, talk to me ;)
I tend to be rather wary of open source projects. I'm fully aware
of their benefits, but just using my own point of view (unemployed
game developer =) ), some form of sustainable income is more than
a luxury, it's a necessity if you want continuity and a reasonable
likelihood of attracting top talent to the project. As a result,
I'm leery about the overall quality (and odds of completion) of
any significantly large, unfunded open source initiative.
Obviously there are some well known success stories, and open
source itself isn't doesn't necessarily mean "doing it for free".
Of course, there's the classic "if it's free, you don't make
money" vs. "if it's not free, your market can't afford it" problem
High-quality tools are absolutely vital to quickly making and
editing a world, and unfortunately this is often overlooked
because of time constraints, programmer disdain for tool work, or
conflicting requirements as stated by users, management,
developers, and artists. This is often the biggest stumbling
block to getting high quality tools in place - too many cooks make
a very unfocused, mish-mash of tool requirements, often resulting
in a plethora of poorly defined tools that don't interoperate
Libs or Lib + Sample Game:
I would imagine to make it really interesting that you'd have to
provide a sample set of art, scripts, etc. to make the game go.
The traditional engine licensees such as Epic, id and Monolith
provide full source code to one of their games as part of the
engine license -- this verifies that the stuff actually works and
isn't a bunch of untested black box routines.
So, for example, you would get all the code necessary to build
your own game, and along with it you'd get a small, low-budget
Diablo/PSO style game with a couple zones.
C w/ C++ headers. I'm sufficiently pissed at C++ that I'm now
ready to just go back to ANSI C and be happy. =)
This is very, very tricky. Getting portability with 3D graphics
is a royal pain in the ass, even between driver revs of the same
video card on one platform! Not to mention endianess differences,
compiler differences, etc. I've worked around this before, and
it's not impossible, but it's difficult to stay disciplined with
it when you don't have all the different target platforms
available to constantly sanity check your code as you go along.
For the hobbyist market you can aim for robustness and speed --
lower the bar somewhat -- instead of trying to take advantage of
the latest and greatest. The odds of running across a wide range
of hardware are much higher if you stay away from the more
esoteric features out there (pixel shaders, vertex shaders, vertex
array range, radical multitexture implementations, register
combiners, stencil/dst alpha ), but then you run the risk of
alienating users that gotta have bump mapped, dynamic
lights/shadows w/ specular otherwise their l337 GeForce3 is
I'm not in tune with the MUD market, so this is just conjecture on
my part. If you're targeting the "prosumer" market, then a
Windows based server probably makes the most sense. If you're
targeting real businesses (but not necessarily huge ones), you
would probably want to support *ix and Windows solutions. There
has been some discussion here in the past about how the two
architectures have quite radically different performance
characteristics with regards to sockets and threads, so I'm not
sure how this would be resolved (other than to abstract it to a
very high level).
If the scope of the package was limited to several hundred users,
I would imagine that it would be significantly easier to develop.
Once again, I think this is likely to be the biggest problem.
Even if a small developer was handed the basic tools necessary to
accomplish this task - MAX/Maya, Photoshop, C/C++ libraries,
etc. -- they would still have to create huge amounts of stock
assets. Theoretically the tool set could also provide generic
building block assets (rock textures, etc.) but these would
probably be of the same quality as free assets you can download
I think if the sights were set modestly enough -- a few hundred
users, "good enough" graphics, basic portability, good tools --
that this would be a very feasible project for three or four
people in a 12 month timeframe. The question is whether it's
economically viable for those people, or if there was even a real
market. If you're a "big developer" you're going to roll your own
solution or purchase a bigger package like LithWorlds. If you're
a "small developer" you may find yourself bandwidth limited even
if all the tools are handed to you. You may not even be able to
afford the server and network bandwidth.
So it could just be a product that's cool, but with no real market.
Has anyone looked at the available libs that try to supply this (A4
and WorldForge)? Are they complete enough to use, and if so, are
they viable? If they haven't achieved success, is there a reason?
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev