[MUD-Dev] Libs for 3D Client/Servers

[Brian Hook]

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 ;)

Open Source/Commercial/Free:

  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
  too.

Tools:

  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
  effectively.

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.

Language:

  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. =)

Client Portability:

  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
  wasted.

Server Portability:

  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.

Assets:

  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
  anywhere else.

Conclusion:

  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?

Brian Hook

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev