Where the customization of EQEmu Ends

[Cisyouc]

This question has been brought up in the past, but reading a recent thread proposing the addition to mob models in OpenZone it has gotten me thinking. Where does the customization of EQEMu end? In the past Ive only really seen about 4 projects take on the actual modification/addition of zones and models to EverQuest. I think that once you get to the point where you are adding custom mob and weapon models, and custom zones, and running it on a custom EQEMu server, it comes to a point where the EverQuest client is so far out of context from what it was designed to be that its just a hassle and is a step in the wrong direction to make what you intend to make. While building a separate client is an extremely large task, of course, if your team has the ambition to add all this to the EverQuest client, is it too much to assemble a team to make a client you can fully control? Even if it is using EQEMu as a server still, it seems to be that once you replace all the graphics (client-side) and all the content (server-side), using the EverQuest client is now an unnecessary step that shouldn't be taken, for both logic and in recent times legal reasons. When does/should EverQuest Server Emulator customization end and a new MMORPG creation begin?

What are your thoughts on this?

[smogo]

i suppose it's just impossible to set up a team to work on a new client, new art, new content for long enough to get something playable, if ever you do in the end.

Many server ops pretend their server will be different, with new content and design. Customizing what's working now is just what WC described : replacing zones by new ones, and adding more models.

As for the work involved to get a client from scratch ... i've been having a look at it and it takes pretty much effort to get something running. Plus time to create the art. Plus taking a player base accostumbred to a new game/ui. Not to mention re-writting a part of the server.

That's a point, ... as you asked. Humble and personal opinion.

I'll continue working on RPG project(s), client and server, and new models ... but just for the fun of it, as i like to tweak and develop. As a player and server op, i'd just customise what works already.

I'd appreciate more points of view on this, though, thanks for raising the question Cysiouc.

[Damilis]

Personally, I feel that by working with the finer details of the code, learning about network comms, seeing what could be done better with the eq client server comms, textures, meshes, etc, all builds a very good platform for creation of a new MMO.

Just my $0.02

[Dr Zauis]

When does/should EverQuest Server Emulator customization end and a new MMORPG creation begin?

As long as we arte using the original EQ.exe to play then it will be eqemu.

[GeorgeS]

I do not think a new client is necessary. I enjoy playing this emu as it is. What should be fixed is the world game formats and models as well. A whole new game with new graphics and a MMORG client can take years to write - just try to get someone to make animated and textured models is hard enough. By that time eq2 or something else will eventually take the developer's interest.

I will play by my guns and suggest we start by creating support for a better .wld/s3d format...

edit - now I think of it - new .wld format may very well mean a new client is needed - is this right?

GeorgeS

[Windcatcher]

First let me say that I'd like to see this project have its own client. Badly. Extremely badly. A client would let us completely divorce ourselves from the EQ patching cycle and content, as well as any legal entanglements (as long as any names they use are also done away with, like "eq", "erudite", "iksar", etc.). One of the ongoing things I do to OpenZone from time to time is expand support for .XWF files, which is a simple and easily expandable file format that was intended to replace the .WLD format for our own client if one should come about (Daeken and I collaborated on the format for OpenEQ, which never materialized). .XWF only supports zones at the moment, but I intend to expand it to support weapon and creature models in the near future. Getting it to support weapons would be pretty trivial as 90% of what's needed is already in there.

Being in the somewhat unique position as the content guru, I tend to hear from and talk to some rather interesting people in the community (though rarely to the devs ). There's been a lot of talk about writing a cilent in the past year, and you'd be surprised at how few pieces are need to create a client:

- A simple class or two for netcode (reading from and writing to a socket, with a data buffer and methods for an application to drain or fill the buffer). I have something like this that I've been working on for a possible rewrite of ZoneProxy, and it's super-clean, if anyone wants to port it.
- Classes for reading content files (which are a lot easier if you drop .WLD and go with something simpler like .XWF)
- A thread that drains the incoming socket buffer and dispatches messages (that is, handles incoming packets)
- A thread that spins and renders the scene, handling notifications for changes to the scene (e.g. new creature, despawned creature, changes in creature visibility, position, animation, etc.)
- A mutex that makes sure that game data can't be changed by more than one thread at a time
- A 3D engine
- Classes for user interface handling (unless the 3D engine gives you this for free)
- A set of methods that handle packets (e.g. one per packet type)
- A set of methods for creating and sending packets (e.g. one per packet type)
- Miscellaneous setup code (setting up the GUI, loading and saving preferences, etc.)

The devil's in the details, of course, but in terms of what pieces are needed it's not intractable if a number of people work on it. The code for importing .XWF exists and doesn't have to be rewritten (only ported from Delphi, and it's *very* little code), and a handful of coders could probably get a basic client at least logging in within a couple of months. From what I've seen of the server code, most of the work would be in adding support for all of the packet types (e.g. adding a "handleTradeRequest(void *c, int size)" method and corresponding methods for sending appropriate responses). I'm convinced that it's a lot more doable than peope realize, it's just that it needs a handful of developers to take a whack at it.

[sdabbs65]

There was a client made that worked.
I don't know what happened to the Creator,
I was never able to contact him to ask for the source.
it just fell off the earth the way most projects do when people lose interest and have lifes issues at hand.maybe some of the guys from the failed wr.xx project have the source still.all I can find is the exe for it and it only works for 5.7.
but yes it has been done before.

[SiliconeClone]

Been doing alot of searching for the older client code, but most thing's lead to dead links. Unless someone has a mysterious .zip somewhere with it stashed in it, chances are it would need to be done from scratch.

[smogo]

You may ask Daekken for the archives he might have saved. I guess he's not in the mood for developping EQ client at the moment, but might be willing to help.

You may find some tarball of the sources there :
http://www.lekrikidesaoule.perso.ceg...openeq.tar.bz2

I you're willing to give it a try ...

[iamjooish]

Originally Posted by Windcatcher

and you'd be surprised at how few pieces are need to create a client:
- A 3D engine

(a couple days too late responding, bah..)

From my limited knowledge of game developement, I'd wager that last part is your biggest problem, and likewise, the most labor-intensive. IIRC, the vast majority of most game developement budgets (the ones that run into the 7 or 8 digit figures) are spent on programing how the game interperets and renders it's media; it's graphics engine, basicly. As to why or how it's so consuming; time and money wise; I haven't the foggiest.


So unless someone has made a 3d graphics renderer open source and available a la GNU... my 2 coppers goes to trying to play tug-o-war (attrition) with sony over live compatibility, and see who quits first in frustration. (EQ1 is slowly dieing, right?). Certainly, it's better than allocating the mountains of human resources and time to reinvent the wheel with EQemu, and at some point having the team realize it's too much effort involved for a volunteer basis, burn out, lose interest, 'run into' real life issues, find something shinier to invest time in, get a new hobby etc.

Personally, I just want to play that oh-so addictive ORPG with a tight knit band of fellow gamers, experience all the content up to a fully-functional PoP DB (hopefully) on a nonlegit server, whack a few raid mobs without the leveling treadmill, etc. And I wouldn't want an OS client to distract EQemu from that.

[Windcatcher]

OGRE is an LGPL engine in C++. I haven't followed it in a while, but from what I've seen of the earlier versions, it should work well.

[Drake1132]

There are, in fact, several open source 3D engines available... most aren't that spectacular, but OGRE is one of the ones that shows substantial promise. Also, I don't know how the licensing is handled for it so I don't know if it would work, but there is an engine called Torque which for the least expensive license costs something like $300.00 US for the baseline engine plus shaders plus sound handler. There are options... The real issue is not finding options, but finding a GOOD option and implementing it. I would recomend that anyone interested in using an already existant engine take a look at DevMaster.net.

Hope that that helps at least a little somewhere, 'cause I for one would LOVE(!!!!!) to see a new open source client that can be used with the emulator... none of this "the new patch breaks the emulator, do not patch, if you're new to the emulator you're SOL" anymore. It would be beautiful.

Drake

[EDIT] At this point the last couple of posts are no longer about OpenZone and are about OpenEQ and therefore should probably be redirected to the forum for such topics... just a thought

[RangerDown]

Most people I bet aren't even aware those two projects are separate and independent.

[Shadow-Wolf]

Torque is NOT a graphics engine, it is an entire game engine that was developed for Tribes 2. The creators of the engine retained the rights to develop and sell it.