<timor.super@[EMAIL PROTECTED]
> wrote in message
news:1179468092.449112.326910@[EMAIL PROTECTED]
> On 18 mai, 06:11, "Jim Langston" <tazmas...@[EMAIL PROTECTED]
> wrote:
>> <timor.su...@[EMAIL PROTECTED]
> wrote in message
>>
>> news:1179340725.032443.117080@[EMAIL PROTECTED]
>>
>>
>>
>> > Hi all,
>>
>> > I'm a developper that knows some things about software programming,
>> > but nothing about game programming.
>>
>> > I would like to know concept of network game programming. books,
>> > articles, ... are welcome
>>
>> > For example, let me know if it's the good strategy :
>>
>> > I would like to create a 2 players game, very simple for beginning.
>> > The purpose is to establish the network engine.
>>
>> > What i want to do, on a screen, 2 players (2 sprites), and each
player
>> > can move his sprite, and each player can see his player and the other
>> > one too.
>>
>> > So, what i've done :
>> > - a server that broadcast the message to the others players (in my
>> > case, to the only one other player)
>> > - 2 clients that :
>> > - can move a sprite when moving pad and send position to the
>> > serveur
>> > - can listen to the server, receving the position and display the
>> > other sprite at the position
>>
>> > I've try something like this, but I encounter a lot of slowness .
>>
>> > My question is : is this the good philosophy ?
>> > I try to send data trough network (wifi capability), but despite the
>> > very little amount of data sended, the game is too slow.
>> > How can real game do with sending many many data during a game ?
>>
>> > Thanks for your answers.
>>
>> Basically, that's how it works. A client sends a message to the server
>> saying, "I'm moving to X,Y,Z". The server checks and makes sure it's a
>> legal move, if so sends the information to all (see note) clients in
the
>> area that player A moved to X,Y,Z.
>>
>> Now, with internet lag the way it is, this can take some time.A ping
time
>> to
>> a game server under 100ms is considered good (for some games). Lower
is
>> better of course. So, client A sends message which takes 100ms (1/10
>> second) to reach the server. The server confirms the move and sends to
>> the
>> client(s) the move. Which takes 100ms to reach them. This is 2/10 of
a
>> second or 1/5 of a second. With this type of movment a player will
seem
>> to
>> jump from place to place.
>>
>> What a lot of games do is some type of prediction or timing. For a 3D
>> game
>> it may be more like client A sends to server I'm moving toward X,Y,Z.
>> Server checks the speed of the character. Sends to clients, Player A
>> moving
>> to X,Y,Z at speed so and so. It may give some timing information (or
>> not).
>> Now, at this points the clients can figure out where player A will be
>> between the 1/5 jumps. It starts at X1,Y1,Z1 going to X2,Y2,Z2 which
>> will
>> take 1 second to get there (or whatever). It can then predict where
that
>> client will be at any given time, and show them there.
>>
>> This can be seen in some games when you see another player move across
>> the
>> screen, then run back to a previous postion. What actually happened
was
>> the
>> client said they were running toward X,Y,Z, the server sent messages
>> saying
>> they were running, then somewhere a lag spike happened. Maybe player
A's
>> computer lagged and had sent the message to stop running, the the
server
>> didnt' get it for a second or two. Or the server to your client lagged
>> out
>> and your client never received the message they stopped running.
>> Eventually
>> the server sends the message that player A is actually at X3,Y3,Z3 and
>> your
>> client says, hmm, I see them way over here, better move them back.
>>
>> You can usually never have each client know exactly where other
>> characters/mobs are at any given millisecond, but you can make it
appear
>> as
>> if the client actually does know.
>>
>> Try a google link for
>> prediction game server client
>> and look at the
>>
results.http://www.google.com/search?hl=en&q=prediction+game+server+client
>> The first hit seems interesting although I didn't read it. Its titled
>> "Latency Compensating Methods in Client/Server In-game Protocol Design
>> and
>> Optimization"http://www.resourcecode.de/stuff/clientsideprediction.pdf
>
> thanks all for your answers ... it's seems to be more difficult than
> want i thought.
> In fact, i'm almost sure that i'm saturate the network by sending the
> position each time it changes, that means, during the time i'm holding
> the arrow key, my sprite is moving, and each moves send a position.
> To go from pos (1,1) to pos (100, 1), i'm sending 50 positions (moves
> increments position by 2).
> Should i limit the number of positions ? Should i send the positions
> only at a certain date ? (for example each 500 ms ?)
>
> thanks for your help
One alternative is simply to send a moving to the clients.
Player N at position X1,Y1 is moving toward X2,Y2 at speed S.
When the player stops moving, then have the server send the message,
Player
N at X3,Y3 stopped moving
For single moves, however, the player moves one space/step only, you would
have to send a message for each of these. If a player is moing in a
direction you can describe (right, left, up down, toward some position,
etc...) at some constant speed, that is the only message need be sent
until
they stop moving (for whatever reason).
|
