Te digo algo: Si necesitas hacer un par de cosas "raras" para que tu juego funcione bien.
1.- Cuando envias información, la información no siempre llega "igual" como la mandaste. Ej:
Mandas "Hola", luego mandas "Mundo":
Puede que reciban: "Hola" y luego "Mundo", también: "HolaMundo" todo unido,
esto complica la recepción de datos y puede que necesites reconsiderar tu "protocolo" de envio de mensajes que creaste para tu juego. Necesitas diferenciar el "Hola" del "Mundo". Puedes usar un caracter especial que es lo más fácil, o también indicar la longitud de cada fragmento de información que envies:
Así si a tu método de recepción de mensajes llega:
t4Holat5Mundo
Tu método podría reconocer la "t" como inicio de fragmento de texto y el 4 como la longitud de ese texo. Obviamente mejor si envías datos binarios y en lugar de enviar un "4" en texto envías un 4 binario (un byte) para poder enviar más información sin desperdiciar ancho de banda:
Ej, Mandar 200 en texto es menos eficiente y más complicado que enviar un 200 en binario que ocupa un solo byte. Es más fácil hacer un programa que luego de leer la "t" que indica texto lea el siguiente byte y determine la longitud del texto que sigue que tener que distinguir si 200 se refiere a que la longitud del texto es 200 caracteres o es de 2 caracteres y los caracteres son "00".
2.- Si el paquete es demasiado grande, se fragmenta. Es bueno que evites despachar paquetes grandes (más de 1Kb de información), especialmente si quieres hacer un juego en "Tiempo real" ya que esperar por el resto de información faltante destruye el ritmo del juego y en los juegos en "tiempo real" el ritmo de juego es vital para crear la ilusión de continuidad.
Como tu juego es por turnos, puedes agregar a tu método de recepción un sistema que detecte que falta información adicional y espere a que llegue otro paquete con la información faltante en cierto tiempo, evitando que el juego quede detenido mucho tiempo.
Ej. Te llega "t4ho", como esperas 4 caracteres y sólo te llegaron dos esperas hasta que en un máximo de digamos 4 segundos llegue otro paquete con el "la"
¿Pero no se supone que esas cosas las hace el winsock?
Nadie dijo que los "paquetes" no vayan a llegar juntos o primero llegue una parte y luego el resto. Lo que asegura el "soket" es que TODA la información llegue a destino... eventualmente (si no ocurren problemas mayores) y llegue en orden. Tu tienes que saber distinquir tus fragmentos de datos que envias y saber si ya te llego todo tu fragmento.
P.D.
Si no me crees haz que tu programa te muestre en pantalla todo lo que recibe el socket y haz la prueba enviando cantidades muy chicas de información en varias llamadas a "send" una detrás de otra y también enviando un buen paquete de información como de 64Kb y verás los resultados. Prueba sólo en tu máquina, en red a otra máquina y si es posible por internet usando una conexión "dial up". Verás las sorpresas que te esperan.
----------------
La diferencia de los juegos "con turnos" de los juegos en "tiempo real" es que en los juegos en tiempo real puedes o no usar tu turno, los turnos apenas duran una fracción de segundo o en el caso de juegos de estrategia tu puedes mandar la cantidad de órdenes que desees pero tus "bichos" se mueven y atacan en sus respectivos turnos. Obviamente no se espera a que el jugador realize su "movida" para que comience el siguiente turno y pocas veces los turnos están sincronizados.
Turnos no sincronizados: por bicho y acción existe un tiempo de espera hasta realizar la siguiente acción, esto lo sincronizan muy bien con la animación de los "bichos" para desvanecer cualquier impresión que todo el juego va por turnos y dar la sensación de continuidad.