Quote:
|
Originally Posted by Windcatcher
It seems to me that, were this to stand, EQEmu would have to immediately divorce itself from anything SOE...at the very least the content and client, and possibly the protocol as well. With a mature OpenEQ client going to a different protocol would be pretty easy (and probably desirable anyway), but content would be the hardest nut to crack. We're at the point where we can create original zones at will (and I could switch OpenZone to a different export file format in a few days if necessary), so it comes down to mob models and textures. The appeals process will take months but I see no reason not to prepare for the worst anyway. I've wanted to make OpenZone capable of letting people design mob skeletons for a while now, and I think i understand enough of what skeleton animation is all about to start to take a stab at it. If we want a different file format for OpenEQ, however, this might be a good time to start designing one.
I should also point out that the two letters "EQ" should probably go away from anything we do...which is exactly the reason why I called OZ "OpenZone"...to keep it generic.
Thoughts?
|
I've been thinking about this for a while as well. I think that we should use sony's file formats (the new ones exclusively, as we do right now... we can use convertors for the old ones, which gives us another level of legal protection as well, really) simply because they're open-ended and not patent-encumbered. Of course, we can modify the file formats as we see fit since we'll be creating the zone content.
If we choose to completely replace the official EQ client, there are some major roadblocks right now. The primary one is the UI. Without a good UI, or even _mediocre_, the client simply won't take off. I have absolutely no experience in building a 2d UI in OpenGL, so my current implimentation is horrid. I looked around but every open source widget set for OpenGL either sucked or was in C++ (or both heh) so I think building it from scratch is still our best option. Perhaps I was simply going about it the wrong way.
As for protocol, the existing one is not the most optimal design by any means. Their encryption and other means of keeping us out has made for a pretty poor protocol design in essence. I think we should completely redesign the protocol when we get to that point, and I think we should develop a completely new server to go along with it.
If we go with EQEmu for more than the prototype, we will have lots of problems. Too many people have figured things out and just put them in the code without sufficient testing. Since we're designing the protocol, we can do it in a way that's efficient on both ends of the connection, and we will have proper documentation so we're not stumbling blindly to develop the server.
Input on this would be useful.
Thanks.