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

[Sean Howard]

"Craig Huber" <huberc at frontiernet.net> wrote:
> Frankly, I think most of this thread is coming at the problem from the
> wrong perspective.  Is this about generating creativity in terms of
> hacking out code, or about generating creativity in terms of
> designing "game"?

This all comes down to the perfect sphere. Everything you create should
aim for the perfect sphere - nothing poking out, and no dents poking in.
Sometimes, you don't need really powerful features and actually using them
will end up making the rest of your design look inferior, or even take
away from the design itself. And sometime, you don't have the features you
need, leaving big dents and flaws that are difficult to cover up.

Depending on the creativity you are aiming for, different features are
optional or required. It's context dependant, which is one of those
frustrating things about these conversations. Half the people are in
context A and half are in context B, and they just can't imagine why
anybody would do otherwise.

> The creators of Dungeons and Dragons, Monopoly, Texas Hold'em, American
> Rules Football, and/or Yahtzee didn't need to know "modern mainstream
> programming languages" to design and develop apparently interesting and
> engaging _games_.

I argue that you can create an engaging game with a sheet of paper and a
pencil, or with a single button, or without graphics, or using items you
find in your yard. There's never anything you NEED to have if you only
care that the destination is great - but if you care what that destination
is, much less that it is great, then you've got to plan accordingly. It's
top down versus bottom up design. Work with what you have and build to
something, or design something and figure out how to make it happen.

> They just needed to have someone who could
> generate those resources for them at a reasonable price.

In your examples, they all used game pieces and elements that existed
before they made these games. There were already places to find dice or
print books cheaply. That's a large part of WHY those games were made in
the first place.

Likewise, would we have all the MUDs that we do if the MUD software wasn't
created first? Certainly not DragonBall Z MUSH. So, I guess the question
is whether or not amateur MMORPG development fits into this category. If
you build it, will they come? Yes, but only if it is 100% free, easy to
use, and can be used to quickly produce something interesting and unique
in a weekend.

You can do that with text without SQL databases and fancy graphics, but
can you do that with something more complicated? Maybe, but it would be an
effort of designing something that is easily extensible, and largely
optional. And each element you include is one element somebody won't
design for themselves, make each decision about what variety you want to
REMOVE from the equation at the price of accessability.

> A walking animation applied to a basic human model has to have been done
> 10^6 times or more.  Yet, to use most of the toolkits that have been
> mentioned so far, you'll be doing it for the 10^6+1st time.

Okay, really good example. But what shape is that figure? Are we talking
Poser-like, as evidenced by Vanguard or Everquest 2? Anime styled like
Lineage II? Cartoon styled like WoW? What about super deformed, like the
gnomes in World of Warcraft? If I made a MMORPG, the characters would
undoubtedly be three heads high at most.

You've got the character and he walks - but does he run? What kind of
dances does he do? Can hit sit in a chair? Does he swing one sword? What
about two swords? A staff? A ball and chain? Even if you do only provide
the very basic actions, what then? How difficult would it be to add new
ones? Could the average 12 year old add new weapon types? Each thing you
add affects what things will likely be added later, and each thing you
don't add is a thing that most likely won't happen later. So you are
essentially building the game for them, for all the good and bad that
does.

I'm going to be honest right here - I think the only way this would work
is through low res pixel art. I'm serious. I have seen thousands of half
talented teenagers take a Mega Man sprite and edit it into all sorts of
poses, animations, and even characters. Editing a sprite, especially with
limited shading, requires very little talent or ability. Sprite editing
may be the bane of my existence as a pixel artist, but it is absolutely
the best chance a general purpose graphical gamedev library has of
obtaining critical mass.

> It -is- that doing all of that is essentially a distraction (at best)
> from what I really want to be doing...

This is something I've noticed in my life as well. I wanted to be a game
designer, so I learned how to program. Then I learned how to do pixel art.
I became really good at both. I even got a job as a programmer in the game
industry, only to find out that whatever I wanted, it wasn't that. And
now, almost 30, I have all the skills needed to make a professional,
complicate game, and I've never finished even so much as a PacMan clone.

Why? Frankly, I get distracted easily. It's too easy to get distracted
with programming such that you miss the big picture. Plus, one can get
hung up on an art problem and never get past it - wearing too many hats
means meeting too many obstacles, and requiring the experience and
knowledge to defeat them all.

-- 
Sean Howard