Offline play

[jorb]

After reading source ocde of client I must admit that this is very bad style of coding. No comments, names of variables are like aliens or chineses language... ugh... Total mess.
Trying to figure out hot to put together those sprites for character animation. Any hint which class hold this?

I have never yet seen any plan which has not been mended by the observation of those who were much inferior in understanding to the person who took the lead in the business.

[Butko]

Great hint ty!

[Potjeh]

TBH Loftar does seem a bit averse to commenting his code, judging by a cursory glance at the client's source. And his variable names could be a bit more descriptive. And in camelCase

[sabinati]

camelCase and commenting are crutches used by the weak

[mvgulik]

camelCase and commenting are crutches used by the weak

And by those that like others to be able to read, use or maintain there code.

Neither case applies here of course ... yet.

[loftar]

Trying to figure out hot to put together those sprites for character animation. Any hint which class hold this?

That would be the haven.Layered class. However, the actual information it receives comes from the server.

After reading source ocde of client I must admit that this is very bad style of coding. No comments, names of variables are like aliens or chineses language... ugh... Total mess.

Heh, I feel I must respond to this. :)

I think those long, descriptive variable names that are so common in Java programs cause more trouble than relief. When I read code, I read code, not English, and variable names are merely symbolic; they are references to nodes in the dataflow graph to me, and as such their primary quality is distinguishability, not descriptiveness. (Many variables, being merely the dataflow tags that they are, have no properly defined semantic that can be described anyway.) Long variable names make it harder, I think, to parse the actual structure of the dataflow graph, since they outcompete the structural components of the text, such as operators and groupings, for screenspace and, more importantly, locality.

More important, then, I believe it is to structure the code to properly correspond to the intended semantics of the algorithm it represents. Admittedly, however, that is very hard to do in Java (because Java sucks in many ways, the descriptions of which are beyond the proper scope of this comment), so the client code is quite a bit ugly in many places, but not quite in the way you describe. I would have much rather written the client in another language, but I badly wanted the Internet distributability which is Java's foremost quality.

As for comments, I don't really think it can be motivated for me to waste time in commenting code that I really only ever intended myself to read. ;)

[sabinati]

camelCase and commenting are crutches used by the weak

And by those that like others to be able to read, use or maintain there code.

Neither case applies here of course ... yet.

by those that like the weak to be able to read, use or maintain their code

[Butko]

Trying to figure out hot to put together those sprites for character animation. Any hint which class hold this?

That would be the haven.Layered class. However, the actual information it receives comes from the server.

WTB server source code
EDIT: well photoshop skills on the way...

[Butko]

Ok you said that all calculations are made on server side... so every time I move my character all calculations are made there and send to my client everytime? ZOMG man this is bad. Things like that should be made on client side. Server should only give position for one part (probably legs) and everything else should be calculated on client side depending on legs position. That would reduce some trafic between client and server.

On old server I had some thoughts that server may not be optimised or there is too much done on server side instead on client side. now I see that I was right.
So that means that all location calculations for every graphical object, window, button,... is done on server side?

[Butko]

So here are extracted parts from original:
When I extracted every piece was in seperate file, so that means I got 8 files, for head, torso, legs, and each arm. 8 files one picture for each direction.

I merged those files to not have too many of them and for easier loading in my project.

I made some optimisation of mine in paintshop:
Now I have only one file for a male with idle arms. In H&H client we have 40 files.
If I'm not mistaken (I don't have a lot of knowledge aboiut openGL and that stuff), loading a lot of small files is slower for rendering than loading one bigger file.
Ofc if original client would use sprites like that there would be no need for server calculation for each part and some ppl would get probably more FPS.

What is your thoughts devs?