[MUD-Dev2] [DESIGN] Homogenized MMORPG Engines (Was: A rant against Vanguard reviews and rants)
Sean Howard
squidi at squidi.net
Mon Mar 19 10:54:42 CET 2007
"Morris Cox" <morriscox at gmail.com> wrote:
> Casual experimentation of anything computer/Internet related isn't
> likely to be easy. HTML is pretty easy, but you'll need a program (for
> validation) if you want to do XHTML Strict. I don't consider anything
> to do with programming as being easy since you're not allowed to get
> away with errors. You do make an excellent point. Easy to use
> interfaces are a pain to make. The scale of a MMOG (let alone any
> game) makes it all that much harder (a lot more interactions to
> consider).
I think the model we really need to look at are MUDs - there's thousands
of them and have been thousands more since they began. Different themes,
different worlds, different systems. Some of these are stupidly difficult
to modify. I believe DikuMUDs require actually knowing C and making
changes to the actual source code. Some of them, like MUSHes, have built
in scripting languages that are fairly easy to learn, but also sort of
obtuse. Some of the later mudlibs, like MUDOS, is way more complex than it
needs to be. And yet, that hasn't stopped people at all. True story, I
learned C initially so that I could program an lpmud (but I learn things
for all sorts of stupid gaming-related reasons).
I don't think complexity is the problem. But I think the interface is.
Learning how the DikuMUD code works by pouring over thousands of lines -
or learning C in the first place - is difficult. But that's all you have
to do. That's some that one person can do. The goal is within sight at all
times. But a graphical mud, programmers are going to look at the need for
art and just give up, while trying to work with an artist on the internet
is probably going to fail quickly.
I've said it before, but I think low res pixel art is really the way to
go. Much in the same way that learning to mod a program is easier than
building one from scratch, sprite editing is a really easy way to get
halfway decent results, even for a non-program. Seriously, try it. Grab
some sprites of the internet (not mine), load up MS Paint, and go to town.
Turn Mega Man into a cowboy. You'd be suprised how easy it is to do, and
how good it will look afterwards. I have a real problem with people
stealing my pixel art because of this, but I do think it is absolutely the
magic bullet for graphical woes. If an eight year old can turn a Final
Fantasy sprite into a recognizable Dragonball Z character, anyone can.
> I do have a "certain creative imagination"; however, don't ask me to
> do any graphics. :) (Okay, so my "certain creative imagination" tends
> to have quite a geek slant.)
This, more than anything is the problem. Graphics seem like such an
impossibility to non-artists that they avoid it without ever giving it a
go. Luckily, I got into art at a young age when I didn't know better. But
I won't touch 3D art because it seems foreign and strange to me. :)
> Cool that Java has that now. I do wish they would update it so that it
> doesn't knock Vista out of Aero (even temporarily). Agreed that trying
> to use a lot of languages would be a disaster in the making. The point
> I was trying to make is that allowing the use of more than one
> language might lower the "barrier to entry" and make it easier for
> those who don't know the same programming language to collaborate.
Oh, I get it now. You weren't saying that every team member use a
different language, but that it would be possible for the teams to
collectively decide what they wanted to use based on their own
experiences. That makes more sense, but I can still see a babel problem
popping up when the community tries to share code and features. If I make
this really awesome inventory management system in Perl, that team that
used JavaScript exclusively might not be able to incorporate it, learn
from it, or modify it to suit their needs. I guess that is really what the
big push for encapsulation is about (making everything self contained with
interfaces so it doesn't matter), but I think the solution is to be as
open as possible. The only way a community can survive is if they can
easily learn from each other, share, or just plain complain together. :)
--
Sean Howard
More information about the mud-dev2-archive
mailing list