Questions about Client implementation details

[Dreadicon]

So, I'm pondering making a custom client. I work on an XML-C# hybrid game engine at my day job, and am thinking of utilizing my experience with Unity 3D to make a client. Specifically a 'thicker' client which is built to do things that require predictive behavior, like WASD and proper pathfinding. Also a better UI and having the client hold onto objects so that one could pan around areas explored to see how they were when last seen (useful for finding trees and bushes, among other things).

Now, my questions: is the server-client messaging protocol documented anywhere? and did anyone ever figure out how to extract resource data for textures, meshes, and animations? If I had those, the client would just be a matter of hammering it out as I've done most of the functional bits before in experiments, prototypes, and for my day job.

I could probably divine the server-client protocol given enough time, but I'd rather not spend the weeks that would take if at all possible. To preempt a question 'why not just use the existing client?', it's because I have a bloodoath vendetta against Java, along with PHP and Perl. May my bones be filled with molten lead rather than write any of them for more than an hour per project. (No offense to users of these languages; I just really, really don't like to use them myself.) Finally, I wanted to say that as a programmer, I hold the developer in high regard; the client code, far as I can tell, is a well-patterned message system, which is a solid model. Sadly, due to my aforementioned disdain for Java, I'm not well versed enough in it's libraries and nuances to quickly track down what I'm after.

[bdew]

There is no documentation for the protocol except the source code of the client, at least that i know of.

If you want to look at it, most of the S->C stuff is in Session class, and C->S is in RemoteUI.

The protocol is pretty simple because the client has very limited idea what it's actually doing. Most of the game logic is server side, including stuff you wouldn't really expect to.

For example when you open your inventory - the client has no idea that it's an inventory. It gets a message to create a widget with some texture, and add some child widgets to it and attach some properties to them. If you click an item the client has no idea what to do with it, it just sees widget #787456 clicked and sends that to the server which then tells him how to display the results.

Also some of the "protocol" is hidden in executable resources, and isn't part of the client source code. e.g. If an item has a quality, the server says "load code resource ui/tt/q/qbuff, attach it to widget #787456 and pass <binary blob> to it" the client then either downloads that resource over HTTP or grabs it from local cache, decodes the code object, loads and executes it. The client has no idea what quality is, it just has some object attached to a widget that can add stuff to the tooltip.

For extrating resources there is LayerUtil, thought it's old/unfinished/buggy and doesn't support everything.

[Dreadicon]

Thanks for the info. I figured the client did pretty much nothing, based on what I saw in the source. Didn't know that the server might even be doing rendering though....that's almost as bad as FF14 when it launched. Super thin client is super thin. Ultimately I think just a few bits from the devs would be sufficient for the protocol, but the resources would be a much bigger issue.

I suppose that until one of the devs offers a little more info, I'll just have to prod at it in my spare time such as it is. That, or maybe just make my own survival MMO, lol. But that's what they all say....

[Paradoxs]

Thanks for the info. I figured the client did pretty much nothing, based on what I saw in the source. Didn't know that the server might even be doing rendering though....that's almost as bad as FF14 when it launched. Super thin client is super thin. Ultimately I think just a few bits from the devs would be sufficient for the protocol, but the resources would be a much bigger issue.

I suppose that until one of the devs offers a little more info, I'll just have to prod at it in my spare time such as it is. That, or maybe just make my own survival MMO, lol. But that's what they all say....

Server cant do rendering that doesnt make sense.

The client gets the map data, and that data is used to do rendering,

For example in ridges theres a statement that checks the vertex of the grid, if the vertex reaches a certain steepness, a ridge is rendered.

Id start by going into the sessions and start tagging different messages to and from client,

then make a console test to see if you can login

once you can do that rebuilding the client piece by piece is just going to be a matter of time and determination

[romovs]

KT did a C# implementation IIRC a while ago. You might want to check his repo for tips.
Why that might be pain in the ass to do you'll probably figure out soon youself.

[shubla]

I dont know if this has anything to do with it but there are some random notes from apxeolog that he once wrote.
I think he has done some research on how client protocol works.

but I'd rather not spend the weeks

You will use a lot of time to re-write the client like this anyway.

[Ysh]

Server cant do rendering that doesnt make sense.

Different usage of word ''rendering.''

[loftar]

The Session class implements the vast majority of the protocol, and I don't think I can document it in text much shorter than it is documented by the code. If you have any specific questions, you're free to ask, of course.

[Paradoxs]

Server cant do rendering that doesnt make sense.

Different usage of word ''rendering.''

Ah, dont know how I missed that with the context applied

[Dreadicon]

Oh, wow. That's some really helpful information everyone!

Id start by going into the sessions and start tagging different messages to and from client,

then make a console test to see if you can login

once you can do that rebuilding the client piece by piece is just going to be a matter of time and determination

That's a good place to start. After more study, will probably do just that.

KT did a C# implementation IIRC a while ago. You might want to check his repo for tips.
Why that might be pain in the ass to do you'll probably figure out soon youself.

Aha! Sweet! This should help a ton. I'm curious how much the overall server/client comms have changes since then. It looks like the main reason he gave up was the nitty-gritty of implementation; adding all the widgets and linking them up properly. Unity will make that very easy. Way easier than my day job, which works closer to how KT was doing it.

I dont know if this has anything to do with it but there are some random notes from apxeolog that he once wrote.
I think he has done some research on how client protocol works.
...
You will use a lot of time to re-write the client like this anyway.

Thanks for that; I'll try to match it up with what I find digging around in sessions and KT's repo. Re: time. What I meant was it would take weeks to decipher what is going on BEFORE I even start on actual implementation. With enough resources and some guidance, I was hoping to condense that early stage down to under a week (irl permitting). Almost there with all or your help!

The Session class implements the vast majority of the protocol, and I don't think I can document it in text much shorter than it is documented by the code. If you have any specific questions, you're free to ask, of course.

Sweet! loftar himself, can't get much better than that. Only specific questions for now would be concerning the resource files; what finalized format are they in? Where are they stored? Just want to know my efforts won't be for naught as ultimately even if I can replicate the UI and functionality, without the resources it's pretty pointless. So, what are/aren't you willing to do with regards to them? would you post them on a repo? Is it required that they come from the server only? I'm presently not even sure that the client has them unto itself, or if it pulls most/all of them from the server as needed.

Thanks everyone! This community may be small, but it's pretty darn loyal and active, I'll give it that. Hope my efforts bear fruit and make HnH better for all in return.