¿Debería el anfitrión del juego ser la autoridad u otro cliente tonto?

Al diseñar un juego multijugador en red donde un jugador aloja y otros se conectan, hay dos estrategias que conozco:

• Haga que el juego del jugador anfitrión sea la autoridad , con todos los demás jugadores como clientes tontos tratando de ponerse al día con el estado actual del juego. En el código, tendrá que haber muchos casos especiales, dependiendo de si el jugador actual es el anfitrión o no.
• Haga que el host sea un cliente tonto como todos los demás ejecutando un servidor dedicado oculto en otro hilo. El servidor dedicado será la autoridad, y el host se conectará a él como todos los demás (a través de localhost).

¿Cuáles son las ventajas / desventajas de cada uno de estos? ¿Cuál se usa con más frecuencia (o varía según el tipo / tamaño del juego)?

El enfoque de cliente tonto es mejor desde un punto de vista de diseño puro: limita en gran medida la cantidad de código diferente que necesita entre el host y los clientes, y permite que el servidor se ejecute de forma asincrónica. La desventaja es que la máquina del host requiere recursos adicionales, pero supongo que siempre lo hizo.

Entre estas dos opciones, el enfoque de cliente tonto es ciertamente mejor por las razones que menciona DeadMG.

Hay otra opción que hace que cada cliente sea una autoridad, tiene la ventaja del cliente tonto de que todos los pares comparten el mismo código. La otra ventaja es que podría ser mucho más justo si establece las reglas correctas porque nadie tiene la ventaja de 0-lag-to-server.

Por supuesto, esto puede ser bastante complicado de implementar dependiendo del tipo de juego. Su protocolo tendrá que lidiar con la resolución de conflictos entre pares, probablemente utilizando algún tipo de esquema de propiedad. Dejando solo los conflictos donde 2 pares reclaman la propiedad del mismo objeto del juego.

Buscar en Google los protocolos multijugador Peer-2-Peer podría darle más detalles sobre este enfoque.