> But my problem is the sockets : I''ve developing finally in C++, > and VisualC++6.0 don''t allow to have a conversion between > sockaddr_in and sockaddr by default (when I''m calling read > (something,something, &sockaddr_in, sizeof (sockaddr_in));
AFAIK, you should not stuff any sockaddr into the "read" function. "read" is reserved for FILE I/O on windows. Use "recv" to read data from a socket. The sockaddr structure goes into the "connect" or "bind" function, depending if you are cleint or server for the connection. To avoid the compiler error, do something like this:
sockaddr_in sa;
// open socket SOCKET s = socket (AF_INET, SOCK_STREAM, 0);
// fill sa struct sa.sin_family = AF_INET; sa.sin_port = htons (); sa.sin_addr.s_addr = htonl (INADRR_ANY);
Well this is fascinating. Like many others I am looking at MMO. Is there an argument for peer to peer and giving the client more control over the game. To decide collisions, kills and defences on the clients game and to send and confirm kills from client to client looking at the server only for confirmation and physical less frequently changing data such as the map?
I have no idea sorry, and i''d think it really depends on the game. At a GUESS i could say that a single server might support maybe 100-200 people in a game like everquest, but it really does depend on the game and the tech they are using. The client in any online game should really be basically used as a dumb renderer, although running simulations to lower bandwidth requirements is fine. However, any collision testing, kills, whatnot etc. must be run on the server to keep the game synchronised, protect against illegal use (hacking/cheating) and reduce lag. (Especaially in a MMO game, peer-peer is almost entirley useless). All of these collision tests, kill checks etc. can be simulated on the client, but the client should just send the actions it wants to do to the server, the simulation is just there to reduce the visible etc. effects of lag, the server has the final say over what happens.
quote:Once the client comes in contact with another entity, temporarily store that entity on the client so that you only need to send data when that entity actually changes.
Well I don't totally agree on that technique. Okay it will probably reduce the lag a little bit, but if the client has to send the state of that entity, you're gonna have a security flaw. Your game WILL most probably be hacked.
Let the server do every calculs and random numbers generation for the client.
You misunderstand what i meant by that sentence. The client doesn''t do any calculations on the entity at all, but it does temporarily (until not in contact anymore) store the entitys variables on the client so the server only has to send you the variables of that entity that change, rather than sending you all the neccessary variables of the entity every frame. The client doesn''t send any data on the entity to the server. Hope that clears it up for you.
