|
||
|
GP Mailing List
ATXGPSIG List
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [gameprogrammer] Re: pingin'
Instead of having the client tell the server "hey i want to move
here", it would probably be better to tell the server "hey i want to
move left", because if the client tells the server specific
coordinates to move to, people could hack their client and make it
send whatever coordinates they want to have "teleport hacks" (:
On 1/23/08, Jake Briggs <jakbri@coretech.co.nz> wrote:
>
>
> Yasser Gonzalez Soto wrote:
> > I want make an application (c++ or delphi) that pings to an ip
> > address. Is reponse add a "IP actived" message to a list
>
> Well you could just try to open a socket on the remote IP.... Depends
> what libraries you are using.
>
> >
> >
> > second:
> > In a multiplayer LAN game using tcp/ip, I want make a game where,
> > each time an user connects to the server, creates a sprite on the
> > room. So, when a player on his own PC moves his character screen
> > moves, on the other PC else, user player moves. Could you give a clue
>
> Well here is how I'd do it, in the simplest way I can think :
>
> 1: You would have the server remember the state (x and y position, for
> example) of each client.
> 2: The client would request a move - "Hey server, I want to move to x
> position,y position".
> 3: The server would validate the request, checking that the move is
> valid based on the clients previous location. If it is, the server
> updates its internal state.
> 4: The server updates each client periodically with the state of all the
> clients.
>
> So we have a situation where each client puts sprites (including its
> own) wherever the server tells it to. If a client gets a key press from
> the user that means "move up 1 pixel", it doesn't move its own sprite -
> it tells the server that it wants to move its own sprite up one pixel.
> The client only moves sprites when the server tells it too. The client
> doesn't change the state of the game (it doesn't change the position of
> sprites) unless told to by the server. Deferring to the server this way
> keeps things nice and tidy, since you have separated the
> responsibilities of the client and server cleanly - they won't step on
> each others toes.
>
> There are probably about 100 ways to do this though, and this way will
> have issues that need to be worked around later. For example, if ping
> time (lag) is high, the user will notice a lag when moving. They hit the
> "up" button and half to wait half a second to see their sprite move. A
> way to work around this specific issue is to implement client-side
> prediction. This means that the client does move its own sprite (and
> possibly other players sprites) to keeps things looking good to the
> user, but will still use the servers version of the game state as the
> official state placing the sprites where the server thinks they should be.
>
> Right gameprogrammer mailing list, I expect my little scheme to be
> ripped apart :)
>
> --
> Jacob Briggs
> Systems Engineer
>
> Core Technology Limited
> Level 1, NZX Centre
> 11 Cable Street
> Wellington
> Phone +64 4 801 2252
>
> --
>
> object doAnythingConceivable(string whatToDo, object whatToDoItWith) { .....
>
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
|
|