2009-05-27 16 views
20

Me preguntaba cómo funciona el protocolo multijugador Half-Life 2 en modos como Counter-Strike: Source o Day Of Defeat: Source. Creo que usan algún tipo de ofuscación y algoritmo de compresión propietario. Me gustaría saber cómo se codifican diferentes tipos de mensajes en un paquete.¿Cómo funciona el protocolo multijugador Half-Life 2?

+1

No creo que el protocolo de red sea el término correcto aquí, así que eliminé la etiqueta. –

+1

Llenó la etiqueta, porque eso es exactamente lo que parece preguntar JtR. –

Respuesta

39

Half-Life 2, Counter-Strike: Source etc. todos utilizan el motor de las válvulas de origen. Válvula tiene un developer wiki que cubre un montón de cosas (que es bastante fresco comprobar que funciona!) ...

Estos artículos interesantes:

Latency Compensating Methods in Client/Server In-game Protocol, Design and Optimization

Source Multiplayer Networking

+0

Me pregunto cuánto representante se necesita para agregar enlaces. No aparece en las preguntas frecuentes. – Copas

+0

Creo que puede ser algo que tenga que ver conmigo solo al hacer la cuenta hace unos días :) –

+3

Estoy muy interesado en la compresión delta y la estructura de los encabezados de paquetes y no pude encontrar esa información. – JtR

3

Ésta es una pregunta muy complicada, mi sugerencia sería la de buscar en algunos de los motores de juego de red de código abierto:

También podría ver la fuente código para la serie de terremotos en la que se basa el motor de vida media original.

+0

Enfóquese en las ramas del motor de Quake: algunas terminaron construyéndose hasta el punto de compatibilidad con Half-Life. Motores como FTEQuakeWorld o TomazQuake podrían ser buenos puntos de partida. –

+0

@A. Scagnelli, el motor Source (motor de Half-Life 2) no está basado en el motor Quake. Entonces, si bien sería bueno aprender conceptos básicos de servidor de cliente, no le dará el código exacto. –

+0

Nada le va a dar el código exacto, a excepción de la licencia del motor. Y Source Engine tiene raíces en Quake Engine. – Aistina

2

Aunque los detalles pueden diferir , el marco general es bastante viejo. Aquí hay una vista general rápida:

En los primeros juegos de fps como Doom y Quake, la posición del jugador se actualizó solo en la respuesta del servidor a su comando de movimiento. Es decir, presionó el botón mover hacia adelante y el cliente le comunicó que al servidor, el servidor ubicó su posición en su memoria y luego transmitió un nuevo estado de juego a su cliente con su nueva posición. Esto condujo a un juego muy lento: disparar, incluso moverse en pasillos estrechos era un juego de predicción de lag.

Los juegos más nuevos permiten que el cliente maneje los disparos y el movimiento del jugador por sí mismo. Aunque esto provocó un movimiento y un disparo sin retardo, abrió más posibilidades de hacer trampa pirateando el código del cliente. Ahora cada jugador se mueve y dispara independientemente en su propia computadora y le comunica al servidor lo que han hecho. Esto solo se rompe cuando dos jugadores chocan entre sí o intentan tomar un poder al mismo tiempo.

Ahora el servidor tiene este flujo de estado del cliente procedente de cada jugador y tiene que sincronizarlos y hacer un juego coherente de ellos. El truco es medir la latencia de cada jugador. El objetivo final es poder disparar un arma de latencia muy baja (como un rifle de francotirador o cañón de riel) sobre un enemigo que se mueve hacia los lados y hacer que golpee correctamente. Si se conoce la latencia de cada jugador, supongamos que el jugador A (latencia de 50 ms) dispara un arma en B (latencia de 60 ms). Para hacer un golpe, el tiro tiene que golpear B donde B estaba hace 60ms, desde donde A estaba hace 50ms.

Esa es una descripción muy aproximada, pero debe darle una idea general.

+0

Esto no explica cómo se codifican los diferentes tipos de mensajes en un paquete. – JtR

+2

"Ahora cada jugador se mueve y dispara independientemente en su propia computadora y le comunica al servidor lo que han hecho". Esto no es cierto, al menos en Half-life 1. El cliente solo puede ejecutar la misma simulación localmente para crear la ilusión de cero retraso, pero el servidor todavía obtiene entradas de control normalmente, no el estado completo. El servidor también tiene la última palabra sobre lo que está sucediendo, por lo que los clientes no pueden usar esto para "romper las reglas del juego". –

5

Debe consultar Luigi Auriemmas papers en Half-Life. Encontrarás un decodificador de paquetes y algunos algoritmos desensamblados allí, también.

La información de ingeniería inversa en Half-Life 2 puede ser difícil de encontrar, debido a su relevancia para hacer trampa. Supongo que las tablas como mpcforum son su mejor opción.

+0

Esta es la mejor respuesta hasta el momento, incluso si no contiene la respuesta exacta. Al menos tengo una remota posibilidad de encontrar a alguien que sepa sobre esto desde ese foro, ¡gracias! – JtR

1

Le sugiero que consulte los motores Quake 1-3. Están disponibles con código fuente. El protocolo de Half-Life puede ser un poco diferente, pero lo más probable es que esté lo suficientemente cerca.

Cuestiones relacionadas