Resumen realizado por Adamanter en
CE.
- ¿Cómo interfieren las soluciones a corto plazo con las soluciones a largo plazo en el desarrollo?Interfieren bastante.
Siempre trabajan pensando en el largo plazo pero dada la naturaleza de SC, que tienen que publicar parches cada pocos meses, están obligados a resolver problemas que en un desarrollo clásico no resolverían pues no es necesario.
Lo que hacen es publicar una primera versión "funcional" de cada "feature" e iterar a partir de esa base. El ejemplo más claro es la personalización de personajes que tenemos en el parche 3.0 que es muy básica y está lejos de lo que será en la versión final.
- Diferencia entre SV Culling (Serialized Variables Culling) y Network Bind Culling:El NBC no usa recursos del cliente (memoria, ciclos de CPU, etc) mientras que las SV (Variables Serializadas) ocupan memoria pero no usan ciclos de CPU hasta que la correspondiente entidad requiera ser actualizada, por así decirlo pasan a un estado "durmiente". En ambos casos esto se aplica a las entidades que están demasiado lejos del jugador y que no requieren actualización porque no las ve.
- ¿Desde cuando se están haciendo optimizaciones?Desde el principio.
A lo largo de todo el desarrollo se ha estado discutiendo formas de optimizar el rendimiento, sin embargo es algo que va evolucionando según se desarrolla el juego y afecta a todos los departamentos, no sólo a los ingenieros de red.
- ¿Cuanto os "cabrea" que la gente achaque al netcode todos los problemas de rendimiento que experimentan? (pregunta Discolando)Un montón.
La razón de que les cabree tanto es que pese a que es cierto que el número de entidades crece rápidamente con el número de clientes conectados (naves, cargamento, restos de explosiones, las naves manejada por IAs, etc.) y es lógico que la mayoría de la gente lo achaque al netcode, en realidad el problema es más de optimización en general, de todos los departamentos de ingeniería (gráficos, físicas, sonido, IA, etc.), esta es una de las razones del rework de las naves, si no la principal, es decir, reducir el número de polígonos (ndt: drawcalls, esta optimización se explicó en el AtV anterior) sin perder calidad gráfica.
(Discolando pone como ejemplo el caso de la Freelancer original que en memoria era mucho más pesada que la propia Idris).
- ¿Qué optimizaciones en el netcode son necesarias antes de introducir puntos de salto que conecten dos sistemas?Los sistemas van a funcionar como servidores independientes sin comunicación entre ellos (ndt: es la idea que tienen ahora) y probablemente usarán un sistema de migración entre servidores de forma transparente. La nave entrará en una especie de burbuja (ndt: supongo que se refiere a una región esférica en torno a los puntos de salto) que inicia la migración entre servidores y es puesta en el sistema de destino. Y aquí está el problema. Todos los sistemas tienen el mismo sistema de coordenadas con la estrella principal en el origen de coordenadas (punto 0,0,0) así que tienen que mover la burbuja en el sistema de destino asegurándose de que no hay colisiones con nada.
En definitiva tienen que hacer primero el sistema de migración entre servidores, y probarlo, antes de poder conectar dos sistemas estelares.
- ¿Cual es la optimización por venir que más os interesa y por qué?El Objects Container Streaming (streaming del contenedor de objetos) en el que trabajan para el parche 3.3 porque va a suponer una considerable optimización ya que el cliente sólo cargará y actualizará las entidades cercanas, por ejemplo, en Port Olisar se cargará el entorno cercano con lo que los tiempos de carga serán mucho más rápidos. Por otra parte el OCS va a suponer deshacerse de una buena parte del viejo código (ndt: obsoleto) con el que han tenido que lidiar hasta la fecha.
- ¿Que es el Object Container Streaming (explicación para tontos)?El Object Container es una lista de entidades (Objetos); por ejemplo, un planeta es una contenedor de objetos (en el hay jugadores, vehículos, edificios, etc) que en su mayoría, a su vez, son contenedores de objetos (un personaje lleva ropa y/o armadura, armas, herramientas, etc.)
El Streaming de contenedores de objetos es la carga dinámica de los contendores de objetos que uno ve. Si estás en una estación e invocas una nave estás cargando un contenedor de objetos (la nave), al subirte a ella y volar lejos de la estación ya no la ves y ese contendor de objetos (la estación) deja de estar en memoria (del cliente).
Resumiento, el OCS es la carga/descarga dinámica de todo lo que está en tu rango de visión, o deja de estar en dicho rango.
- ¿Son todavía posibles las batallas de flotas masivas?SI. (Ndt: rotundo)
(Ndt: Discolando pide elaboración de la respuesta).
Por un lado van a disponer de servidores con 72 núncleos, el 3.0 funciona con servidores de 16 núcleos por lo que pueden paralelizar mucho más, pero los demás departamentos (gameplay, físicas, sonido, etc) han de optimizar el uso de todos esos núcleos.
Por otra lado, siempre buscan los límites y están subiendo el listón constantemente, así que trabajan con el objetivo de tener la mayor cantidad de gente posible en el PU con la esperanza de alcanzar ese punto en el que la gente diga que está en una batalla masiva.
- ¿Por qué el SV Culling es menos problemático que el Network Bind Culling si son tan similares? (ndt: para el que pregunta)Porque las Variables Serializadas están en el cliente (ndt: ocupando memoria por lo menos), mientras que el NBC supone crear la entidad en el cliente y vincularla al servidor (ndt: decirle al servidor que ya está disponible en el cliente). Esto supone que, por ejemplo, estás viendo una nave que salta a la velocidad cuántica, por tanto se descarga de la memoria del cliente y deja de existir en el cliente, pero al volver, como no existe en el cliente, hay que volver a cargarla y causa una pérdida de rendimiento, razón por la que decidieron mover el NBC al parche 3.2 pues no querían penalizar más el rendimento del juego. Por tanto decidieron optimizar más el SVC para el parche 3.1.
Van a necesitar un tiempo para optimizar el uso del NBC pues aún necesitan determinar qué entidades realmente están disponibles (son visibles o lo serán en breve) y cuales no.
- ¿Es el Ping una barrera infranqueable?Lo es.
Los planes son usar una sóla instancia (shard) pero el ping es el gran obstáculo.
Por ejemplo, el ping medio entre australia y los EEUU es de 200 milisegundos, mientras que el ping medio entre Europa y los EEUU es de algunos milisegundos (ndt: en realidad no sé qué coño ha dicho y sólo distingo la palabra "miliseconds").
Barajan varias opciones, pero las dos principales son:
1.- Poner a todos los jugadores en un servidor equidistante geográficamente.
2.- Utilizar un servidor intermediario geográficamente equidistante a los servidores locales.
En general va a depender un poco de la situación.
En cualquier caso va a ser una tarea desafiante y primero tienen que desarrollar la tecnología y probarla para identificar claramente los problemas y abordarlos.
Para el caso del Arena Commander y Star Marine lo más probable es que funcionen a través de servidores locales para que todos los jugadores tengan bajos pings.
- ¿Es el NBC problematico para la implementación de, por ejemplo, mirillas telescópicas?Sí, lo es.
Ahora mismo el criterio que usan para decidir qué está en tu rango de visión o no es la regla de la uña del pulgar, es decir, todo lo que es más pequeño que la uña del pulgar, vista con el brazo extendido, es "no visible".
El problema es que las mirillas telescopicas reducen el campo de visión pero aumentan el tamaño de lo que está lejos complicando las cosas.
Tienen un problema similar con las comunicaciones (ndt: supongo que se refería a las comunicaciones con video RTT) ya que implican interactuar con entidades que no están en las proximidades del jugador y por tanto no son visibles.
- ¿Se hacen las optimizaciones pensando en un ámplio rango de PCs?Sí, no trabajan pensando en un tipo concreto de máquina. El código no se preocupa de si el PC es gama alta o gama baja, así pues los arreglos en el código son los mismos para cualquier PC, sean cuales sean sus especificaciones.
Esto se aplica también para los servidores, es decir, que las optimizaciones que hacen buscan ser beneficiosas tanto para los clientes como para los servidores.
- ¿Qué oiptimizaciones van a ser necesarias para resolver el problema de las sobrecargas de la CPU de los clientes?No tienen nada pensado todavía porque necesitan identificar primero qué es lo que causa esas sobrecargas (si es el código del juego, las físicas, la IA,..., todo ello junto). Es por ello que están desarrollando herramientas de telemetría que les den información más específica y concreta de lo que está pasando en los clientes cuando tienen esas sobrecargas o caídas de rendimiento.
En cierto sentido, van a pescar :)
(Lando sugiere que la solución es apagar las físicas, a lo que los desarrolladores responden que también podrían apagar el renderizador).
- ¿Están trabajando en la optimización de Escuadrón 42?Al ser un desarrollo compartido muchas de las optimizaciones que hacen para el PU benefician a la campaña.
Pero también hay optimizaciones más específicas al tratarse de un juego en solitario, por ejemplo entidades que en lugar de actualizarse 60 veces por segundo sólo haya que actualizar una vez por segundo.
- ¿Cuales son los problemas que impiden poner en el PU naves grandes como la Idris?En cuanto al código del juego el atraque (docking).
En cuanto a lo que es rendimiento, ya es posible ponerla pero necesitan tener en funcionamiento el OCS ya que el impacto en el rendimiento al cargar estas naves tan grandes es masivo.
