¿Se transmiten objetos estáticos enormes como el entorno del servidor al cliente en los juegos multijugador modernos?


18

Tengo un sistema autorizado, donde cuando el jugador se une al partido, obtiene todos los objetos ya generados, generados en sí mismo (el cliente).

Se parece a esto:

  1. Client envía el token de acceso a la Server
  2. Client recibe la aceptación del Server
  3. Client cambia la escena a la escena del juego
  4. Serverenvía jugadores, cajas, objetos con los que puedes interactuar para que clientpuedan aparecer y mostrarlos.

¿Pero qué pasa con el objeto de tierra? Por ahora, tengo exactamente la misma escena en el servidor y el cliente, con un plano estático que actúa como piso. Actualmente estoy agregando cosas nuevas, árboles, escaleras y construimos cosas juntos.

Pensé: estamos bien. ¿Pero no debería sincronizarse también el entorno? Estar en red de alguna manera? Propiedad del servidor?

Tomemos League of Legends:

ingrese la descripción de la imagen aquí

Es un entorno estático, probablemente una malla combinada (escaleras, césped, paredes, tienda). Pero, ¿se guarda realmente en el cliente o lo envía el servidor durante la pantalla de carga?


1
Incluso puede pensarlo desde el punto en que puede agregar máscaras personalizadas a los personajes de la liga y al entorno. No los envía a cortar, se muestran localmente, por lo que tiene sentido llegar a la conclusión de que están almacenados y representados localmente. Además, no afectan el juego, si preguntas sobre colisiones, son una mezcla de servidor y cliente, por lo que el jugador no puede hacer trampa y atravesar paredes.
Candid Moon _Max_

Respuestas:


41

En su mayor parte, no, los activos artísticos de cualquier tipo no se envían de forma rutinaria a través de la red. En general, todos los clientes tendrán los mismos activos de contenido localmente. Puede haber un código para garantizar que este sea el caso mediante la suma de verificación del contenido o similar. Si le preocupa que los usuarios manipulen parte de su contenido del lado del cliente, puede implementar un sistema similar.

El servidor puede enviar directivas al cliente indicando que debe mostrar u ocultar ciertos activos, pero no enviará los datos reales del activo. Esto es, en la práctica, demasiado derrochador y lento, y podría causar problemas reales con personas con datos limitados disponibles.

En ciertos casos, los activos más pequeños pueden transmitirse en su totalidad si el activo de alguna manera se considera un "spoiler" o lo que sea. Pero eso es poco común. En general, lo que ves es que un juego puede descargar contenido nuevo de un parche, o lo que sea, pero eso solo sucederá una vez, durante el proceso de parcheo al inicio. No durante el juego.


21
Tenga en cuenta que esta respuesta solo aborda los activos estáticos. Los activos generados por jugadores / dinámicos (p. Ej., Fragmentos de mundo de Minecraft o logotipos de gremios MMORPG que los jugadores pueden cargar) deberán transmitirse. Pero incluso entonces, generalmente se intenta minimizar la cantidad de datos necesarios (para continuar con el ejemplo de Minecraft: enviar actualizaciones de bloques en lugar de fragmentos enteros, solo indicando el tipo / estado del bloque y las coordenadas que cambiaron) y / o almacenar en caché los datos en el lado del cliente .
hoffmale

@hoffmale Sí, buen punto; La pregunta mencionaba que el paisaje era estático al final, así que no pensé en plantear ese punto, pero es bueno.

3
Si un activo es un spoiler, generalmente el activo está en el cliente, encriptado, y la clave de descifrado se transmite del servidor al cliente cuando se necesita el activo.
Grant Davis

44
Y, por ejemplo, si necesita colocar árboles al azar en un mapa, en lugar de enviar las coordenadas de los árboles al cliente, envía la semilla (del generador de números aleatorios) al cliente.
Grant Davis

5

Depende de varios factores, incluido el tipo de juego (supondré RTS aquí, aunque también me viene a la mente el MMO de mundo abierto). Un estado de terreno base de local a jugador se envía al conectarse o es parte de los activos del cliente; piense en un juego RTS donde el mapa se envía con el cliente o se descarga antes de que comience un juego.

De hecho, la malla generalmente no se enviaría, ya que ya estaría en el cliente en la mayoría de los casos de RTS. Si se envía o no el mapa de colisión, que es lo que es realmente crucial para mantener los dos sincronizados , es otra cuestión. Pero en la mayoría de los RTS, esto volvería a almacenarse previamente en el cliente.

Entonces, realmente, todo depende de con qué se envíe su RTS, ya sea que descargue mapas antes del tiempo de juego o en el momento en que comience el juego.

Después de eso, hay algunas formas típicas de mantenerse sincronizado:

  • Los deltas se envían al cliente, la forma más común y eficiente de mantener actualizado el mundo local / cliente con el servidor;
  • En ocasiones, las sumas de verificación se envían de servidor a cliente o de cliente a servidor para garantizar que el estado mundial realmente coincida;
  • Ocasionalmente, el estado completo se reenvía para resincronizar al cliente, a menudo como resultado de preocupaciones técnicas como la deriva de coma flotante.

4

En cuanto a su pregunta exacta como se le preguntó, no sé cómo League of Legends lo maneja específicamente. Nunca he jugado ese juego, así que no puedo sugerir si es necesario o no.

Pero la respuesta a su pregunta, en general, es bastante simple y directa:

Si los datos son estáticos , y usted sabe con certeza que lo harán nunca cambiarán (salvo las actualizaciones periódicas del juego completo, pero eso es por separado), entonces ¿por qué querrías enviar esos datos adicionales? Por lo general, intenta evitar enviar lo que pueda evitarse. Solo envíe datos si esa comunicación es necesaria .

Por otra parte, si los datos cambiarán con el tiempo , o si solo desea dejar esa opción abierta, ¿realmente tiene alguna opción al respecto? Para este caso, debe enviar los datos. De lo contrario, el cliente no tiene lo que necesita.

Esto se aplica a todas las comunicaciones de red, no solo a los datos del terreno. Todo .


2

No.

He hecho una feria de excavación en la fuente de League of Legends, y todo, incluidos los modelos Champion, Shopkeeper, el fondo del mapa general y las criaturas pelusas añadidas después del hecho (como la pequeña ardilla en algunas rocas y un caracol en el río) se mantienen del lado del cliente. El hecho de que el cliente tenga todos estos modelos es una de las razones por las que LoL tiene muchos gigabytes de tamaño.

Transferir todos estos datos del servidor al cliente sería un infierno, sin mencionar el uso del ancho de banda solo para volver a hacerlo todo el próximo juego.

Entonces, ¿cómo se resuelve entonces? Cada jugador solo envía los datos que importan a otros al servidor jugadores del juego. Nadie necesita saber si te quedan 5 segundos en el tiempo de reutilización de Q, o si el Aspecto de Terror Profundo crea burbujas para ti. Las cosas que pasan en el juego son cosas como, Vel'Koz lanzó Q, Viktor se movió a la izquierda, etc.

Más explícitamente, en relación con la pantalla de carga, a medida que lo mencionas, cosas que suceden son cosas como parches de parche medio, que cada jugador necesita hablar con los servidores de Riot antes de que comience el juego, protocolos de conexión segura y protocolos anti trampa.

NOTA:

Si quieres ver qué cosas tiene el cliente y, por lo tanto, el servidor no te pasa, busca la carpeta C: \ Riot Games \ RADS \ lol_Game_Client \ Projects (eso podría estar un poco apagado, perdóname ' estoy trabajando fuera de la memoria en este momento) y encuentre un desempaquetador de archivos .RAF en línea. Luego puede ver todas las cosas que se encuentran localmente, como cargar salpicaduras de pantalla y texturas de piel, incluso esqueletos de campeones.


1
Parece que la forma obvia de implementar esto sería hacer que el cliente solicite (desde un servidor de activos dedicado) cualquier activo que no haya almacenado localmente, y cuando los recibe, los agrega (semi) permanentemente a su Tienda local persistente en el disco. De esta forma, los activos solo se descargan una vez, y solo cuando realmente se necesitan. (Una vez que está trabajando, una optimización sería para rellenar previamente tienda local del cliente con activos que son muy probable que se necesiten Esto reduciría el tiempo de inicio del juego en la primera conexión, a costa de hacer el paquete de instalación del juego más grande.)
Jeremy Friesner

1
@JeremyFriesner ¿Por qué sería esa la manera obvia? Eso suena peor que la implementación actual descrita en esta publicación, que hace que instale todos los activos con anticipación para que los tenga disponibles de inmediato cuando los necesite. Podría funcionar bien para un juego de un solo jugador, aunque creo que mucha gente preferiría un mayor tiempo de instalación (y más uso de espacio en disco) en lugar de tener que esperar constantemente a que se descarguen nuevos activos durante el juego.
Anthony Grist el

2
¿Para un juego multijugador? Desastre absoluto. No querrás mantener a todos los demás jugadores esperando para comenzar el juego porque una persona tiene que descargar algunos recursos que nunca han necesitado hasta ahora.
Anthony Grist

1
@AnthonyGrist Es por eso que muchos juegos como League of Legends requieren que un jugador descargue todos los activos del juego antes de unirse a la cola para encontrar una coincidencia. Esto funciona mucho mejor que tener el retraso del juego mientras esperas que funcione un gran activo. Tenga en cuenta que en este tipo de juego, los jugadores se entusiasman con una reducción de 10 ms en el ping y, a menudo, juegan con <50 ms de ping y pueden saber si eso salta al rango de 100 a 150. Esperar a buscar un activo durante un juego sería un desastre en un MOBA o FPS, y si sucediera en el momento equivocado, incluso podría cambiar el resultado de un juego.
JustWannaFly

@AnthonyGrist (continuación) Supongo que podrías pensarlo así. En algunos juegos multijugador / competitivos, los jugadores intercambian un tiempo de carga / parche / instalación más largo por una experiencia de juego más en tiempo real al hacer que un cliente se encargue de todas las actualizaciones y las colas. Esto hace que solo el jugador específico que necesita activos tenga que esperar a menos que quiera unirse a una fiesta prefabricada, entonces todos los jugadores en la fiesta tendrían que esperar para ingresar a la cola para encontrar oponentes
JustWannaFly

1

Un ejemplo de dónde no se hizo esto fue Elder Scrolls Online, donde confiaba en el cliente sobre la altitud del nivel del suelo .

Los mineros de oro cayeron al nivel del suelo varios pies. Luego podrían caminar "debajo" del terreno y extraer recursos desde abajo sin ser vistos por PC o atacados por NPC.

Ediciones similares les permitieron suavizar los acantilados para poder subirlos, quitarlos o enrutarlos bajo paredes estáticas, ver a través de todos los objetos estáticos, etc.

Esencialmente, el servidor confiaba en el cliente sobre la ubicación del jugador, calculando la colisión en el lado del servidor para cada jugador contra todas las estadísticas sería bastante pesado.

Sin embargo, en los juegos basados ​​en mosaicos como Furcadia, es diferente: cada casilla a la que te mudes tiene capacidad para caminar del lado del servidor, y el servidor no necesita confiar en el cliente para nada: el servidor conoce y valida cada movimiento y acción del usuario, y el cliente solo muestra la acción cuando el servidor le dice el resultado.


1
TL; DR: Siempre asuma que el cliente es un mentiroso, tramposo, avutarda . Pero la validación del servidor de todo reduce su capacidad.
Draco18s
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.