Simple network gaming, client-server architecture planning

I'm coding simple game which I plan to make mul开发者_如何学编程tiplayer (over the network) as my university project. I'm considering two scenarios for client-server communication:

The physics (they're trivial! I should call it "collision tests" in fact :) ) are processed on server machine only. Therefore the communication looks like

Client1->Server: Pressed "UP"
Server->Clients: here you go, Client1 position is now [X,Y]
Client2->Server: Pressed "fire"
Server->Clients: Client1 hit Client2, make Client2 disappear!

server receives the event and broadcasts it to all the other clients.

Client1->Server: Pressed "UP"
Server->Clients: Client1 pressed "UP", recalculate his position!!
[Client1 receives this one as well!]

Which one is better? Or maybe none of them?

---

The usual approach is to send this information:

1. Where the player is
2. At what time he is there (using the game's internal concept of time, not necessarily real time)
3. The player's movement vector (direction and speed)

Then the clients can use dead reckoning to estimate where the other players are, so that the network latency will disturb the game less. Updates need to be send only when the player changes his direction or speed of movement (which the other clients cannot predict), so also network bandwidth will be saved.

Here are some links on dead reckoning. The same web sites contain probably also more articles on it. http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php http://www.gamedev.net/reference/articles/article1370.asp

---

i think the first approach is better. so you have equal data on all clients.

when the physics are simple and the results of the calculations are always the same the second approach is ok too. but if there are random numbers possible you will have different effects on all clients.