Pixel Walking/Movement

[MasterMind]

Hi there peeps,

I was wondering (after searching quite a bit) how do you change the way characters move/walk?

I would like to have it so they move Pixel per pixel instead? Is it a lot of code that needs to be modified?

Thanks for the help in advance.

[Guest]

Yeah there's quite a few code and core changes to be made to turn existing Eclipse engines to pixel based. If you want to learn a bit more about you could always PM Exception, he's got it working fairly well.

[MasterMind]

Thanks Sekaru, i'll contact him right away!

[Exception]

Rather than reply on the PM, I may as well reply here, so it adds to anybody who cares to reads' knowledge bank. Here's the function, effectively as Spodi taught me.

The way pixel-based movement works is simple in concept, but quite difficult for some to wrap their head around. It works by utilising three packets from the client to server; one to handle starting movement, where the server then sends this flag to all clients on the map to process movement, one to handle stopping movement, where the server sends the flag to all clients to stop processing movement (and, to potentially sync it correctly), and one to handle changing direction.

What I've done, is that I've left the tile-system intact, for the sake of mapping, but I've added a "subtile", a value out of 32 that acts as amatrix of tiles within a single tile. The server NEVER works out anything withtin it, it only synchronises and sends the subtile position.

In terms of handling movement, the server -never- keeps track of players' ongoing movement, it is merely synced from the client, and prediction algorithms can be written to guess where a player'll be at a given point in time. The clients movement is also processed based on about 99% guesswork, and as a result, the higher the latency between the client to server to other clients, the more jumpier the game'll appear. Packets are never sent instantaneously, so, jumping is inevitable, but if syncing is timed right, you can manage this.

In effect, you make the client handle all forms of colission and keep track of movement, the server merely corrects itself infrequently from what is provided by the client, so, it is possible to dupe the server, either by teleporting, or breaking colission. It's an unfortunate flaw, but it can be managed by using aforementioned prediction algorithms to work out if the new area is within range of the previously known position, and you can warp players out of blocked areas if they're standing there for too long (never make it instantaneous, you'll be met with tons of issues.).

As you can see, I've pointed out a lot of flaws, but only because I wish for others to be educated in the matter, and to be aware of them. I'm currently in the process of writing it as fool-proof and preventing as possible, and I expect I'll be done shortly, and I'll most likely open up a test-server to see how it goes.

Anyway, I've tried my best to concisely explain what I can. If anybody wants to correct, suggest, criticise, or question me, go ahead.

[Lavos]

Ugh, Very tedious, just thinking about it makes me dizzy. *Bookmarked*

[DMF]

huh… xD Exception ,ur probably better at posting a tut or pointing them at an existing tut.

[Exception]

Do you really think there is an existing tut on -pixel based movement-? When I've got it working as functional as possible, then 'll post one with a serious warning, but in all honesty, EO2/3 should stay tile-based, for a reason.