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

[Craig Huber]

"Sean Howard" <squidi at squidi.net> wrote:
>
> 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.
>
Agreed.  Half of the intent of my little rant was really "ok, what are 
people really aiming at here?"... a question that seems meaningful to me 
both within the thread itself, and amongst the various engine developers out 
there in general.

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

Very true.  I've done this quite a bit with my own little musings... cut 
entire packs of 3x5 notecards in half to create cards with which to play out 
combat concepts, a cribbage board in the middle of the table to track 
"ticks", poker chips to represent status scores, etc.  Cumbersome, but it 
can help.  Eventually, you do need to work your way over to the target 
venue, though.

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

It has generally been my impression, with at least a few of the engines out 
there, that the "easily extensible, largely optional" perspective was what 
they were shooting for.  I understand that there is a tradeoff, believe 
me... I actually was a dev on a project back in the early 90s where we 
created just such a toolkit-like system for "information lines", allowing 
admins at newspapers, TV stations, and the like to largely define their own 
call flows and categories, to create custom surveys, contests, rearrange 
information from feeds in multiple ways, and so on.

Even for something that simple, it was a bear to create something 
sufficiently robust to do everything everyone wanted to try, yet keep it 
relatively simple.  It was, in the end, only a qualified success: many 
admins decided they had other things they wanted to do, and simply 
contracted with us to design their little sub-applications anyway.  (From a 
strictly business standpoint, I suppose that was the best of both 
worlds...but I was rather disappointed.)  The ones that took it and ran with 
it, tho, ended up creating some call apps we never would have thought of in 
a million years...

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.  People driven 
to do this type of creative experimentation in the first place, in this 
arena in the second place, will be willing to part with a few bucks in the 
third place... 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...

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

While I fully agree that people will be looking to pursue multiple art 
styles, I don't think most would find it unreasonable to receive a certain 
base set of models as part of the initial purchase, as long as the ability 
to purchase/contract for/create your own models and animations was also 
included.  I'm not saying lock the artists and programmers out of the 
process... I'm just saying, don't make them reinvent the wheel each time.

A toolkit like this needs to positively dedicate itself to pumping out 
resources, or at least strongly encourage sharing of resources between 
players.  (It should be a subscription, not a purchase, IMO..."resource pack 
of the month?"... credits, earned and spent?)  Second Life flexibility, 
crossbred with a game-centric or at least game-friendly infrastructure, with 
centralized hosting optional... I'm actually kind of hoping this is where 
Areae is heading, at least in part (crosses fingers).

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

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.

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?

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

For me, it's really a matter of having time and energy (at the same time, 
preferably).  We all have the rest of our lives to attend to, our various 
commitments to our circle of friends and society to fulfill, after all.

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 guess distraction is as good a word as any to describe 
it, after all.  In the end, being able to focus on the primary goal would be 
helpful, no matter the reason.

Craig