[MUD-Dev] Failure of Emulation was EthernalQuest

eric rhea eric at enkanica.com
Fri Jan 3 09:20:27 CET 2003


On Wed, 1 Jan 2003, Valerio Santinelli wrote:

> I can't recall anyone talking about EthernalQuest, the EverQuest
> unofficial server emulator (http://www.ethernalquest.com/).  As of
> now the v0.6.x serie is becoming playable and the first servers
> are popping up around the world. I wonder how Sony is going to
> react to this trend that is going to be much similar to the one
> rised with UO.

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

While it may not be true now, the "EQ Emu" team was working on their
own product. Theirs was light years head of anything that could be
done with EthernalQuest. This would be about a year or so ago. I
spent some time with the emulator, mostly out of spite to prove to
myself and other underground members of the EQ community that, in
fact, certain things could be done, but that something at Sony
prevented them from happening.

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!

For instance, I was able to implement a very large number of
features using the EQEmu source that the game that we love to hate
(aka EverQuest) simply never bothered with. I'll leave it up to you
to decide why these particular features were never seen on EQ Live
(non emulated everquest):

  - Mob procreation where two mobs create offspring, etc.

  - Specific mob factories

  - Spell casting doors

  - Player owned housing

  - Seige warfare (player's could "own" towns and have armies)

  - Herd-like AI

  - Mob Hunger

  - Flying boats

  - Naval Warfare

  - ALICE integration

  - Merchants that barter with one another in zone on /auct

  - Servant and Master relations (multiple servants to a master)

  - Donations for Servants and Masters

  - And a dozen or so small minor things that I won't bother to
  mention (e.g., Cascading hate decay)

I spent about five months implementing the above, during 1-2 hour
breaks at night. The emulator code base was a sinch to work with. My
posts on their forums should still be archived by the data holders,
but sadly I believe that the group fell prey to infighting. I have,
however, kept a backup of most of my work. You can read about it
here:

  http://www.enkanica.com/index.php?story=data/eqemu/About.txt

Screenshots here:

  http://www.enkanica.com/index.php?story=data/eqemu/Screenshots.txt

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.

  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.

  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.

  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.

    http://www.enkanica.com/index.php?story=data/eqemu/Threads/ObservationsByAServerOp/Observations.txt

  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.

I'll end here. Why do companies fear emulation, and why do aspects
of the community bother with it at all? I don't know why companies
fear emulation, as I had said earlier, that is a question that looms
out there to be pondered. I would argue that the community bothers
at all with emulation because they want to (1) implement aspects of
the game that they feel would make it more fun, (2) do something
better with a product that they enjoy, (3) demonstrate their
technical ability to other hackers (similar to the security
industry), or (4) just have felt violated by the parent company and
hope to still be able to play a game that they enjoy, only without
the continuing violations of said company. But, it is a waste of
energy for so little payoff: managing expectations and providing
support for an emulator community are hard.

Eric `Malevolent' Rhea

_______________________________________________
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