❇️ Star Citizen - Respuesta de Dev #2
Saul "Havok" Specter
Selección periódica de respuestas ofrecidas por desarrolladores de Cloud Imperium Games resolviendo cuestiones de interés.
🔹 Cambios en Arena Commander y Star Marine
12 Septiembre 2020
- La mecánica de la frontera (ntd: la red que bordea los mapas de arena commander) no se adecua al modelo de vuelo actual. Cuando la ves, es demasiado tarde para reaccionar, la mayoría de las veces. Creo que se podría crear una frontera que se pueda atravesar y darnos tiempo (10 a 20 segundos) para volver a entrar, podría ayudar mucho.
La holosfera está siendo reemplazada por una nueva mecánica de "área de juego", donde puedes alejarte del límite y tener X cantidad de segundos para volver en vez de destruirte al instante. Lo más probable es que encuentres esto con la 3.12
- Ya que somos bastante lentos actualmente, la distancia de escape a un "escondite" parece bastante larga. Creo que deberían añadirse algunos obstáculos más (no demasiados). Además, sería divertido tener la sensación de un cinturón de asteroides en AC, tal vez sólo en una esquina del mapa.
Con el cambio mencionado arriba estamos aumentando el espacio de juego para el mapa de Broken Moon (En Dying Star ya fue aumentada) con esto estamos buscando hacer ese espacio de juego un poco más interesante.
- Necesitamos un nuevo mapa atmosférico.
Estoy de acuerdo - Antes de hacer nuevos mapas de AC queremos actualizar los actuales como hicimos con Star Marine + The Good Doctor. Hemos estado experimentando con algunas cosas, pero ahora mismo el foco es Theaters of War.
- Las recompensas de RECs para las carreras están rotas. Como las carreras son un modo de juego que no se juega mucho en realidad, tal vez debería dar la mayor cantidad de REC para atraer a los jugadores que lo prueben.
Los puntos en los modos de carrera se dan por premios que aún no han sido refactorizados. Puedes esperar un cambio en los puntos REC de las carreras cuando el refactorizado esté hecho. Podríamos aumentar el multiplicador de puntuación/rec para el modo pero creo que los modos de carrera necesitan mucho más trabajo aparte de la puntuación. Fueron hechos para un sistema de vuelo que está bastante lejos del actual y no se les ha mostrado mucho amor desde entonces.
- Para el Vanduul y el Pirate Swarm, creo que los daños excesivos todavía cuentan. Es un gran problema, ya que puedes conseguir buenos puntos para la leaderboard jugando la nave meta o el arma meta. Claro que siempre hay armas que son mejores, pero esta vez, hay peores armas que dan más puntos. Eso no tiene sentido. Los puntos deben ser calculados con el daño recibido/tiempo (sin excesos de daño) y la proporción de daño durante la partida. O tal vez sólo contar el tiempo de la partida!
Esto no debería ser cierto. La puntuación se refactorizó hace un tiempo donde eliminé algunas matemáticas dudosas e hice que la puntuación se extrajera de un fondo de puntuación por nave basado en el daño causado. Es decir, el objetivo vale 1600 puntos. Si infliges el 100% del daño deberías acercarte mucho, si no exactamente, a 1600. Recibirás una bonificación por matar y si hay varias personas que contribuyan a los asistentes se les dará una bonificación basada en su contribución al daño, pero para la puntuación del daño nunca debes superar el valor de la nave. - Lo mismo ocurre con las muertes en Star Marine. Si has encontrado una manera de superarlo, por favor, asegúrate de informarlo en el Issue Council.
- Hay un problema general en Arena Commander, que después de terminar un juego, intenta cargar uno nuevo que nunca funciona. Te quedas atascado en la pantalla de carga. Como ya no puedes salir, tienes que hacer alt-f4 y volver a cargar el juego.
¡Eso es preocupante! ¿Es esto realmente siempre el caso? Por favor, informa y contribuye al Issue Council y el bug llegará a mí. Es posible que esté arreglado para la 3.11, pero estaré atento a ello.
- Ofrezco otra opción para estar fuera de los límites en Arena Commander, cuando vuelas fuera de la Arena, restar puntos por segundo y de forma algo agresiva para obligar al jugador a volver a entrar lo antes posible, incluso no te molestes en hacerlos explotar pero si lo haces después de 20 segundos así se le habrá bajado la puntuación por ser travieso.
Deducir puntos por segundo no es una mala idea. Lo plantearé en el diseño. Ahora mismo, cuando dejes el área, si no vuelves en el tiempo asignado, explotarás; esa muerte cuenta como un suicidio. En la muerte, la puntuación restante de tu nave se distribuye entre todos tus atacantes (dentro de un marco de tiempo razonable) basado en su contribución de daño hasta ese momento - es decir, yo hago el 30% de daño, tú haces el 10%, yo seré premiado con un 45% adicional y tú con el 15%. Hemos estado hablando de añadir un tipo de puntuación "Assist as Kill", donde si has contribuido con suficiente daño (digamos más del 80%) y el objetivo muere por otros medios, aún así se te concede la muerte, con suerte podrás jugar con eso cuando los premios sean refactorizados.
Además, como la muerte cuenta como un suicidio, al jugador que está fuera de los límites se le descuenta una puntuación fija (la misma que perderías si te estrellaras contra algo y murieras).
En cuanto a no hacerlos explotar, a diferencia de Theaters of War, donde queremos dar libertad para extrañas y maravillosas dogfights, este es un modo de juego centrado en la arena, no creo que permitir jugar fuera de los límites normales sea saludable. No es mi decisión, pero me imagino una meta para la gente que no se preocupa por los puntos fuera de los límites. Estoy seguro de que es una discusión que el control de calidad y el diseño tendrán en algún momento durante las pruebas de juego.
@Duncan-CIG
🔹 Server Meshing
13 Septiembre 2020
¿Se está explorando el server meshing desde la perspectiva de los principios básicos?
No puedes separar un esfuerzo técnico del contexto en el que funciona. Se me ocurren muchas formas diferentes de crear algún concepto de malla de servidores, pero la única que importa es la que resuelve los problemas del juego que tenemos. Tenemos que tomar muchas decisiones a lo largo del camino sobre cuestiones como "¿cómo debemos cambiar fundamentalmente el juego?" y variaciones de enfoques con compensaciones de tiempo. Puede ser interesante considerar cómo hubiera sido si escribiéramos el motor desde cero con esto en mente en lugar de modificar el motor que tenemos, pero al final no suponen mucho más que una interesante introspección porque la verdad es que tenemos el motor que tenemos y el calendario que intentamos cumplir.
Como un inciso, sólo brevemente como programador, veo que hay muchos que piensan así e intentan ver las cosas desde un punto de vista demasiado abstracto, pero no creo que sea el enfoque más productivo. La mejor solución es la más directa al problema que tienes. Para cualquier programador que quiera saber más sobre lo que eso significa en la práctica, le animo a que se familiarice con el Diseño Orientado a los Datos
@CIG_ChadMcKinney
14 Septiembre 2020
¿Qué ocurre cuando viajas entre las "mallas" del mallado de servidores (server meshing)?
Una malla particular de servidores (lo que llamamos un fragmento o "shard") está completamente encerrado entre sí, y no se puede pasar automáticamente de un fragmento a otro. Son simulaciones independientes, con su propia visión del estado persistente del mundo.
@CIG_ChadMcKinney
🔹 Client Side OCS
13 Septiembre 2020
Leí que el Client Side OCS permitía al motor saltar los ticks de actualización para ciertas entidades en base a la distancia del jugador. Cuanto más lejos esté una entidad, más ticks se saltan. ¿Significa esto que para esa entidad la tasa de ticks de actualización en el bucle de juego se reduce en el servidor, o sólo se refiere a la tasa de ticks de actualización de la red al cliente del jugador?
El Client Side OCS nos permite transmitir entidades en los clientes para que no se actualicen en absoluto y esto no afecta al comportamiento del servidor en nada... Hay un sistema de actualización de componentes de entidades separado que se encarga de la actualización de las entidades generadas, y esto permite muchas configuraciones diversas para optimizar el rendimiento, incluyendo la distancia a los jugadores, la visibilidad de los jugadores, los rangos de tiempo, etc., pero esta política de actualización será la misma en el servidor y en el cliente para cualquier componente de la entidad.
Una cuestión similar: ¿el propio cliente del jugador simula las entidades cercanas como lo hace el servidor del juego y retrocede/suscribe ciertos estados cuando el estado entre el cliente y el servidor ya no se alinean (lo que conoceríamos como rubberbanding o desync), o el cliente del jugador simplemente recibe el estado cambiado de las entidades del servidor y actualiza su propio estado sin simular también su propio estado? Si esto último es el caso, ¿el próximo Rework al Actor Networking es un paso adelante hacia lo antes mencionado?
Los sistemas más sencillos se ajustarán al estado del servidor en el cliente, pero los programadores siempre pueden hacer sistemas más sofisticados que manejen cosas como la interpolación, etc..., para hacer que el comportamiento del cliente parezca más natural. Y sí, esto es parte del trabajo para los cambios en el Actor Networking. El movimiento y la animación de los jugadores es algo en lo que la gente está muy acostumbrada a ver fallos (somos humanos después de todo) y conseguir que se vea natural y fluido es un montón de trabajo. También hay que tener en cuenta el impacto en la jugabilidad, por ejemplo, la implementación de los cálculos puede acabar favoreciendo a los que disparan en lugar de a los que reciben los disparos, donde se produce una discrepancia en el servidor.
@CIG_ChadMcKinney
🔹 Persistencia de los avatares
13 Septiembre 2020
¿Cuándo llegará la persistencia para el personaje?
Con el icache y la persistencia global, mantendremos los historiales de los servidores/shards más allá de la vida útil de los mismos, y esto nos permitirá hacer cosas como la restauración completa después de una caída del servidor. Esto puede que no sea parte del primer lanzamiento del sistema, pero es algo que hemos tenido en cuenta a lo largo de nuestro diseño e implementación.
En cuanto a la carga, además del comportamiento global de persistencia/reconexión, hace tiempo que tenemos la intención de tener un seguro de carga y de artículos para protegeros más contra el comportamiento del juego y los errores. Por eso cuando introdujimos más persistencia en las naves en la 3.0 incluimos el seguro de naves en la misma versión, de lo contrario los bugs y los choques habrían sido demasiado castigados. Esta es también otra razón por la que introdujimos la base de datos LTP (Long Time Persistence).
@CIG_ChadMcKinney
🔹 Máquinas expendedoras
13 Septiembre 2020
¿Las máquinas expendedoras funcionarán algún día?
Se ha trabajado en las máquinas expendedoras para cosas como las prisiones, y hay más trabajo por hacer para el comportamiento general de las máquinas expendedoras.
Una buena opción sería añadir la persistencia de los artículos en las naves, para que podamos dejar agua y comida almacenada en nuestras naves.
Esto ya funciona aunque ocurran algunos bugs todavía.
@CIG_ChadMcKinney
🔹 Optimización de CPU
13 Septiembre 2020
https://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/cpu-optimization-work/3372425
¿Aprovechará el juego las CPU con muchos núcleos como el AMD 3900X que tiene 12 núcleos?
En términos generales el juego es muy multihilo, de lejos el juego más multihilo en el que he trabajado, y sí, más núcleos funcionarán mejor. Esto también mejorará a medida que el juego se desarrolle, ya que estamos constantemente intentando que el juego funcione más en paralelo. Dicho esto, la mejora no se corresponde linealmente con el número de núcleos (y según la ley de Amdahl no se puede mantener de todos modos https://en.wikipedia.org/wiki/Amdahl%27s_law), así que no me gustaría hablar de números exactos.
@CIG_ChadMcKinney
🔹 Estrella de Stanton
17 Septiembre 2020
https://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/stanton-star/3382451
¿Se pueden dar detalles de los planes con la estrella de Stanton? Si podremos acercanos, si tendrá erupciones, si tendrá efectos sobre las naves, etc.
No conozco los planes completos pero mientras trabajamos en Pyro queremos que el sol sea más importante, probablemente de alguna de las maneras que dices. No conozco ningún detalle específico que pueda decir, pero sé que hay trabajo planeado para mejorar las estrellas. Si hacemos que la estrella de Pyro sea realmente bonita, también inspirará una mejora de la estrella de Stanton.
@JakeDunlopCIG
🔹 Rest Stops
17 Septiembre 2020
Los antiguos rest stops también molaban, de tamaño más pequeño ¿volverán algún día?
Las viejas estaciones eran de procedimentales. Para explicarlo de una manera muy fácil es que las viejas estaciones encajan como piezas de rompecabezas, las nuevas encajan más como piezas de lego. Las nuevas estaciones tienen mucha más libertad para cambiar su forma y añadir nuevos segmentos en cualquier momento (como lo que estamos haciendo con los Cargo Decks). Añadirlos al viejo sistema habría sido difícil.
Las nuevas estaciones también permiten que los hangares se puedan acoplar, todavía tenemos plataformas de aterrizaje pero principalmente los hangares son mejores para que podamos hacer spawn y despawn de naves sin que nadie lo vea (¡inmersión! + consume menos renderizar menos naves).
Por último, apenas hay espacio en las viejas estaciones, por lo que generar un interior en un área tan pequeña es muy limitante. Una vez que hayamos creado los nuevos exteriores de la estación, mucho más grandes, podremos crear cualquier diseño que queramos. También hicimos algunas habitaciones más anchas debido al espacio extra, pero no demasiado anchas para que nos llevara una eternidad recorrer las estaciones.
Si quieres saberlo, las nuevas estaciones no sólo utilizan el trabajo nuevo, sino que reutilizamos algunas de las estructuras de las viejas estaciones para ayudar a construirlas.
@JakeDunlopCIG
🌐Historial🌐