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

[Sean Howard]

"Craig Huber" <huberc at frontiernet.net> wrote:
> I don't think it needs to be 100% free.  Price will determine the size of
> the market, true: this isn't exactly a "must-have" commodity.

It depends on what your focus is. If you just want to make money, you
create a really high end, robust system that you license out to major
developers to make their own MMORPGs. If you want to have a huge amateur
adoption rate to introduce as many new ideas into the system as possible,
you'll want to make it free.

It's been my experience that the people who have the most time and
inclination to make their own MMORPG in their spare time are teenagers.
With a life and family, I decide which games I can play by how far apart
the save points are. I'd do it with what little time I had because I think
it would be cool to do, but these guys are looking to be in the game
industry. They have something to prove to each other, their friends, their
community, and to future employers. These are the guys who are going to
use such a system and use it best.

> they are already regularly putting $40-50 down, and paying
> $15/mo or so, just to feel vaguely unfulfilled by whatever the latest
> first-tier MMO happens to be, after all...

There's a difference between buying a completed product and buying a tool
you may or may not use. Every project I start seems to require a new tool,
but I finish so few of my projects that it would be dumb to purchase all
these couple hundred dollar tools, much less spend the time and effort to
learn them. I've had Adobe Illustrator on my harddrive for years through
the Adobe Creative Suite, but I don't have clue one how to use it and
probably never will - but I've loaded it up a few times to play around in
it. I wouldn't have it if it weren't part of the suite. I wouldn't buy it
individually. I wouldn't even bother trying it if I had to face down a
huge cost eventually.

> I agree it's far easier with low-res pixel art.  That's actually what I'm
> doing right now, with my own various "test of concept" apps.  Even I can
> create and modify sprites relatively quickly and come up with something
> that doesn't have me cringing with disgust as I look at it... and that's
> saying something.

Exactly my point. Pixel art is somewhat difficult to do well, but stupidly
easy to mod. At least for the basic level of use for a tool like this, one
should be considering modding to be the primarily focus of interaction and
creation.

> My own concerns with going too far down that road are 1) differences in
> 2D interface vs. 3D, will it cause adoption of a mechanic that works
> fine in 2D but bombs in 3D due to interface issues; and 2) is gathering
> a sizable and appropriate test group, if/when that ever becomes
> desireable, even going to be possible with 2D graphics, especially since
> what I'm working on is a "hard-core" system of game mechanics?

If a game is attractive, it doesn't matter if it is 2D or 3D. I know
that's not what the general belief is, but being 2D didn't hurt Symphony
of the Night from achieving success... or Diablo II. Likewise, 2D games
are created for portable game systems all the time and nobody complains.
It comes from a couple places, but not the 2D itself. For instance, Sony
wanted to differentiate itself from the Saturn, so they placed a premium
on 3D games over 2D ones in an effort to seem more "next-gen" than the
Saturn. It wasn't that 2D sucked, but that 3D had a bigger wow factor by
being newer. That's largely where the hardcore anti-2D thing came from,
but if it is still going on today, it's not as strong as it used to be and
shouldn't act as any real barrier in practice.

As for the interface thing, I'm not sure what you are getting at. While I
can think of plenty of mechanics that work in 3D but not 2D, I can't think
of any 2D mechanics that could not be easily moved into the 3rd dimension.

> Having actual substantial blocks of time is also a challenge: while I can
> pump out an email or a blog post in 15-20 minutes, weaving through
> thousands of lines of code, or working on an 3D model takes me a bit
> longer to really get productive.

I'm the same way, except I'm not. I mean, I can program just as fast or
even faster than I can type a complex English sentence. If I sat down with
only 30 minutes to do something in Java, I'd get tons done. The problem
comes not from the time taken but from the unknown stopping point. If I
sit down knowing I only have 30 minutes, I'll know not to start on problem
#16 at 28 minutes in. But if my daughter could wake up from her nap at any
second and throw LEGOs at me, I've got to be wary that I may have to stop
at literally a moments notice.

You shouldn't stop programming in the middle of procedure - always quit
when the code compiles and runs. Code doesn't break down as easily
digestable bits like an email does. I know that if I have to stop writing
this, I can save a draft and return to it, even in mid-sentence. I can
quickly read the text before it to figure out where I was, and even if I
lose my train of though, it is easy enough to delete a few sentences and
start over.

I usually end up, on some days, having an hour of time, but I almost never
have the certainty that I'll get the whole thing. I can look up and see
how much time has passed, but never predict how much I'll have in the
future. What this has to do with the conversation eludes me, but it was
something I realized reading your post, and now that I've recognized it,
maybe I can do something to adapt to it?

-- 
Sean Howard