[MUD-Dev2] [DESIGN] Homogenized MMORPG Engines (Was: A rant against Vanguard reviews and rants)

[Morris Cox]

On 3/16/07, Sean Howard <squidi at squidi.net> wrote:
>
> "Morris Cox" <morriscox at gmail.com> wrote:
> 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 once tried modifying a DikuMUD for about 10 minutes. No thanks. I
haven't done MUSHcode in years, yet I still remember some of the
commands. (@lock/use me=me&!me) I was unable to create a "battlesuit"
that could do various (non-destructive) things. I did try using a MUD
(LPC and Lima) and learned more from that than taking a class.

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

No argument here. The thing is, what can be done to improve this
situation? The beauty of things like XAML or XML in general is that
the structure lets you separate presentation and content. Granted,
that's harder to do in a game, but I feel that the concept is
important. Things like a paperdoll/base image for an object/mob and
then only having to define the differences should reduce the effort
needed.

> 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'll put it on my (way too long) to-do list. I looked at them years
ago but couldn't get the hang of it. I have failed at pretty much any
graphics program except for fractals (who could mess that up?).
Actually (and ironically), I have hope for raytracing as it seems more
comfortable to me.

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

I've given it a go. I just can't make the transition from my mind to
the screen (or paper). It's like outgoing dyslexia.

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

I see what you mean, but look at web services. You can "mix and match"
ala mashups or do your own. You might end up with a SOA (Service
Oriented Architecture) which can be bulky, awkward, and difficult to
manage, but it can also open up new frontiers such as interlinking
with other games and virtual worlds (such as my concept of a Massive
Entertainment/Educational Online World or MEOW).
-- 
Morris Cox