Are you making an RPG, a FPS or a RTS? They have different needs, and different ways of dealing with latency, commands, and sync.

In an RPG, I would not worry about latency at all. 200 ms is nothing. Any MMORPG you play with two computers right next to each other will show different views when the two players try to run right next to each other.

In a RTS, I would make sure that the command delay is long enough to cover round-trip to everyone, and only advance simulation time (different from animation time) when I know everyone is getting the packets.

In an FPS, I would extrapolate the current position of a player based on the previous N input points (or last point/velocity points); then I would figure out where I want to display the player X seconds from now, and where it is displayed now, and move it with speed 1/X towards that position. This will smooth out latency, although it will display people in non-physical locations, especially on high-lag connections.

it is an action / RPG. i want to run it as a persistant world though. that is, i want to host a server and keep it running, like a mini-MMORPG. my goal is to be able to handle 20 people at once with my cable connection acting as a server. i'll have a database of players with their character and other info that people will log on to.

let me give some more details. the game is 2d, in a console RPG style top downish view similar to Final Fantasy 3 or Shadowrun. however, the game will have real-time combat. the game is futuristic so that means guns and grenades and other kinds of projectiles. when you see a person, you click on them / press a button and you are now targetting them. when you press your fire button you will fire your gun, and you will see a bullet fly towards the target. i have it working in single player mode, and im about to start tranferring it to online mode now. i want to be able to handle a decent amount of action, that is bullets and stuff flying around the screen.

im still not sure how to handle movement. i don't think it would work with no correction because of the action nature of the game. i mean, what if on my screen the bullet misses someone but on another persons machine the person was in the way? should i go the FPS way you mention? if so, if you dont mind, could you please explain a little more on how exactly to do it? thanks a lot for anymore help.

EDIT: maybe i could do this: when a bullet is fired, instead of saying "fired at (x,y), targetting (x,y)", couldnt i send "fired from me, targetting him"... then i would only have to send 2 bytes instead of 8 (2 id's rather then 4 coordinates). also, the main advantage of this is since we are all seeing slightly different things, we go along with this "fake" simulation instead of attempting to perfectly sync everyone. do you know what i mean?

my only worry is that "targetting him" deal. does this mean each NPC will need an ID? maybe that is needed anyway though? haven't thought much about NPC's yet.

also, this might be a really stupid idea. i mean, things could get really out of sync and there would be no way to fix it i think...im not sure..

thanks again!

[Edited by - graveyard filla on October 24, 2004 11:48:35 PM]

Quote:

what if on my screen the bullet misses someone but on another persons machine the person was in the way?

In an RPG, you "hit" or you "miss" based on the skill of the character, not the skill of the player. This is the major difference between shooters and RPGs.

Assuming your RPG has a "to hit" percentage (skill roll), then let the server determine whether you actually hit, and let everyone know whether it's a hit or (close) miss.

Thus, I'd click on you to shoot you on the screen, and I'd see the bullet getting fired, and 200 milliseconds later, I either see red blood spurt from you, or I don't -- I hit, or I missed.

Quote:

Original post by hplus0603 Quote: what if on my screen the bullet misses someone but on another persons machine the person was in the way? In an RPG, you "hit" or you "miss" based on the skill of the character, not the skill of the player. This is the major difference between shooters and RPGs. Assuming your RPG has a "to hit" percentage (skill roll), then let the server determine whether you actually hit, and let everyone know whether it's a hit or (close) miss. Thus, I'd click on you to shoot you on the screen, and I'd see the bullet getting fired, and 200 milliseconds later, I either see red blood spurt from you, or I don't -- I hit, or I missed.

This is not really what he was asking.

Because his game state is not perfectly sync'd, it is possible for a character to be simultaneousley at N different locations (where N is the number clients)... At some of those locations, he is in the path of the bullet, and at others he is not... This means that bullets may appear to pass right through some characters...

td

hi everyone,

actually, my game is an action / RPG and i am mixing both forms of what you mentioned. a player will be able to dodge bullets and stuff, but since the game is not birds eye view, there is no free aiming, just auto-aiming (that is click to target, then another to fire, and it automatically fires strait at the target. so i just send "heres where i am, heres where i shot at").

anyway, when a player does hit someone, a skill check will be made. even if you do hit someone, depending on your skills and rand() you might still "miss", that is, the bullet visibly hit , they could "dodge" or something, if you get what i mean.

iaretony is right about the problem though. im in the middle of implementing it though so im not sure how it will turn out.

thanks for anymore help.

hplus,

it says you replied, but i dont see your reply....

@anon, my plan is to group clients togeather based on maps. that is, all clients on the same map are stuck in a group. data that a client sends will only be sent to other clients in their same group. however, im thinking that grouping them by map is too much. maybe i should group on area? however, what if say if someone shoots a bullet, then some guy runs towards my area, hes put in my group, but he never finds out about that bullet... that means that i would have to come up with a system so when someone joined a group, all data they would have received if they had already been in the group is sent to them. however, grouping players by maps wont prevent this either, since when you enter a map, any bullets that are already flying through the air you should be sent. so, hmmm, i guess i won't do it by map then...

also, what is the world state? is this the servers verison of everything, or is the world state just a packet that tells where everything is, that the clients can help build also ?

I replied, but deleted my own reply :-)

If your game is simple, world state can be put in a single packet. If your game is complex, then world state is what your server thinks of the world, and your task is to figure out what packets to send to the client to make the client render something that's as close to the real world state as you want to get.

hi hplus,

i have been working on this world state thing. right now the server keeps track of where all players are. i still need to put in collision detection on the server though for players.

about issuing out the world state. im assuming the server should send out the world state just to make sure everyones in sync (and not cheating). i was going to loop through each client and send him every other clients x/y/ position/velocity with a timestamp, and the players would set the position everytime it got this packet, and i would send it every X milliseconds. however, i think it would add chopiness. im testing it out now and though it works good with 0 ping, im not sure how it will hold up with high ping and other players.

so, since the server is telling me whenver another player moves, can i trust that? or, at regular intervals should i send out the positions of all clients to all clients.

about the player. i dont know if its a good idea for the server to send the player his position and velocity at regular intervals. instead, i was thinking when a player clicked, he would send to the server "this is where im i am, this is where im clicking", and the server would then do checks to make sure its legit. however, im not sure exactly what kind of checks to make....

one last question, does the server have to track all the bullets that are being made too? i think im going to need to anyway though when i partition the players into groups either based on map "zones" or by giving each player a list of "buddies".

thanks for any help.

You might want to have a rotating schedule, where the full state of every object is sent to every client every so often (like, once every 30 seconds or whatever). In the meanwhile, only object changes are sent. That way, everyone will "heal up" even if packets are lost in transit, and there isn't too much bandwidth usage. This works for small-to-medium worlds. For large worlds, you have to spend a lot of effort on the server side just managing what you actually send to clients -- don't go there if you're doing this alone!

Regarding anti-cheating, you want to be much more suspicious of user input than of what you send to users, although sending secret data is a bad idea (like, "which of these 20 scattered chests have the $1,000,000 check in it"). I think letting the user translate from screen to world is OK; the user will then send "here's where I'm at, and here's where I want to go". The actual position of the player will be updated on the server, as well as the client. If the client hacks himself so he can walk through walls, he will see himself walk through walls on his client, but on the server, he won't (when you add collision checks :-), and the client will get the new state of himself every 30 seconds or so.

Also, don't trust the "here's where I'm at" part of the message, only trust the "here's where I want to go" !

You probably want to smooth out updates if the update for the client himself is "close enough" to where the client is actually drawn, to avoid a jump backwards every 30 seconds.