VÍDEO OFICIAL EN INGLÉSTRANSCRIPCIÓN EN INGLÉSn/d
RESÚMENES EN VÍDEO EN ESPAÑOLPunto de Salton/d
El Hangar de Marshial y AnubyssEl Hangar de Cuerdasn/d
Duddeyn/d
RESÚMENES TRANSCRITOS EN ESPAÑOLResumen realizado por Ñampazampa en Ciudadano Estelar.NOTICIAS GENERALES
1.- Empezamos el Noticiario comentando un poco el Roadmap y el estado actual del juego.
En el último Roadmap no tenemos grandes cambios, todo progresa adecuadamente rumbo a la 3.2, lo único que les falta terminar es el sistema de salto cuántico en grupo pero supongo que es cuestión de dias que lo terminen y lancen la 3.2 al Live.
Como sabeis, a dia de hoy la 3.2 está en PTU y cada pocas horas lanzan otra versión por lo que estad atentos al foro ya que el Live es inminente (a dia de hoy van por la letra "m"). Este viernes saldrá el nuevo Roadmap de la semana y es previsible que hayan empezado a meter mano a la 3.3, subiré el Roadmap al foro.
2.- El parche PTU 3.2.0 "L" parece ser que es un punto de inflexión en cuanto a rendimiento, se ha conseguido incrementar el tamaño de los grupos desde 8 jugadores en versiones anteriores a 64 jugadores! los crashes han desaparecido casi en su totalidad y los fps son aceptables (teniendo en cuenta que trabaja sin el Netcode terminado).
3.- Se ha hecho público un documento de 21 páginas creado por John Pritchett (Programador de RSI en cuanto a fisicas) donde se explica detalladamente el sistema de vuelo desarrollado durante estos últimos 5 años (el ya conocido como IFCS o intelligent flight control system).
Para quienes no sepan qué es el IFCS creo que es mejor explicarlo con un ejemplo y algo de culturilla aeronautica. En la vida real hay aviones militares que por su propio diseño son inestables por naturaleza, sobretodo aquellos que tienen las alas en flecha hacia adelante (como el Rework de la Mustang). Esta inestabilidad les confiere una maniobralidad excelente pero por contra requieren de una CPU y sensores que hagan lecturas del vuelo para que la CPU pueda interpretar esos datos y hacer rectificaciones "al vuelo" para compensar esa inestabilidad, esa CPU de la que hablo es lo que sería el sistema IFCS en la ficción del Star Citizen, es la CPU que gestiona cada uno de los impulsores de la nave, decidiendo la orientación y potencia apropiadas para que la conducción de la nave sea fiel al pilotaje que le demos con independencia de la aerodinámica de la nave.
El mejor modo de apreciar los efectos del IFCS es cuando tenemos una nave sin un ala.. el IFCS hace todo lo posible para compensar esa falta de impulsores del ala mediante una buena gestión de los demás impulsores de la nave, por supuesto se nota que la conducción empeora pero es pilotable aun así, cosa que no ocurriria sin un IFCS.
Dejo el link del documento del IFCS aquí, lo podeis descargar, es un enlace de confianza:
https://drive.google.com/file/d/1poxfPYfm32r84G4WWWJ6uK-rU6ijl85g/viewEl documento está en un inglés relativamente friendly, viene con ilustraciones, gráficas, algunas ecuaciones y esquemas que facilitan su lectura, aunque en algunos puntos se requiere entender un poquito de fisica newtoniana y dinámica de fluidos pero a nivel basico, abajo viene la bibliografia y links de ayuda. Lo considero un documento de gran valor para aquellos pilotos que quieran entender realmente el funcionamiento de las fisicas, una vez se lea y entienda, tu pilotaje nunca volverá a ser el de antes.
Me encantaria traducirlo porque es muy interesante pero son 21 páginas, quizá en el futuro haga algún suplemento comentando algun punto en concreto del documento, como el modelo newtoniano del sólido rígido de 6 grados de libertad que es la base para todo lo demás. Es lo que explicó Christ Robert en esos primeros videos de SC donde hablaba de las fisicas newtonianas mientras disparaba con un laser a una nave y se reia.
Por último, dejo abajo un video donde explican la principal información extraida del documento anterior del IFCS, siento que esté en inglés, si la comunidad hispana hace este mismo video en español lo sustituiré pero de momento es lo que hay.
4.- Se realizó una entrevista a Eric Roberts (el que se encarga de SQ42 y hermano de Christ Robert) en el que se tratan algunos temas. Si quereis la fuente original está arriba del noticiario, fuente nº 4, si el link no carga insistid, a veces se queda pillado.
La entrevista es larga y no puedo traducirlo todo pero si puedo comentar un poco lo más relevante. Hablan para los nuevos jugadores que no hay pantallas de carga, tambien sobre las implicaciones de las versiones 3.0, 3.1, 3.2 y 3.3 en cuanto a tecnologias y relevancia en el desarrollo del proyecto, tambien hablan de las tecnologias del Netcode y lo más relevante, que se estima que para el año que viene puedan albergar entre 100 y 1000 jugadores jugando en el mismo servidor (supongo que la cifra irá aumentando más conforme optimicen el código).
5.- Los de RSI han subido un nuevo video de la Avenger, la Aegis Eclipse, la Hurricane y la Vanduul Blade . Aqui lo pongo en ese orden.
CALLING ALL DEVS1.- ¿Como va el progreso en el desarrollo de los subcomponentes en las armas de mano y de las naves?Pues comentan que el sistema de objetos 2.0 ya está creado y funciona correctamente a nivel de programación, pero queda acabar dicho sistema a nivel artístico de cara a los jugadores, es decir, crear los subcomponentes y sus animaciones para luego implementarlas al juego.
Recordemos que este sistema 2.0 permitirá a los desarrolladores modificar a placer los atributos de las armas (y otros componentes) y capacitarlos con modularidad de forma que estos componentes permitan el acoplamiento de subcomponentes que modifiquen cualidades del componente en sí, un buen ejemplo seria poder acoplar a un rifle una mirilla, ponerle un cargador con más capacidad o un puntero laser.
2.- ¿En qué punto del desarrollo estamos para la implementación de los subcomponentes que comentamos en la anterior pregunta?No dan fechas sino que vuelven a explicar lo anterior, dicen que a nivel de programación la infraestructura está terminada pero que falta diseñar cada subcomponente y sus animaciones para incorporarlas al juego. Cuando esto se consiga, podremos dotar a cada componente (tanto de nave como de campo) con subcomponentes especificos que alteren sus cualidades, por ejemplo podremos acoplar a la planta de energia un subcomponente para disminuir su huella electromagnética a costa de cierto rendimiento (underclock) o podremos modificar la refrigeración de lar armas, su cadencia de fuego, su dispersión, alcance etc
3.- ¿Hay planes para castigar los "griefeos" y no a los piratas?Para los que no lo sepan, griefear es básicamene acosar a alguien malintencionadamente matándole una y otra vez de forma sucia esperando a que salga de nuevo para volver a matarlo y arruinar su experiencia en el juego, sabotear el respawn de su nave, el del jugador y en definitiva hostigar de forma poco honorable a otra persona. Este comportamiento tiene obviamente una inteción poco deportiva y muy diferente a la pirateria, cuyo proposito es el beneficio propio y no tanto el perjuicio de la otra persona. La pirateria es parte del juego y está aceptada, tiene que haber malotes que engrandezcan la victoria de los buenos (o no) pero otra cosa muy diferente es el grifing.
Entrando en el tema, nos comentan que actualmente hay un sistema de leyes (muy básico) pero que con el tiempo irán puliendo de forma que constituirá una primera barrera ante el grifeo, pero aqui surge una cuestión.. ¿qué linea separa la pirateria del grifeo? aqui es donde surgirán los GM (game masters) que serán la 2ª barrera ante el grifeo y harán de moderadores del juego atendiendo a los informes de reporte que podremos mandar en caso de alguien nos grifee y enfocandolos desde un punto de vista humano, digamos que serán como los jueces del verso en estas cuestiones (entre otras funciones).
Por último, cuando el juego esté mucho más avanzado, la intención es automatizar esa función en concreto que hacen los GM e incorporar una 3ª barrera en la propia programación del juego que gestionará automáticamente este tema penalizando los comportamientos de grifeo, pero claro.. ¿donde trazamos la linea entre pirateria y griefing a nivel de código? esto a nivel de programación es MUY dificil ya que es complicado realizar un juicio de valores del comportamiento humano y ademas puede dar lugar a falsos positivos. La linea entre la pirateria y el grifeo debe de estar muy bien definida, asi que ya se verá que pasa más adelante con el tema, pero a dia de hoy su intención a largo plazo es esa.
4.- ¿Se está trabajando en animaciones de naves chocando contra la superficie terrestre?No, no es algo que hayan hablado y no se espera que se lleve a cabo al menos en el corto plazo.
5.- Si las naves grandes no pueden maniobrar como las naves pequeñas ¿Por qué no pueden disparar desde más lejos para compensarlo?La respuesta es ambigua, comenta que el sistema de objetos 2.0 ya está implementado en la 3.2 y el sistema de daño de las armas tendrá una gestión del DPS (daño por segundo) totalmente diferente ya que ahora depende de la energia de la que dispongan, de la refrigeración, de la inercia en la cadencia de disparo, el estado del arma etc
Respondiendo a la pregunta, se ha incorporado un gran cambio en las armas por lo que esperemos a ver como se balancea el asunto, es pronto para responder.
AROUND THE VERSE1.- El Around The Verse de esta semana tenemos un ATV de solo 12 minutos que se centra en el equipo de desarrollo y en ponernos al dia con el proyecto de SQ42.
Empieza hablando el director creativo Nick Elms diciendo que será dificil enseñarnos como va SQ42 sin spoilearnos partes importantes de la historia pero que están haciendo grandes progresos y nos van a enseñar algunas muestras del mismo a lo largo del ATV.
Nos comentan que SQ42 se compone de muchas tecnologias trabajando juntas, algunas de ellas son pioneras y no existen todavia pero están en ello. Este mes se han centrado en las diferentes animaciones de movilidad como saltar, girarse, agacharse, escalar etc para estar seguros de que los tiroteos y la exploración sean fluidos y divertidos.
2.- Un diseñador nos dice que las animaciones como saltar, subir muros, agacharse y eso aun le queda algo de trabajo por delante, tienen que pulirlas un poco para que la experiencia del jugador sea verdaderamente satisfactoria tanto para el jugador en primera persona, como para otra persona ajena a nosotros que nos esté mirando.
3.- El equipo de personajes ha estado mejorando los NPC y su IA para que automaticamente realicen las animaciones más adecuadas a las circunstancias correspondientes. La idea es que sin importar la situación en la que esté el personaje, en cuanto deje de tener instrucciones que determinen su comportamiento, el "sistema inactivo" tomará el control de estos NPC para manejarlos y darles animaciones que sirvan como "comodin" y así no romper con la inmersión, me explico.
Cada NPC tiene asignada una lista de acciones y animaciones que llevará a cabo (reparar tal cable en cierto pasillo, ir a comer, irse a dormir tras su jornada laboral etc) pero habrá ocasiones en las que un NPC se quede sin instrucciones, por lo que se quedaria como un maniquí con los brazos en cruz.. (modo dios lo llaman) asi que para evitar esa ruptura de la inmersión pues el sistema inactivo controlará estos NPC diciendoles que realicen animaciones comodin, como mirar el moviglas, bostezar, mirar las naves que pasan por la ventana, sentarse en la silla más cercana, quitarse cera del oido con la llave de su Caterpillar, lo tipico.
4.- El equipo de ingenieria ha estado trabajando en la tecnologia cinemática procedural inversa. (mas adelante pongo un video donde se explica graficamente) Nos cuentan que la tecnologia procedural es una herramienta muy poderosa en el diseño de Star Citizen ya que mediante algunos algoritmos se pueden dar solución a todos las posibles problemas de un mismo tipo, concretamente en el ATV se centran en el sistema de "agarre" de objetos.
Es evidente que no cojemos de la misma forma una tablet que una lata de refresco o una bengala, por ello en lugar de elaborar una animación especifica para cada tipo de objeto, lo que han hecho es crear un algoritmo procedural que dependiendo de la forma del objeto en sí, el personaje lo agarra de una determinada manera. Tened en cuenta que en SC habrá multitud de objetos, y si se pusiesen a crear una animación de agarra para cada uno.. seria una pérdida de tiempo, recursos y dinero.
En el video de abajo podeis ver algunas de estas animaciones procedurales de "agarre" a diferentes objetos. Tambien nos muestran como estos objetos que cojemos podemos tocarlos, manejarlos y rotarlos para observarlos desde casi todos sus ángulos.
5.- A continuación nos hablan del trabajo realizado por el equipo en referencia a la inspección de objetos mediante su manipulación (lo que deciamos antes). Podeis verlo por el minuto 5:12 (usad el video de arriba). Este trabajo tiene implicaciones más alla de lo mencionado, va a capacitarnos poder interactuar con multitud de nuevos objetos y subcomponentes de forma que el entorno sea mucho mas interactivo.
6.- El equipo de armamento está trabajando en un lanzacohetes Xi`an (minuto 6:14) lo veremos en SQ42 aunque no precisa si en el PU también (tendria sentido que si). Dicen que es el primer arma alienígena con el que empezaron a trabajar y que fue algo nuevo para ellos. Intentaron que el arma aparentase ser realmente pesada y del mismo tamaño que la Railgun.
7.- El equipo de efectos ha estado trabajando en un protopipo procedural de "formación de cuerpo blando" (procedural soft-bodied formation, no encuentro una traducción decente, sorry) es decir, están creando un sistema que determine como pueden deformarse las texturas sin que se requieran demasiados recursos, esta tecnologia jugará su papel a la hora de abrir brechas en los cascos de las naves y bases.
Personalmente es toda una sorpresa ya que tenia entendido que todas las entidades serían "solidos rígidos fragmentables" pero resulta que van a simular deformaciones en las texturas. Lo que no tengo claro es si será solo un "truco" visual (un shader) o si en verdad la entidad y su geometria quedará deformada a todos sus efectos. Bueno tras este parentesis, sigo con el ATV.
Nos cuentan que hay 2 métodos para deformar las entidades, el primero requiere por parte de los desarrolladores determinar la ubicación de la fractura inicial de la estructura, seria como si dibujaramos en una pared con un pincel donde va a fracturar esa pared, una vez determinada la fractura inicial, se indica la fuerza y geometria del objeto de impacto y la herramienta calcula la deformación. (lo podeis ver en el minuto 7:05 en adelante, haced click aquí)
Este es el antes y el despues usando el primer método.
El 2º método aunque es más consistente, requiere un mayor uso de la memoria, el método es llamado GM cash (lo podeis ver en el minuto 7:34)
8.- El jefe del equipo de accesorios bromea diciendo que no es frecuente asociar al equipo de accesorios con la palabra basura, pero en este mes sí, ya que han estado trabajando duro con el diseño de la basura que podremos encontrar en multitud de espacios abandonados del verso.
A continuación uno de los desarrolladores de accesorios comenta que ha estado trabajando en los montones de basura y estos tienen una mezcla de sustancias (que hace de substrato) y objetos distribuidos en esa base de manera procedural. Aqui podeis ver una pequeña demostración.
9.- Tambien han estado trabajando en las armaduras Vanduul, comentan que debido a la naturaleza Vanduul, sus armaduras tienen influencias de otras razas (que posiblemente exterminaron y cuya tecnologia absorbieron) pero sin embargo tienen una apariencia única y característica.
Tambien nos hablan de las armas de los Vanduul (minuto 9:08), ellos no usan pistolas y rifles sino que se centran en objetos con forma de lanza o de cetro, tambien usan cuchillos y dagas, más adelante del video aparecen y tienen muy buena pinta. Eso es todo lo del Around The Verse, por últivo, al final del video aparecen las hijas de Christ Robert despidiendo el ATV jejej (aunque no hacen el "See you.. arooound the Verse")
