View Single Post
  #9  
Old 07-29-2007, 01:01 PM
Windcatcher
Demi-God
 
Join Date: Jan 2002
Posts: 1,175
Default

Okay, current status. First, let me speak toward the people are very kindly testing this for me. Aside from fixing a couple of crash bugs I haven't changed the functionality of the client lately, but underneath it has undergone a MAJOR refactoring. Part of the reason for this involves licensing: SC had some GPL code in it that would otherwise be fine if I was open-sourcing it, but since Doodman and company want me to keep it closed-source all that stuff had to go. The only real casualty from a functionality standpoint was the loss of .XMI music capability, but since we don't have any of our own .XMI music anyway that's not all that big a loss. I had to move the OGRE code that I was using to read the keyboard out to a DLL, and when the client is released that will be open-sourced. Another major difficulty was the fact that I have to use a minimal amount of code from EQEmu, because SC of course has to interoperate with it. Doodman and FNW are aware of the two pieces it's using and I'm awaiting direction in that area. In my opinion, from a design-cleanliness standpoint one of those pieces has no place in any client, but I need a couple of packets to be added to the protocol to properly do away with it.

A benefit of the refactoring, though, is that later releases of SC will be WAY more agnostic when it comes to particular EQEmu server versions. Some of the problems I'm reading about aren't really problems with the client per se but the 0.5.5 server I distributed for testing. SC can talk to several EQEmu versions between 0.5.5 and 0.6.0, but there is a separate effort going on to allow it to talk to 0.7.0. This will probably take quite some time as I need someone to write a DLL for me (whistles innocently), but internally at least, SC should be much more able to talk to later revisions when the DLL eventually exists.

As far as development goes, I will definitely have to release the source to someone, as OpenZone itself is so much of a handful that I'm overwhelmed. SC is the type of project that demands a dev team, but as it's based on OpenZone's code that team will have to know something about Delphi (and have it, of course). Unfortunately, SC will probably have to remain closed source as well, as someone with a compiler could find all kinds of ways to cheat otherwise.

So what's planned for the future? I first want to get OpenZone 7.7 out the door, including somewhere between one and three mob models (definitely an orc, and possibly a skeleton or spectre). The thing's been sitting on my hard drive for entirely too long and I want to get it done. For the time being, the models that are available now are the ones that come with OpenZone 7.6, though not all models are exported to all zones. SC does support force-loading, however, so server operators do have some leeway.

I'm not overly concerned about copying the look-and-feel of EQ in terms of the GUI, as Apple lost that particular legal battle ages ago. I'm more concerned about mimicking their game system, and perhaps the client-server protocol might have to be expanded to allow for some game system flexibility (where the server DB would dictate some of the game system particulars). EQ borrows heavily from AD&D so not all that much flexibility is really needed, but at any rate such a thing would require coordination between both the server and the client.

Last edited by Windcatcher; 07-29-2007 at 09:07 PM..
Reply With Quote