Tercera parte...

Videojuego a Videojuego
Se produce entre consolas/ordenadores por la red. Se presupone conocimientos de redes, TCP/IP, TCP y UDP entre otros, asi que me salto la parte de arquitectura de internet y otros conceptos.

Programación de la red
Necesitamos crear las conexiones y definir la comunicación entre aplicaciones. Opciones:

• Utilizar librerías de sockets, control a bajo nivel:
  Para trabajar de manera eficiente con sockets también hay que trabajar con multihilos, los cuales están directamente relacionados con el SO, por lo que debríamos buscar una librería que nos abstraiga de ello, ejemplo Boost o SDL. También deberemos tener conocimientos en streaming ya que muchos demandan la posibilidad de hablar por micrófono con otros jugadores.


• Utilizar librerías de alto nivel, con menos control, las librerías se encargan de las conexiones y su estado:
  
  • DirectPlay: incluido en DirectX. Permite cliente/servidor y peer-to-peer, TCP y UDP y conexión de usuarios con NAT
  • Raknet: cliente/servidor, peer-to-peer, UDP y soporte para transmisión con voz. Es multiplataforma.
  • SDL_Net
  • HawkNL: TCP y UDP, muy senilla y para voz trabaja con HawkVoice.

Arquitectura de comunicación

• Cliente/Servidor
  
  Ventajas:
  • La seguridad se puede controlar mejor
  • Permite garantizar integridad de datos
  • Normalmente los servidores son hardware específicos por lo que tiene mejor rendimiento
  • Mucho más fácil gestionar la gestión de usuarios y de partidas
  
  Desventajas:
  • Se necesita crear dos tipos de programas
  • El hardware del servidor específico puede salir caro, junto con un administrador
  • Si hay problemas en el servidor, el juego se para. La conexión puede hacer cuello de botella.


• Peer-to-peer
  
  Ventajas:
  • No es necesario invertir en hardware
  • Se desarrolla un sólo programa para todos
  • No depende de un sólo sistema, por lo que no hay problemas de conexiones
  
  Desventajas:
  • Poco escalables
  • Posibilidad de desincronización alta
  • seguridad muy baja
  
  Como crear todas las conexiones entre pares peers es de n^2, es inviable. Por lo que se necesita crear estructuras que ahorren y compartan conexiones. La más básica es DHT (distributed Hash Table, o tablas de dispersión distribuidas), los cuales permite mantener información usando pares clave-valor:
  • Esta información se mantiene en alguna parte de la red de peers
  • Cada peer puede introducir/borrar una clave
  • Cada peer puede consultar


• Híbridos
  Conexiones cliente/servidor para aquellos momentos en los que se necesita cierto orden, peer-to-peer para distribuir los cambios de forma rápida u otra información que no es necesario sincronizar como los chats.

Protocolo de comunicación
Cómo vamos a organizar la información a mandar. Alguno de los campos más comunes son:

• Timestamp: para poder sincronizar los eventos en los clientes y además poder saber si algún paquete llega fuera de tiempo (UDP)
• Identificador del mensaje: indica qué tipos de datos manda
• Flags: bits adicionales que nos permite saber más rápidamente
• CRC
• Longitud del paquete
• Datos

Las cuestiones a considerar para el diseño es

• Optimizar al máximo compactando el mensaje
• Enviar el mínimo de paquetes
• No enviar información no necesaria o redundante

Una vez diseñado, definimos la secuencia de mensajes. la secuencia debe indicar cómo iniciar una partida, cómo actualiza la información durante la partida y cómo finalizar la conexión. Una buena manera de definirlo es con un diagrama de flujo que a su vez pueden contener otros diagramas.

El diagrama más complejo es el del bucle principal del juego, ya que tiene que tener en cuenta otros paquetes para la pausa, identificar alguien desconectado, si hay error, si hay ganador....