# tweaking movement and collision in 2D RPG

This topic is 5000 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
One option is to make it so that player avatars never collide with each other. That way, you won't have the big troll blocking the tunnel so nobody else can get by. Then you only need to collision test against static stuff, and possibly mobs, which all are much more predictable.

Another option is to run physics at a fixed rate (say, 20 steps per second?) but run rendering as fast as you can, using interpolation for position/orientation of objects you render. That way, you could get the "capping the frame rate" that you want, without having to slow down the visible frame rate.

##### Share on other sites
hi hplus,

so you think its worth it to do the inneficent collision detection, to prevent these errors? also the bigger issue - sending floats over the wire instead of unsigned shorts. to be 100% accurate i must send floats.

also, do you think i should not have the client respond immediately to input? like i said, with high pings, the 'jump' is very noticable. if i had the client wait for a resonpse from the server, this should cut that jump in half at the expense of a slower reaction time and bandwith. with a decent ping though (~100), it looks flawless.

actually, after thinking about it more, this might actually be a bad idea. because then, the client who wants to move must "jump" to make up for lost time.. so, the clients own movement will appear jumpy during high ping.. not sure how well that will work out..

thanks for any more help.

[Edited by - graveyard filla on January 16, 2005 7:01:46 PM]

##### Share on other sites
You don't need to send floats. The trick is that you only ever send "I want to move here" updates. When the user clicks on the screen, you should truncate that to short precision before your program deals with it (even if you convert back to floats to do math). That way, it will be the same on all machines, including the client.

Regarding inefficient collision detection: Yes, I think you should do it server-side. Once the profiler tells you it's too inefficient, you could re-code it using a quad tree, or the sweep-and-prune algorithm. But one thing at a time, and no thing before its time.

##### Share on other sites
so your saying, when a user clicks, i truncate his position to the next possible short integer value? wow, im surprised i didnt think of that =). so when i move, i might appear to slightly jump half of a pixel.. however, i dont think this is very noticable anyway..

im still not sure what to do about the movement system though. im gunna have to test it more with people to see how jumpy it truly is.

thanks again.

##### Share on other sites
oh, and i forgot..

could you please show me what you mean by the "fixed rate" thing? i had tried something like this, but it didnt work out well. basically, i tried doing it like this:

while(game running){   //only update the movement and other logic at best 100 FPS  if(GetTime() - last_time_updated > 10)  {     Update_Characters_And_Stuff();     last_time_updated = GetTime();  }  Update_Network();  Render();}

this didnt work out too well though.. i think im doing something obviously wrong.

##### Share on other sites
One problem might be that if your time elapsed is 20 milliseconds, you won't update characters twice. I'm assuming "updating characters" means actually calculating physics.

Note that, when you render, you should render at a specific point in time. You then render entities at a position which is extrapolated from their last two actually calculated positions. This means that "update characters" turns into "copy current state into saved state; then update current state".

1. 1
2. 2
3. 3
Rutin
14
4. 4
5. 5

• 12
• 12
• 9
• 14
• 10
• ### Forum Statistics

• Total Topics
632655
• Total Posts
3007670
• ### Who's Online (See full list)

There are no registered users currently online

×