Timeing multyplayer games.
Greg Cavanagh
Gooday. whats the most effective way to keep programs on two or more
machines over a network.
I'm want to make a stratagy game but can't figure the best way to have
the same peice do the same thing on multiple computers simultaneously.
Just a hint would be nice thanks.
Greg Cavanagh
Sorry. I got that message messed up a bit.
I'm writing a game of warships in 3D. They are Galleons and Triremes.
I've created the ships useing 3D vectors. I'll apply an angular velocity
to the ships to turn each one at a different rate. As a ship moves
faster the turn radius will increase. I'm wondering what would be the
best way to keep the two games correlated.
I Figure that each machine should compute for only it's players
positions, and send position and direction vector information over the
network. That way the computer only needs to reposition the other
ships and calc intermediate positions.
Also wich machine should register a hit. I can't see how the receiver
of an attack can do it, or for that matter how the sender can do it.
Hope this clarifys the question.
Robert Winkler
Greg,
I am creating a game for the internet medium, and I think of
the problem this way: Client/Server and Object Encapsulation.
I tend to separate the design this way because it becomes more
manageable in my mind.
I hope I can answer your question about, "who registers a ship
hit", but I want to make sure you are using the model I am
thinking of first.
I am going to ignore the case of a single source server model,
ie. all users dialup to your server and are strictly clients
to it. These would be the online and head to head models.
Therefore, I am assuming each player acts as a server "and"
a client:
Player1 wishes to initiate a turn,
the server on his/her machine processes the request and
then sends the results to the other player's servers, and
their server informs their local client.
This keeps all gui and processing separate.
Note, that each server needs to share the same view of the
world and so must be synchronized to each other.
This duplicates processing but allows faster responses.
This approach allows you to Encapsulate the Processing parts
and the Graphical parts independantly.
The Player, Client Vector Detection Algorithm, or Server Rules
can initiate events that fall out naturally in the game design.
Ok, now to what I think is the answer, to "which machine should
register a hit". The machine that "takes" the hit. Why? Because
it is logical to process what has happened to my ship only on my
machine. My machine, more specifically "MY SERVER", will then
inform all other servers of the change in state, the servers will
process the change, and then all clients will update their screens
concurrantly. Note that the receiving server might intiate its
own event based on gaming rules. Btw, I would suggest keeping
all data only in the server and the client only knows information
that it should.
For example, Player1(P1) moves into Player2's(P2) ship (ramming),
P1's Vector logic informs its server,
P1's server informs all servers of the change and
invokes its OnHit event,
All servers receive P1's new data,
P2's server processes the data which invokes its
OnHit event,
P1's server processes its OnHit and sends out new
info to all servers,
P2's server processes its OnHit and sends out new
info to all servers,
All servers receive P1's and P2's info,
P1's and P2's servers process the data and do not
invoke their OnHit events again,
All servers inform their clients,
P2's server continues its OnHit logic and raises its
OnBreached event,
P2's server processes its OnBreached event and sends
out new info...(you get the idea).
Obviously, queuing is part of the server synchronization.
I hope this helped,
Robert Winkler
rwin...@earthlink.net