¿Referencias de servidor de juegos de mesa por turnos? [cerrado]

¿Hay alguna buena referencia / libro para recomendar sobre cómo construir un servidor de juegos por turnos? Es algo así como un servidor de ajedrez para emparejar jugadores de ajedrez y mantener estados de juego. En el pasado, por ejemplo, el IGS (for go, weiqi) es una implementación basada en socket. ¿Cuáles son las tecnologías contemporáneas disponibles para aprender? ¡Gracias!

No creo que haya un libro en particular sobre esto, ya que el tema es algo trivial.

Solo imagine un servidor de correo donde los jugadores puedan enviar sus acciones por correo. El servidor tiene todas las acciones realizadas hasta ahora (como correos), lo que significa que tiene el estado del juego. Si desea volver a cargar el estado del juego, simplemente ejecute todas las acciones dentro de los correos cronológicamente. Lo único que tienes que hacer es asegurarte de quién es el turno ... pero eso también es fácil (por ejemplo, números de turno). No hay necesidad de tecnologías contemporáneas ... una solución modificada de servidor de correo / cliente servirá.

El emparejamiento ppl se puede hacer a través de Elo ... pero supongo que lo sabías

Si fuera yo, lo construiría desde cero con enchufes. La cantidad de datos a enviar es muy pequeña, y la naturaleza por turnos hace que una pequeña latencia sea imperceptible.

La verdadera pregunta, en mi opinión, es qué características adicionales necesita. ¿Son persistentes las sesiones de juego (puede alguien abandonar y volver a unirse, se puede guardar el juego, etc.)? Si está haciendo un guardado al estilo de Civilization, probablemente desee enviar los datos guardados a todos los clientes, o hacer que el guardado se realice en el lado del cliente con una clave provista por el servidor incrustada para la verificación.

¿Necesita algún tipo de informe entre turnos, por ejemplo, "el jugador 2 está moviendo una unidad" o "su oponente puede estar AFK"? Si es así, puede terminar queriendo mantener abiertas las conexiones de socket.

En términos generales, a menos que haya alguna razón convincente para desviarse, mantendría el servidor lo más tonto y simple posible. Deja menos para depurar. También me gusta usar protocolos de texto sin formato, ya que puedo probar mis servidores usando telnet sin un cliente de juego real (que puede ser sospechoso en un problema dado), pero esto alienta la manipulación de los datos por parte de Wireshark (que probablemente lo hará comprobar de todos modos).

Editar: si el juego solo admite juegos 1 a 1, puede valer la pena mirar las conexiones entre pares.

Es importante no pensar demasiado qué es un servidor y cuáles son sus responsabilidades. En este caso, tiene un juego de acción relativamente lento, por lo que la arquitectura del servidor no será increíblemente complicada (frente a un juego de ritmo más rápido en el que tiene un cálculo muerto, etc.). Su servidor debería estar escuchando en un puerto TCP (podría omitir UDP si no necesita velocidad de todos modos) para que los clientes conectados le envíen paquetes de información. Acepta los paquetes, los valida en función de las reglas del juego y envía una respuesta. En su caso específico, su servidor debe saber quién es el turno actual y rechazar cualquier intento de otros jugadores de realizar acciones hasta que sea su turno.

No sé qué tecnología tenía en mente, pero algo que sería bastante fácil de hacer en Java con la biblioteca Kyronet. Simplemente envíe sus acciones de juego al servidor central (también podría ser uno de los dos jugadores), procese y envíe una actualización del juego a ambos jugadores. Estoy seguro de que existe algo similar para .NET.