   Socket & Character handling (logic)
  I'm pretty new to Game Development, but not programming. I'm just looking for some of the best methods to handle sockets and characters, I'm having a bit of trouble coming up with a good way. Of course I need to have an array of sockets, but I can't think of a good way to incorporate a character class into that.I was thinking I could store the socket resource inside the character class, then every loop it would create an array from all of the characters' sockets. But that sounded like a bad practice to me( because it would have to recreate the socket array every list, and not just have it readily accessible). Maybe I'm wrong and this would be acceptable, I really don't know.Some guidance is really appreciated.   
  you do not need a socket per character, why associate character entity to socket entity? the character should be ready to send/receive updates,the sockets are just the means to transmit/receive the updates.Check the forum FAQ for more info.and a good resource: http://gafferongames.com/networking-for-game-programmers/   ;  A character will represent a player, each player must have a socket to communicate with the server, that's my thinking behind it.Thanks for the link, looking into it now.Edit: Would a better idea be to send a character id to the client when the character is created, then send that back in every packet the client sends to the server?   ;  Most important question: Which language, which socket type (winsock, some Socket class, some library, ....), which OS?   ;  I'm really just looking for logic based help. But I already think I've got what I need.   ;  Actually, Q31 in the FAQ talks exactly about this design question: How do I couple game objects and networking?It links to this article about game network library design.   ;  From a security perspective this is really dangerous since a player could hijack another player by using a hacked client that modifies the id.Quote:Original post by AlexWDA character will represent a player, each player must have a socket to communicate with the server, that's my thinking behind it.Thanks for the link, looking into it now.Edit: Would a better idea be to send a character id to the client when the character is created, then send that back in every packet the client sends to the server?;In my cases, I opted for per-host sockets, not per-player.  I wanted to support multiple players per client.Also, you may have a lot of game state independent of the client.  You are assuming player==client machine, but that may not always be true.I do worry about cheating.  Each socket has its own DES key for encrypting sensitive information, and all clients are given a token to send back to the server with every request, so the server should detect if a player is attempting to spoof another client.;Quote:I do worry about cheating. Each socket has its own DES key for encrypting sensitive information, and all clients are given a token to send back to the server with every request, so the server should detect if a player is attempting to spoof another client.If the key is different for each connection, then the token is redundant. You can't decrypt a packet without it having been encrypted with the right key :-) Your packet-level CRC/hash checksum will catch problems in that regard.However, encryption does not prevent a player from cheating on his own machine; pretty much only game design or community policing can prevent that.   