[MUD-Dev] Failure of Emulation was EthernalQuest

eric rhea eric at enkanica.com
Thu Jan 9 09:40:16 CET 2003


On Wed, 8 Jan 2003, Valerio Santinelli wrote:
> eric rhea wrote:

>> Faithful emulation is a pipe dream. By Faithful emulation I mean
>> to recreate the sum of the experience of an existing MMOG (or
>> whatever you would like to call it).

> Communities like the one floating around EthernalQuest are hard to
> die just because it's going to be really hard to emulate their
> preferred game.

The communities are difficult to crush, I'll grant you that. Having
a faithful community does not translate into having a working
emulator. What is it about emulation that people find more
attractive than "the real deal"? Why do they linger around these
dead projects? Why don't commercial companies provide these people
an outlet for their energy?

[ Snip Speculation on EQEmu History]

Frank Crowell has appropriately addressed these questions:

  https://www.kanga.nu/archives/MUD-Dev-L/2003Q1/msg00127.php

>> I have a very specific question about these emulators: what is it
>> about emulation that companies really fear? Could it be
>> considered healthy competition? Could it be empirical validation
>> that certain things /could/ happen, and that proof as such would
>> be bad PR?  Conspiracy theory? You bet!

> I think that they're mostly fearing loss of subscriptions if the
> emulator is really good. Why should I pay for playing on the
> official servers if I can play for free on player run servers that
> are capable of emulating the game almost perfectly? (Not yet, but
> that's the goal) It happens that sometime even users support is
> better than the one of commercial games. Mainly because of the
> smaller playerbase and the ratio between GMs and players that
> allows them to answer to support calls efficiently.

This is an unwarranted fear. I've been around the UOX camp, and
elsewhere.  I argue that emulators will never reach the point where
they are equatable or better than their counterpart. (c.f. end of
this email).

It occurs to me that there are two sides to this debate. On one side
are the very few number of people who argue that emulation is a pipe
dream that is incapable of achieving a service on par with the
original. On the other side are people who say "give us time, just a
little more time" while the original service continues to add new
features, and create new problems for the emulator community. It
also reminds me structurally of the OS debates, but comparing an OS
to an aspect of emulation is fallacious.

>> I titled this thread the failure of emulation. I did so because I
>> simply do not see emulation as ever becoming a serious contender
>> for an existing product. Here are my reasons for this.

>>   1. Emulation requires support staff, customer service to get
>>   things running because we are often talking about technical
>>   wizardry, not "click icon, make it go". IRC chats and online
>>   forums tend to be used for this, but since no one bothers to
>>   read the manual (RTFM), the spirit for support often decays
>>   quickly.

> I do not agree. That's not always the case. If you work with your
> community and build good communication channels you can convey
> knowledge to a good percentage of users who are going to support
> other users in the future just because they already know the
> answers to their questions.  If you build forums, documentation
> areas and a good announcements policy, you can overcome most of
> the repetitive problems.

> This is true with Open Source projects, too.

I disagree. People are lazy. People with technical ability even more
so. I'm lazy and have some technical ability, so I should be able to
recognize fellow lazy netizens.

I argue that all online documentation is the equivelent of having a
binder full of important documentation. Anyone who has multiple
binders sitting on their desk, in their office, understands my point
here. (On a side note, is it ethical to ask the cleaning lady to
dust them for you?)

It is far quicker to ask someone your question, than to RTFM.

>>   A person reading the thread might say to themselves, "but there
>>   are only a handful of players who would do this. The community
>>   will support itself."  The community will not support itself
>>   because of the virtues that are supported by that
>>   community. The community is more like a snake. Tame until you
>>   start fumbling around with it.

> Have a look at most of the successful Open Source projects. This
> is not true at all. Have a look at Linux. If your statement ever
> applied to Linux, nobody would have ever used it professionally
> due to lack of support.

I am not seeing the point here. Linux does not attempt to emulate an
existing OS. Comparing Linux to an emulation community doesn't make
any sense to me. If the point is that their are communities that are
supportive, then I agree. There are. You just aren't going to have a
supportive emulation community.

  (For my own sake let's define support as assistance in terms of
  setup, configuration, and troubleshooting the software that
  someone else has developed. The community, for anyone following
  the thread, is the emulation community. Successful we define as
  providing professional support for the software or as completely
  emulation the feature set of an existing product.)

In order for a professional supportive community to arise for
emulation is going to require the birth of a business that caters to
this support, and provides it.

The moment you see that Wrox or O'reilly book entitled "EQ
Emulation", is the moment you also read about that publisher on
slashdot for being sued by sony, EA, Mythic, or what have you. In
short, I argue that the necessary elements for a supportive
community can not emerge in the emulation community because (1) any
professional advance in support is going to be bitten off by a law
suit and (2) the community itself will simply tire of providing
support to people who demand, demand, demand and give nothing in
return: *not even recognition*.

>>   Further, you quickly discover there is a breakdown.

>>     a. Those who support b. Those who make content c. Those who
>>     develop for the pure branch d. Those who, like myself, make
>>     experimental branches

>>   Of these four types of people, only (a) does any
>>   support. Rarely will b,c, or d lend support to anyone other
>>   than their own groups. Why? Motivated self-interest. If I help
>>   someone who is doing something like what I am doing, then it
>>   has greater likelihood of a payoff than helping some newbie
>>   learn how to read the manual. That's my theory, as it is the
>>   only one that I could come up with that makes sense.

> People with strong egos are going to act exactly as you are
> saying. But there's a lot of people that are motivated even if
> giving support does not bring home a cent.

I am not arguing that money has to be involved. I could argue that
it ought to. Or that recognition be involved. But that's missing my
point. My point is that people have greater self-interest to help
only those in their immediate domain, unless they are expecting some
sort of payoff from extending their help (similar to how many
animals are said to work together). The payoff could be recognition,
money, or some other motivational factor (such as number of posts on
a support forum).

People who work for the great payoff in emulation are going to burn
out.  It simply cannot exist within it. It's a lot like saying, "I
ought to go rob some banks to today. One day, people will finally
recognize me as a wonderful being." It just isn't going to happen.

>>   2. The expectation of the players. The link below is a larger
>>   rant (careful of word wrap) that is supported by many other
>>   server ops. A server op is a person who maintains a particular
>>   EQ Emu server.

> Expectation is a bad beast. I agree on this being a problem in a
> first place. But it's something that is going to become less and
> less a problem as time goes by and features start flowing in the
> emu.

This argument comes up again and gain. But is ultimately
defeated. Why is the argument that over time an emulator overcomes
the expectations of players? The answer is below.

>>   3. "We are experiencing technical difficulties at this time."
>>   The Hassle of version checking. Often the emulator does not
>>   support a particular version and unless you have a piece of
>>   software to patch your client to the particular version
>>   supported by your internal server, then you are SOL (and that
>>   doesn't involve a moon, either). Particular hardware support
>>   for the client. What of exploits in the client that can be
>>   enabled in the client? What?  Exploit in the client? Yes, very
>>   much so. One discovered enabled arbitrary code to be executed
>>   after sending a particular sequence to the client. Scary stuff.

> This has been an issue with UO emulators, too. But it's something
> you learn to live with since there's no way around. You know that
> if you're going to emulate the server of a commercial game you're
> bound to its client and whatever the developers at Sony are doing.

Until the company folds and stops supporting their own product,
there is no mechanism for an emulated MMOG to "catchup". Therefore,
there will always be hurdles of expectations and technical
challenges in addition to all of the other factors that we have
discussed.

I argue that emulation is a pipe dream. It can never be
successful. Recall that I had defined successful as either (1)
emulating the complete feature set of an existing product or (2) as
providing professional support.  Professional support will only
exist for emulation if a radical shift occurs in how IP law is
regarded. (A MMOG on a creative license?)  Further, I argue that an
emulator for any commercial MMOG will always fail because (1)
lackluster community support, (2) technical difficulties in the
client and server, (3) "keeping up with the jonses", and (4) because
there are no appropriate rewards available for people in such
communities.


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list