Jump to content

Search the Community

Showing results for tags 'carta de desarollo'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • PLAYERUNKNOWN'S BATTLEGROUNDS
    • Forum Rules & Guidelines
    • Report A Player & Appeals
  • Game Announcements & Forum Info
  • Gameplay Discussion & Suggestions
  • PC
    • PC News & Patch Notes
    • Game Discussion & Feedback
    • Help & Troubleshooting
    • Bug Reports & Known Issues
    • Test Server
  • Xbox
    • Xbox News & Patch Notes
    • Game Discussion & Feedback
    • Help & Troubleshooting
    • Bug Reports & Known Issues
    • Test Server
  • PS4
    • PS4 News & Patch Notes
    • Game Discussion & Feedback
    • Help & Troubleshooting
    • Bug Reports & Known Issues
    • Test Server
  • PUBG API Community Developers
    • Getting Started
    • Announcements
    • Community Developer General Discussion
    • Community Developer Projects
    • Community Developer Help
  • Community
    • Introductions
    • Looking For Players
    • Community Content
    • Off Topic
  • Other Languages
    • Russian
    • Portuguese
    • Polish
    • Turkish
    • Spanish
    • German
    • French
    • Italian

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 1 result

  1. Queridos jugadores: En la Carta de desarrollo de hoy, nos gustaría compartir algunos de los avances que hemos realizado para mejorar significativamente el rendimiento del servidor, así como las mejoras adicionales en las que estamos trabajando actualmente. Visión de conjunto: La versión de Unreal Engine que actualmente utiliza PUBG se basa en un modelo Cliente-Servidor y, por lo tanto, el estado de cada "actor" (objetos colocados en niveles que representan caracteres, edificios, telones de fondo, cámaras, etc.) debe actualizarse a través del servidor para cada jugador. El rendimiento del servidor generalmente se indica mediante tick-rate del servidor o Frame Time. A medida que aumenta el rendimiento del servidor, el tiempo por fotograma disminuirá. A medida que disminuye el tiempo por fotograma, también mejora el tiempo de respuesta del servidor. Cuanto más rápido responda el servidor, más rápido se actualizarán sus acciones / movimientos. Por ejemplo, qué tan rápido desapareces de la pantalla de tu oponente después de esconderte detrás de una pared en la tuya. Si queremos reducir lo que comúnmente se conoce como desincronización, es necesario mejorar el tiempo de respuesta del servidor. Mejoras a través de la Actualización # 14 La estructura del proceso de red antes de la Actualización n. ° 14 y conclusiones. Antes de la Actualización n. ° 14, la red se procesaba en el servidor en Unreal Engine, como se muestra a continuación. Vamos a explicar primero el flujo de proceso de red anterior. En la etapa "Net Dispatch", el paquete recibido del cliente se procesa en el servidor. Por ejemplo, tiene información entrante, como disparos, movimientos, etc. Las cosas que se procesan durante este paso generalmente se distribuyen a otros clientes en dos formas: RPC (Llamadas a procedimiento remoto) y Replicación. Después de esto, la lógica del juego como la simulación de física se procesa durante la etapa "Simulate & Render" y el resultado se entrega a todos los clientes a través de "Net Flush". Sin embargo, cuando se envían RPC como resultado del proceso de "Net Dispatch", no se envían de inmediato, sino que se ponen en cola en el búfer. Las muchas cosas almacenadas en el búfer se envían a todos los clientes durante la etapa "Net Flush" y el búfer se vacía. En esta estructura, el RPC debe pasar por la etapa "Simulate & Render" para ser enviado desde "Net Dispatch" a "Net Flush" y, por lo tanto, provoca un retraso. Quizás Unreal Engine se estructuró de esta manera para minimizar la cantidad de paquetes entregados a UDP. De todos modos, cuando se minimiza el número de paquetes, la red funciona de manera más eficiente. La nueva estructura de proceso de red y mejoras Decidimos que mejorar el tiempo de respuesta del servidor era más importante que disminuir la cantidad de paquetes para PUBG. Por lo tanto, el equipo rediseñó la estructura como se muestra a continuación en la Actualización # 14. El equipo agregó una etapa "Net Send Flush" antes de la etapa "Simulate & Render". En la etapa "Net Send Flush", todos los datos UDP almacenados en el buffer serán enviados y el buffer será vaciado. A través de este nuevo flujo, el tiempo que se solía tomar para "Simulate & Render" ya no es necesario, disminuyendo así el tiempo de espera. Durante la fase Net Send Flush, no hay cálculos exhaustivos para la replicación de los "actores" y los datos UDP pendientes se vacían. Como hay dos actualizaciones de red, "Net Send Flush" y "Net Flush" en la nueva estructura, la tasa de actualización de la red se duplicó después de la Actualización N. ° 14, lo que provocó que algunas personas asumieran que el tick-rate del servidor aumentaba. Sin embargo, no fue el tick-rate del servidor, sino la tasa de actualización de la red que saltó a 60 tick-rate a medida que se entrega otra actualización de red durante el procesamiento de Server Tick. Estos resultados se pueden encontrar en Battle (Non) Sense's Update # 14 Netcode Analysis. Mejoras para la actualización n. ° 19 Resultados de creación de perfiles antes de la Actualización n. ° 19 y una nueva hipótesis Los datos del perfil antes de la Actualización de PC n. ° 19, medidos cuando 90 jugadores están vivos el 25 de junio de 2018, son los siguientes. El tiempo neto de descarga es 43.2 mseg, 41% del tiempo total del fotograma. Gran parte de este tiempo se usa para "serializar" para replicar cada actor al cliente. "Serializar" es un proceso de escritura de datos en un orden en la memoria para entregar el estado del actor al cliente a través de la red. Como estábamos buscando el método de optimización basado en el resultado del perfil anterior, pensamos "si somos capaces de reducir el número de actores replicados, especialmente los personajes, el tiempo total de Net Netup se reducirá significativamente". A diferencia de otros juegos que usan un servidor dedicado en Unreal Engine, hasta 100 jugadores juegan simultáneamente en una partida en PUBG, lo que significa que la cantidad de actores es significativamente mayor. El gran tamaño de los datos de los actores es un problema, pero el gran volumen de actores es el problema más grande. Mientras pensábamos en formas de reducir el número total de actores, pensamos que replicar personajes distantes a una frecuencia más baja ayudaría. Dado que los personajes lejanos no son relevantes a esa distancia, la cantidad de actores serializados se puede reducir considerablemente sin afectar el juego, y como resultado, el tiempo de Net Flush se puede reducir. Proceso de desarrollo: sistema de entrelazado de replicación A partir de la idea anterior, llegamos a una conclusión para implementar un sistema que omite las solicitudes de replicación a una frecuencia más apropiada en función de la distancia del cliente y el actor. Llamamos a esto el sistema "Intercalación de replicación". En primer lugar, sacamos la sección donde se replican los actores y disminuimos las frecuencias de replicación de caracteres lejanos. Luego analizamos los problemas y los tipos de cambios visuales. Una vez que pudimos resolver los problemas que ocurrieron cuando se redujo la frecuencia de replicación, probamos qué tan lejos podíamos llegar y llegamos a la conclusión de que reducir las frecuencias de replicación a 1/4 del nivel original todavía no tenía ningún impacto en el juego. El sistema de intercalación de replicación completo se implementó de la siguiente manera: Paso 1: Omita 1 fotograma en los caracteres ubicados a más de 70 m Paso 2: Omita 2 cuadros en los caracteres ubicados a más de 400 m (Nota: este es el estado a partir de hoy, y este valor puede cambiar en el futuro para un mejor rendimiento del servidor y movimientos más suaves) Resultado de la mejora El rendimiento del servidor aumentó en un 20% después de la implementación del nuevo sistema. En el siguiente diagrama, rastreamos la velocidad de fotogramas de un servidor de región NA cuando 85 jugadores estaban vivos. Después de la actualización, la tasa de tick del servidor aumentó en un 22% de 18.5 a 22.9. Otras regiones también mostraron más de un promedio de 20% de aumento de la tasa de fotogramas. Lo que es aún mejor es el cambio que ocurrió en el tiempo de respuesta. Consulte el video de YouTuber Battle (non) Sense relacionado con la Actualización N. ° 19. En conclusión Mejorar el tick-rate del servidor desde el lanzamiento de PUBG ha sido una prioridad constante para el equipo. Además de resolver problemas de software, también se han realizado mejoras en el hardware. Sin embargo, sabemos que no ha habido mejoras claramente notables para los jugadores en los últimos meses antes de la Actualización # 19. Durante FIX PUBG, doblamos la mejora del rendimiento del servidor y continuamos investigando y experimentando sobre varias ideas, pero este es un proceso lento. Para implementar una función única, se debe realizar una investigación preliminar y, una vez implementada la función, se requiere un gran volumen de análisis, verificación y prueba. Es difícil resolver todos los problemas en un corto período de tiempo porque el esfuerzo y el tiempo deben invertirse constantemente en cada problema. La implementación incorrecta de nuevas características puede causar problemas mayores. Por lo tanto, las nuevas características deben implementarse y aplicarse lo más cuidadosamente posible. Dicho esto, después de aplicar las mejoras de las que ya hemos hablado, ahora estamos trabajando en la optimización de la etapa de "Despacho neto" del proceso. De acuerdo con nuestro análisis, la mayor parte del tiempo se consume en el procesamiento de movimiento de caracteres, y hemos identificado algunas oportunidades para optimizarlo. El movimiento de personajes tiene un gran impacto en el juego de PUBG. Por lo tanto, esta tarea requiere mucha atención cuidadosa para garantizar que las mejoras realizadas no afecten la forma en que los personajes se mueven de forma anormal, como el nerviosismo que describimos anteriormente. Ya estamos experimentando con algunas ideas y anticipamos que el tiempo requerido para la etapa de "Net Dispatch" disminuirá más del 50% del actual 41.8mseg si estas ideas no tienen que ser modificadas por lo que encontramos durante el proceso de prueba . Se espera que estabilizar la función después de implementar nuevas ideas lleve más de un mes, pero continuaremos trabajando rápidamente e implementando esto lo antes posible. El objetivo final es mantener siempre la tasa de tics del servidor en 30, desde 100 jugadores hasta el último en pie. Seguiremos trabajando duro para lograr este objetivo, de modo que podamos continuar brindando la mejor experiencia posible de Battle Royale para todos. Gracias, Sang-kyun Kim Jefe de Desarrollo, PUBG Amsterdam
×