State of Repository

[NullSoldier]

Hello, I just recently found this project and have been playing with a few friends. While we've been enjoying ourselves quiet a bit we've all noticed a few things that generally bug us all. For instance, the movement system is very unfriendly to users. It's the opposite of a good user experience. Good user experience dictates that when you click a location, your character will navigate to it's destination using a path finding algorithm and not linearly interpolate stupidly running into every object in it's path forcing you to be stuck into various objects. This really bugs me as a developer because it would be so easy to avoid this. I dug into the repository and to my horrification all it does is use a linear interpolation of two points for movement. (LinMove.java) There's no logic at all to the movement code. I'm probably going to take it upon myself to write a new movement system which creates multiple LinMove commands calculated by a path finding algorithm so I can create a RelayMove system.

However that's not really the issue I've had. After looking through the repository I found some of the most cryptic code imaginable. I must advocate that as developers you strive to make more easily readable and debuggable code. I'm not insulting the quality of code however the memory address space is more than a single byte I assure you. Can anyone really tell me what any of the following variables even do? s, t, c, a, da, dt? Seriously...

Anyway, if I decide to write some code I'll have to create a patch and submit it for review. There's definitely some other things that I want to fix as well... like adding a resolution drop down box to the options screen. Happy coding.

[Serg]

s = speed
t = time
c = ???
a = acceleration
da = delta acceleration (rate of change of the acceleration)
dt = delta time (rate of change of time)

Come on man, you claim to want to program, but you can't figure out THAT?

[KoE]

First off, don't bother, they don't take outside help.

Second off, loftar seems to hate this sort of thing and possibly retooling things in general. (You would be surprised at how long it took pathfinding for animals to get in the game.)

Third off, c is the speed of light, duh.

[Granger]

Anyway, if I decide to write some code I'll have to create a patch and submit it for review. There's definitely some other things that I want to fix as well... like adding a resolution drop down box to the options screen. Happy coding.

Gilbertus is the most used client, so adding client-side pathfinding to it would give most benefit to all of us.
Plus the screen resolution thingy is already fixed there (you can simply resize the window).

[flaw]

Gilbertus is the most used client

Highly doubtful.

[loftar]

The main reason for LinMove being hard to figure out isn't so much the variable names, but the model it reflects. The information the client receives is the starting and target coordinates of the movement, and the number of server-side cycles that it will take the object to get from the start to the target. It's less than obvious that the client deals with server-side cycles at this point, but it's the method that gives the highest precision, since updates can contain the exact current cycle since the start of the movement.

Either way, you can see that reflected in the getc() function of LinMove; dx and dy is obviously the difference (delta) in position between start and target, and them being multiplied by a (which ranges from 0.0 to 1.0) to yield the actual coordinate, should be a hint that a is the amount of movement completed.

If you're complaining about short variables names in general, I would refer you to this post. ;)

Either way, I doubt you're much helped by looking at the linear interpolation. Since the actual movement happens on the server anyway, you can't modify it there. LinMove only reflects what happens authoritatively on the server. If you wanted to implement client-side pathfinding, you would rather have to send move commands along the path in series. And yes, I know it should be done server-side.

[Oddity]

Gilbertus is the most used client

Highly doubtful.

Why do you say that?

[saltmummy626]

I would refer you to this post.

*scratches head* wow uh, That post was met with such hostility that I thought it should just die, so I left it alone... I see people talked in that thread a bit before it (hopefully) went away forever.

back on topic though, path finding would be nice, make running from animals faster but... I don't know why but I like the movement of characters the way it is.

[loftar]

I would refer you to this post. ;)

*scratches head* wow uh, That post was met with such hostility that I thought it should just die, so I left it alone...

I meant my post in that thread, not the thread as such.

back on topic though, path finding would be nice, make running from animals faster but... I don't know why but I like the movement of characters the way it is.

I like the current character movement in that it doesn't do unexpected things. If every action had pathfinding, you might find that you click on an oven that happens to be past a closed palisade, have swimming on, and your character takes the route through the deep end of the nearby lake while you aren't watching...

If pathfinding is automated for characters then I, for one, would like it to be a rather modest version that just avoids corners and other such simple things.

[Granger]

I like the current character movement in that it doesn't do unexpected things. If every action had pathfinding, you might find that you click on an oven that happens to be past a closed palisade, have swimming on, and your character takes the route through the deep end of the nearby lake while you aren't watching...

Yea, that would be bad. Reminds me of original C&C where the harvester always took the route through the enemy base...

If pathfinding is automated for characters then I, for one, would like it to be a rather modest version that just avoids corners and other such simple things.

It would be helpful if the pathfinding would be able to divert 1-2 tiles (max) from linear movement path to just avoid collisions with stuff in the way.
Should also give a speedy algorythm since the search space is smaller...