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.