Star Citizen #HG

RECORDATORIO:

ESTE HILO ES PARA SEGUIR EL DESARROLLO Y AVANCE DE STAR CITIZEN. PARA CRITICAR EL DESARROLLO; P2W, FECHAS DE LANZAMIENTO, BUGS Y DEMÁS, PODÉIS IR A ESTE.

En caso contrario el castigo puede conllevar un Punish.

¿Diferencias de un hilo u otro?

  • Este hilo es para hablar de temas ceñidos a la actualidad del juego, noticias, dudas, etc. Y aunque el debate sano siempre es bienvenido, la intención es dejar el hilo limpio para tal propósito. Por lo tanto la moderación en este hilo será más estricta.
  • El hilo de Off-Development está para soltarse más, donde la moderación será menos estricta y se permite tocar, criticar o debatir temas que eran fruto de discusiones que ensuciaban el principal objetivo de este hilo, incluyendo todo aquello relacionado con el desarrollo. Allí vale más "todo", exceptuando faltas de respeto y las normas generales de Mediavida.

DATOS DE INTERÉS (Actualizado 15/11/2018)

PINCHA PARA DESPLEGAR
ayls

#18089 es que se tropieza con la parte baja de la puerta XD

2
ro_B0T_nik

No hay links de descargar directa o algun FTP? Porque tela, no vale con volver a descargar todo el juego sino que encima esta saturadisima la descarga.

1 respuesta
LimiT-SC

#18092 El truco es deshabitar el p2p. No he oído nada de servidores saturados. Yo me lo he bajado esta mañana y me ha dado el máximo de mi linea.

1 respuesta
Adamanter

Yo lo tengo con P2P y me va a tope.

Salu2 :)

ro_B0T_nik

#18093 Pues sera cosa mia pero vamos, esta bajando a unos tristes 150kb/s y si pongo cualquier otra cosa a bajar se descarga al maximo sin problemas (2MB/s)

clethaw

Hola buenas tardes, vengo a presentaros los puertos. Si puertos, no esos de los barcos, los de informática.

xDD

FrostRaven

7 1 respuesta
joked9

#18097 se podrá ser en el sc como esos que te limpian los cristales en los semaforos y les tienes que pagar si o si?

1 respuesta
FrostRaven

#18098 ¡Por supuesto!

spoiler
Xeros_Grey

http://gfycat.com/GraciousFavorableFlatcoatretriever

1 respuesta
L

#1 entonces para tener el juego basta con comprar una nave?
Y si es para hacer un regalo, ¿cómo lo hago, lo compro y envío a una cuenta?
Gracias :)

1 respuesta
Rigal01

#18100 Esa camara está guapisima para el modo espectador. En plan si te han matado poder ver a tus compañeros de party pero sin poder ghostear.

FrostRaven

#18101 Basta con comprar un package de la lista de packages en la Pledge Store, todos traen el juego más una nave inicial. En Datos de Interés en este hilo tienes los tres packs más baratos a la venta ahora mismo linkeados, como pone ahí yo te recomiendo la Aurora LN. Usa mi referral o el de otra persona al crear tu cuenta para que te den 5.000 UECs adicionales, por cierto.

Si quieres comprar un package para un amigo hazlo de la manera habitual, que te de su email y desde la sección My Hangar de tu cuenta seleccionas el package, le das a la flecha de la derecha azul para desplegar botones y luego le das a gift. Sólo necesitas su email para enviar un regalo.

1 respuesta
L

#18103 mil gracias!!!!!!!

D

Esperate a la venta que se hará el próximo 19 de noviembre ,que a lo mejor sacan a la venta la aurora mr aniversario .

1 comentario moderado
FrostRaven

1- Como productores tenéis la oportunidad de echar un vistazo en profundidad al juego y a la gente que trabaja en sus diversos sistemas. ¿Hay algo que siempre quisisteis hacer (u os gustaría poder hacer) si tuvieseis las habilidades apropiadas? ¿En qué os gustaría trabajar?

Eric Kieron Davies: Si habéis visto el Meet the Devs, mi trasfondo estaba en animación y cuando salí de la Facultad quería ser animador. Conseguí el grado de Animador e Interpretación... todo lo que necesitaba para obtener una sólida animación de un personaje. Y ese era el camino que yo seguía... Así que para mi, me gustaría meterme en el lado de animación de interpretación y personajes para transmitir una historia. Me encanta contar una historia.

Darian Vorlick: Así que este es tu Papel Protagonista como Productor Senior... (risas)

Eric Kieron Davies: (risas) Supongo...

Darian Vorlick: Te has entregado a ti mismo el papel de Productor Senior y ese es tu guión... (risas)

Eric Kieron Davies: Si, por supuesto. ¿Y tú?

Darian Vorlick: Probablemente el aspecto de escritor y de la ficción del proyecto. Dada mi trayectoria como editor me encantaría ser un Administrador de Proyecto vigilando como se desarrolla la escritura. Crear una mitología es algo que me parece muy interesante. Tengo un amor muy arraigado por las publicaciones impresas tradicionales. Hay algo romántico y clásico en sujetar un libro entre tus manos y saber que tú tuviste algo que ver en su creación. Pero... bueno, me gusta en realidad lo que hago, interactuar con los desarrolladores e ingenieros. Es diferente de cualquier otra cosa que haya hecho y me gustan las cosas nuevas.

Eric Kieron Davies: Ahí tenéis nuestra respuesta.

2- Como productores supervisáis el desarrollo del proyecto y coordináis las diferentes disciplinas (Arte, Diseño etc) para unificarlo en un producto acabado para el juego (una nave, localización, etc); pero para hacer esto debéis poneros al nivel de detalles del proyecto. ¿Cómo hacéis para mantener las distancias y el objetivo final frente a perderos en la "conejera" de los detalles? Dadnos un ejemplo.

Darian Vorlick: Hemos estado esperando y preparándonos para responder a esta pregunta.

Eric Kieron Davies: Es muy difícil. Más adelante hablaremos sobre esto; pero la idea es contratar a nivel de producción a gente con diferentes especialidades y gustos para que te proporcionen diferentes perspectivas. Si es algo técnico es mejor tener a algún productor que controle en esos aspectos para darte las respuestas. Como Darian dijo en un mensaje: "conoce lo suficiente para ser peligroso".

Darian Vorlick: Si. En realidad esa cita es de Jason Hutchins.

Eric Kieron Davies: Totalmente cierta. En general, depende en lo que te tengas que meter. Es bueno tener un plan general y un calendario que haces con tus jefes de departamento, pero en cierto sentido tienes que meterte en los detalles para profundizar. No deberías hacer sólo una de las cosas, si no ambas en el momento apropiado.

Darian Vorlick: Cuando empecé aquí yo no era un programador o un ingeniero, por lo que había una sensación de estar fuera de lugar al llegar. No estaba seguro de que podría hablar al nivel necesario para comunicarme con los diseñadores y los ingenieros; pero a base de pura saturación siento que puedo tener una conversación semi-inteligente sin tener que utilizar señales y gruñidos. Ser capaz de tener una conversación sobre el sistema de objetos o el sistema de tokens de identidades. Debemos ser capaz de hacer preguntas sobre cómo va el progreso de algo y saber cuando algo nos está, en cierto sentido, engañándonos para poder anticipar las necesidades de esa disciplina. No hay que ser expertos en ella para poder tener una conversación sobre ellas y administrarlas.

Eric Kieron Davies: Para daros un ejemplo, tenemos el sistema de tokens de identidades. ¿Cómo lo administraste?

Darian Vorlick: Tuvimos una conversación esta mañana con el programador de Reino Unido, Stephen Humphries, que está escribiendo la secuela de GOST: el sistema de tokens de identidades. Yo no se hablar gráfico de flujos en CryEngine; pero como sé lo suficiente sobre lo que quieren lograr con este nuevo sistema puedo prever sus necesidades o si alguien abandonase esta parte del proyecto qué podemos hacer para solucionarlo. Saber quien tiene qué habilidades es útil para llenar ese vacío.

Eric Kieron Davies: Saber equilibrar vista general y detalle es la propia razón por la que existen los productores. Somos la perspectiva externa del proyecto y por lo tanto, de manera intrínseca, esto nos permite tener esta vista de pájaro que nos permite entenderlo.

Darian Vorlick: A veces tener conocimientos técnicos es una hoja de doble filo, porque te puedes poner sin darte cuenta a corregir errores del código o diseño en vez de administrar y coordinar a los programadores y diseñadores que se deberían dedicar a ello.

3- ¿Cómo hacéis estimaciones de tiempo en situaciones en las que aparecen "bloqueadores técnicos"?

Darian Vorlick: No es un problema especial respecto a otros problemas de desarrollo. Simplemente preguntamos al experto cuanto tiempo creen que les llevará respecto a cosas similares que ya han hecho en el pasado y nosotros como productores miramos la escala de lo que hacen para hacer el ajuste proporcional.

Eric Kieron Davies: Si.

Darian Vorlick: Cuando aparecen problemas técnicos... bueno, es lo de siempre. Cuando publicas un calendario de fechas interno se convierte instantáneamente en algo obsoleto porque las fechas y el tiempo de una tarea cambia cada día. A veces algo que podría llevar poco tiempo se alarga porque necesitamos a una persona esencial para resolver rápidamente otro bloqueador técnico que se ha presentado. Debido a que tenemos una cantidad limitada de recursos el tiempo que un desarrollador entrega a una tarea es todavía más valioso. Ser capaz de de planear el tiempo que va a llevar algo así es muy difícil.

Eric Kieron Davies: Al final siempre se añade un tiempo extra adicional del 5 o 10%. Si lleva 2 semanas te daré dos semanas y media, por ejemplo. En general la producción real suele extender un poco más que ese búfer que has creado pero se hace para proteger al equipo, porque no sólo quieres cumplir si no impresionar con lo que entregas.

Darian Vorlick: También hay que entender la diferencia entre 5 días de trabajo y 5 días hábiles. Si durante esos 5 días hábiles Mark Abent ha estado trabajando en otras cosas el tiempo de finalización se puede extender.

Eric Kieron Davies: Estar en producción de un juego ya lanzado (ndt: la pre-alpha), más desarrollo, más pre-producción y producción tienes que añadir tiempo adicional porque a veces tiene que resolver bugs aquí y allá. Es una buena pregunta, pero al final es conocer el equipo y hacer una buena estimación.

4- Se ha comentado varias veces que CIG está reuniendo sus recursos en distintas partes del mundo, poniendo a gente con el mismo tipo de habilidades en el mismo lugar y de esa manera evitando los problemas de trabajar con gente en distintas franjas horarias. Desde un punto de producción, ¿Cómo ha mejorado esto la eficiencia del proyecto? ¿Ha afectado, por ejemplo, a la velocidad en que se está remodelando la Freelancer?

Darian Vorlick: ¡Ese es un ejemplo sospechosamente específico!

Eric Kieron Davies: ¡Si! No sé por qué nos habrá puesto la Freelancer de ejemplo... Chris explicó esto en su carta y a la gente le gusta mucho leer entre líneas; pero en realidad no hay nada que ver entre ellas. Simplemente estábamos mirando cómo hacer lo mejor para el proyecto. Cómo hacerlo de manera más rápida y eficiente. Y hacemos esto constantemente. Verás cambios de este tipo en el desarrollo de cualquier videojuego, rehaciendo el equipo de desarrollo. En mis viejos empleos reorganizábamos el equipo cada año o cada seis meses (ndt. Blizzard): es muy común. Si sabes que puedes hacer una nave más rápidamente no necesitas tanta gente en el equipo. O necesitas más gente para acabar antes. Sea cual sea el caso, así es la industria.
Este cambio está en marcha en estos mismos momentos y nos estamos moviendo para terminarlo cuanto antes. Un ejemplo de por qué esto será bueno es nuestro equipo de Sonido en Reino Unido, dirigido por Lee Banyard: trabajan bien y rápido, entregando materiales cuando se solicitan. ¿Por qué son tan buenos? ¡Por que están todos juntos en el mismo sitio! Cuando algo pasa, se giran y trabajan en equipo para arreglarlo. No tienen que esperar 24 horas para que llegue un email. Todavía tenemos múltiples estudios porque tiene sentido tenerlo así, pero estamos unificando disciplinas y veréis sus efectos durante los siguientes meses.

Respecto a la Freelancer... ¿Darian?

Darian Vorlick: No tengo nada que comentar al respecto.

Eric Kieron Davies: Muy bien. (sonrisa maligna) Investigaremos al respecto y ya te informaremos.

5- Como productores hacéis de Administradores del Proyecto y por lo tanto tenéis un enorme papel vigilando el desarrollo del juego. ¿En qué momento juzgáis oportuno intervenir cuando veis que una persona o una subcontrata está teniendo problemas con la tarea que se les asignó? ¿Qué acciones habéis tomado en esos casos? Adicionalmente, ¿Los equipos están formados por individuos trabajando en tareas solitarias o en equipos pequeños dirigidos por un líder más experimentado?

Darian Vorlick: En nuestra jerarquía de equipos tenemos un Líder para cada equipo: Diseño, Ingeniería, Arte. Estos Líderes dirigen esos equipos. Cuando creamos una tarea para alguien son generadas en colaboración con los líderes del equipo, de manera que estos siempre estén al tanto de lo que hacen sus subordinados. Y nosotros como producción tenemos una vista general de lo que debe ser hecho.
Si por ejemplo vamos a añadir unas características para el siguiente parche nos sentamos con los líderes de equipo y averiguamos que hace falta para que sean terminados. Las dividimos en tareas individuales y las empezamos a mirar qué desarrolladores con las habilidades apropiadas están libres.

Eric Kieron Davies: Respecto a qué acciones hemos tomado cuando algo es díficil...

Darian Vorlick: Hablamos con ellos.

Eric Kieron Davies: Cualquier cosa. Evaluamos si la tarea fue increíblemente mal planeada y en vez de dos días hacen falta tres meses. Un gran error y tenemos que reunirnos con los líderes. Quizá tenemos problemas informáticos o quizá les hemos retirado demasiado tiempo de sus tareas para resolver bugs. Quizás no funciona en nuestra estructura actual. Un ejemplo de esto es mover cadenas de montaje enteras a distintas localizaciones de nuestros estudios porque tenemos la gente apropiada para hacerlo allí, no porque la gente estaba fracasando en su trabajo y queríamos deshacernos de ellos. Hacemos lo que tiene más sentido y se evalúa constantemente mediante nuestras prácticas de contratación.

6- ¿Qué desafíos aparecen cuando hay cambios de trabajadores en un departamento? ¿Qué pasa cuando se cambian productores? ¿Hay que reasignar algunas responsabilidades? ¿Tenéis responsabilidades divididas entre vosotros o todos tenéis una vista general de lo que sucede? ¿Tenéis problemas de comunicación por tener idiomas o culturas distintas?

Eric Kieron Davies: En esta industria, especialmente en las del entretenimiento, la gente cambia de trabajo. Es algo normal. Consiguen otro trabajo, se les promociona, se casan, tienen que mudarse a otro país, tienen hijos que van a la escuela... La gente va y viene. Es algo muy fluido y no tiene nada de nuevo.
Para nosotros es una cuestión de tener planes de contingencia y saber quien puede dominar algo en el entorno presente de desarrollo. Cuando alguien se va nunca hay, para nada, la expectación de que todos los productores lo sepan todo. No hay manera de hacer esto, sería algo que superaría a cualquiera con el nivel de producción de esta compañía. Así que si, lo dividimos en responsabilidades. Darian por ejemplo trabaja con el equipo de Ingeniería de Santa Mónica, con los lanzamientos públicos y también vas a hacer X, Y y Z. Probablemente estarás implicadas en estas tres cosas y también oirás de otras cosas porque estás en ese mismo estudio; pero no se te requiere saberlo todo. De hecho, tenemos que confiar los unos en los otros.
Así que cuando alguien me dice: hey, he conseguido un fantástico trabajo, mi mujer tiene que hacer tal cosa, o mi marido esto, no pasa nada: tenemos el plan de contingencia. O se reparte sus responsabilidades y trabajo o miramos si es posible contratar a alguien nuevo y filtramos eso de nuevo. Por muy mal que suene, tenemos un plan de contingencia para cualquiera aunque "les atropelle un bus". Si. Queremos asegurarnos de que la gente sepa lo suficiente de los demás para que puedan echar una mano si es necesario.

Darian Vorlick: Siempre es una buena señal de que estás haciendo buenas prácticas cuando la compañía no se desmorona cuando alguien se va. Si eres tan esencial y central que si te vas las cosas se van al garete.. eso recalca las ineficiencias de la prácticas de vuestro estudio. Como Administrador del Proyecto tengo que asegurarme de que si yo me voy las cosas sigan funcionando como un mecanismo de relojería.

Eric Kieron Davies: Sobre las barreras de cultura e idioma, somos personas adecuadas a las que preguntar esto. En anteriores trabajos tuve que hacer negocios en China por múltiples razones, poner en marcha ciertas operaciones y para mi esto fue un desafío, sea por frases que utilizas, terminología o jerga de email o poner ejemplos de deportes que no conozco como el fútbol. ¡Usa términos de beisbol o algo así! Son ejemplos de un poco tontos, porque nuestra oficina de Frankfurt habla perfectamente en inglés y trabajan muy bien; pero hay desafíos.

Darian Vorlick: Ricky Jutley de Reino Unido estuvo por aquí y viceversa, por lo que estamos creando algo de intercambio cultural y hace que la compañía sea mucho más homogénea.

Eric Kieron Davies: Siempre consideramos que las cosas se hacen por un esfuerzo de equipo y no queremos andar por ahí diciendo a la gente que "es culpa tuya". Echar la culpa a los demás no funciona, ni en tu familia ni en los negocios.

Darian Vorlick: Crea animosidad y toxicidad. Es una reacción innata señalar con el dedo y decir: "Es culpa vuestra".

Eric Kieron Davies: Si, se trata más de encontrar la raíz del problema y solucionarlo a gran escala. Por supuesto, si alguien ES un problema se toman las apropiadas decisiones de negocios al respecto.

7- ¿Cómo hacéis para tener múltiples versiones de desarrollo al mismo tiempo? Ejemplo: 1.3, 2.0 y Star Marine. Además, ¿podríais explicarnos la importancia de unificar el código en 1.3 para el proyecto y si hace que sea más fácil desarrollar?

Eric Kieron Davies: El 1.3 y su unificación del código ayudó inmensamente porque todo el mundo, a nivel global, usamos el mismo código. Rompió algunas cosas unificar todo esto; pero ahora estamos todos mirando la misma versión y trabajando en la misma. Queremos mantener este conjunto unificado de desarrollo.

Darian Vorlick: Eso y que además queremos poner mucho énfasis en la estabilidad del sistema y puede que os hayáis dado cuenta de que ha mejorado mucho últimamente desde que hacemos esto.
Respecto a tener varias versiones del juego al mismo tiempo en desarrollo... ¡Esa es la razón por la que tenemos múltiples equipos! Una persona puede estar trabajando en una versión propia, mientras otros trabajan en una versión más pública y esto reside en tener un buen equipo de Control de Calidad que detecte los bugs que van a apareciendo en el parche 1.3 y que podrían afectar a la versión principal de desarrollo. Hay que estar atentos a lo que sucede en cada versión, vigilar los hitos del proyecto que deben ser alcanzados y utilizar Jira de manera muy eficiente. Tenemos una interfaz que nos permite saber qué tareas y bugs tenemos en cada versión en desarrollo, qué bugs bloqueadores, críticos y triviales hay allí y hablamos diariamente sobre qué tareas o bugs deben ser atacados el día siguiente.

Eric Kieron Davies: Si. Respecto a cómo nos ayuda: enormemente. Esto permite trabajar en la versión pública 1.3 que ya tenéis mientras se automatiza sus arreglos que se añaden a la versión principal para que no haga falta orquestar esos arreglos en la versión principal cuando tengan que sacar otra versión pública.

Thomas Henessy (Cámara): ¡En el programa de hoy, Darian y Eric discuten las ventajas de cruzar los streams! (Ndt: juego de palabras en referencia a "nunca cruzar los rayos" en Ghostbusters y a cruzar otro tipo de chorros fisiológicos XD)

Eric Kieron Davies: ¡Me gusta!! Asegúrate de editarlo de manera que no sea muy pervertida.... ¡Siguiente pregunta!

8- ¿Si algo se vuelve muy complicado para ser finalmente implementado en el juego se elimina o se simplifica? Y además, ¿Qué métodos utilizáis para criticar el trabajo ajeno, fechas de entrega etc? ¿Palo o Zanahoria?

Darian Vorlick: Respecto a la primera pregunta, ahora mismo cuando se usa el Flowgraph (Como en la conversación de esta mañana con Humphries sobre el sistema de tokens de identidades) tenemos un ping en la red y eso hace que se saturen mucho las líneas, así que una de las cosas que estamos decidiendo es si es bueno diseñar cosas de las naves usando Flowgraph. De esto sale una conversación entre diseñadores sobre si es mejor programarlo a mano o usar flowgraphs de todas formas o usar los tokens de identidad. Todo esto se planea por adelantado y se hace I+D para ver si es posible, haciendo pruebas de concepto y prototipos y cual de ellos funciona mejor.

Eric Kieron Davies: Si. Sobre la siguiente pregunta sobre palo o zanahoria.. Yo no creo en esas dos opciones, porque este viejo adagio te lleva a nunca conseguir esa zanahoria y eso acaba cansando. Es mejor trabajar a través de los líderes de departamento, presentando pequeños objetivos fáciles de lograr y motivar de manera consistente y constante diariamente. Amenazar o sobornar no lleva a ninguna parte, sobre todo trabajando en un ambiente tan creativo como este en el que se crea entretenimiento y experiencias divertidas. No estamos haciendo un engranaje o un coche, algo probado y hecho millones de veces: estamos haciendo algo nuevo y vamos improvisando sobre la marcha como hacerlo. Requiere de mucha más sutilidad que ese tipo de viejas prácticas.

Darian Vorlick: Es cierto. En los estudios en los que se gobierna con puño de hierro... es algo anticuado y que al final es contraproducente porque nadie aporta sus propias ideas. Es mejor usar un esfuerzo colaborativo, un toma y un daca, conversando diariamente con nuestros compañeros locales e internacionales sobre los bloqueadores y problemas que tienen y qué ideas pueden aportar.

Eric Kieron Davies: Además, si estás usando el método de la zanahoria y el palo es que estás forzando a alguien a hacer algo que odia.

Darian Vorlick: Y no queremos compulsar a nadie.

Eric Kieron Davies: ¡Nos encanta trabajar en esto y nuestra pasión nos lleva a trabajar cada día en este proyecto! No hace falta usar esos métodos forzosos. Respecto a la crítica positiva y negativa... ¡queremos ambas cosas! Es cierto que siempre queremos hacer las cosas mejor y las miramos de manera negativa y crítica para hacerlas mejor, pero tenemos que motivarnos señalando lo que nos gusta y lo que ha salido bien para ir hacia delante. Las críticas negativas están bien, como en los foros, porque nos señalan lo que creen que hicimos mal y las buenas nos indican qué puntos fuertes tuvimos y en qué tuvimos éxito. Eso nos ayuda a mejorar las cosas.

Darian Vorlick: Y si, a veces tenemos que poner el pie en el suelo y trazar una línea. Sé que te encantaría añadir esta nueva característica a la nueva versión pero no podemos porque no tenemos ni tiempo ni recursos para hacerlo bien. Mejor esperar al siguiente parche y mientras tanto ajustarlo y pulirlo más.

9- ¿Qué proporción de vuestro trabajo no veremos en mucho tiempo comparando con cosas que veremos a corto plazo? ¿Estamos viendo lo último recién salido del horno o estamos disfrutando de viejo contenido ya pulido? ¿Qué estilo de desarrollo tenéis: en cascada o ágil? ¿El entorno de trabajo se parece más a Mad Max o a Jurassic Park?

Eric Kieron Davies: (risas)

Darian Vorlick: Bromeamos sobre que a veces pinchamos al equipo para conseguir lo que queremos, pero siempre lo decimos en broma. ¡Muy raramente tenemos que obligarles a hacer algo, por eso tengo una gran espada en mi oficina!

Eric Kieron Davies: (risas)

Darian Vorlick: Es una pregunta interesante porque una gran parte de lo que hacemos ha sido planeado hace muchos meses, pero muchas veces mientras trabajamos para un evento hasta el último momento. Hay cosas que intentamos arreglar y meter en el juego hasta el último día que entran en el parche o tenemos una mecánica nueva que lleva mucho tiempo en desarrollo pero que no se mostrará hasta que llegue un evento. Realmente vemos la versión terminada de nuestro trabajo cuando lo veis vosotros en directo.

Eric Kieron Davies: Si.

Darian Vorlick: Esto es parecido a trabajar en una película. Los actores sólo ven sus líneas y se las aprenden. No ven la película acabada hasta que van a una presentación privada previa al estreno. A menudo lo vemos unido días antes o a veces en directo. Si nos veis en los vídeos estamos animando tanto como vosotros por lo que vemos, porque es fantástico, podemos ver el resultado de lo que hemos estado haciendo los últimos meses.

Eric Kieron Davies: Si, mantenemos la cabeza gacha y a veces es difícil ver cómo de gran somos. Tenemos una mezcla de ambas cosas: una lista maestra en el calendario y constantemente nos aprovechamos de ella para hacerla realidad. Las cosas que os mostramos es gran parte de lo que tenemos, lo hacemos tan a menudo como podemos y a menos que sea una gran revelación como el Discurso de Bishop, que queremos que sea excitante cuando llegue, intentamos mostrar todo lo que tenemos pero todo esto son partes de lo que todavía está en construcción de un gran universo. Por eso Chris lo dividió en módulos, para que vieseis su partes.

Darian Vorlick: Cuando enseñamos en Around the Verse un Sneak Peak de una nave o concept art es porque estamos trabajando de manera activa en ese arte, por lo que para cuando llegue el momento de lanzarlo en Arena Commander será la culminación de meses de trabajo que vosotros habréis visto antes gracias a la transparencia que tenemos con nuestro desarrollo. Respecto a metodología de desarrollo..

Eric Kieron Davies: ... es bastante ágil, si. No es 100% ágil, hardcore, pero al mismo tiempo tomamos cosas de la cascada alcanzando ciertos objetivos y se unifican entre ellos. La agilidad es la micro en la macro de la cascada.

Darian Vorlick: Yo uso la metodología de mi hermano, la metodología Dwit: Do Whatever It Takes (haz lo que sea necesario).

Eric Kieron Davies: Hazlo.

Darian Vorlick: Respecto a si es Mad Max o Jurassic Park (risas), voy a hacer un chop de la cara de Eric sobre la de Chris Pratt de Jurassic World y pondré las caras del resto de los desarrolladores sobre las de los raptors cuando está en el pozo de estos dinosaurios (risas).

Eric Kieron Davies: Es una pregunta dura. Una expresión habitual es "pastorear gatos", porque cuando tienes gente tan creativa mantenerles unidos es un desafío.

10- ¿Cómo usáis Jira? ¿Es la fuente de la verdad, modificada y ajustada para llevar vuestro desarrollo al día, o usáis tablas de cálculo para llevar el día a día?

Eric Kieron Davies: Tenemos una metodología más que implementada a estas alturas y Jira es una de nuestras herramientas de producción y estamos animando a la gente a mantener su estado al día para mejorar comunicación y trabajo entre estudios y saber qué trabajo queda por hacer. Gracias a esto y hacer buenos calendarios te puedes hacer una idea del tiempo, recursos y tareas que quedan por hacer para completar tus objetivos. Jira sirve para recolectar toda la información y ver qué lo bloquea para quitarlo del medio y llegar a la siguiente versión. "Si no está en Jira, no existe": ese es nuestro mantra.

Darian Vorlick: También sirve para tener responsabilidades. Cuando alguien inicia una tarea en Jira tenemos un registro sobre el tiempo invertido en una tarea, qué gente está en ello y cuanto tiempo falta. Esto es lo que nos permite acelerar las cosas, hacer reuniones de coordinación más eficientes.

Eric Kieron Davies: Cualquier herramienta de producción es tan buena como la gente que la use y que la mantenga al día. Saber que Calyx está trabajando en algo y ha terminado otras cosas nos permite asignar otras tareas que ya son posibles o allanar el camino a la que tiene en marcha. Así se toman decisiones más rápidas.

Darian Vorlick: Si Zane decide un día hacer un HUD de interfaz para naves de tipo capital y no está en su lista le decimos que esto está genial, lo metemos en el calendario, pero le conminamos a que haga las tareas que necesite el proyecto en este momento. Respecto al flujo del trabajo y tablas de cálculo: yo soy un hombre Excel. Lo he usado mucho y lo amo.

Eric Kieron Davies: No creo que nunca dejemos de usarlo, porque es una gran herramienta para planear escenarios y situaciones. Puedes mover las cosas con rapidez hasta que tengas todos los datos. Jira necesita datos reales.

Darian Vorlick: Hemos usado también Microsoft Project, Shotgun... todos trabajan simultáneamente en el proyecto a su manera.

6
FrostRaven
2
FrostRaven

Saludos, ciudadanos.

¡Esta última semana ha pasado volando! Nos complace presentaros el segundo informe semanal acerca de en qué se ha avanzado tanto en "Star Citizen 2.0" como en "Star Marine".

¿Las novedades más molonas? ¡AHORA LAS NAVES SE PUEDEN PARTIR EN DOS (o más) TROZOS! Sí, los equipos de código y de diseño técnico han estado trabajando duro y haciendo que esta emocionante característica funcione en el motor del juego, y han conseguido finalmente implementarla... ¡por lo que a partir de ahora seréis capaces de reventar las naves en distintos trozos cuando les hayáis infligido daño catastrófico! Ahora podréis darles realmente candela a vuestros peores enemigos causándoles daños irreparables a sus naves, como, por ejemplo, partir una Constellation en cuatro trozos distintos. El sistema todavía necesita recibir un poco de cariño antes de que podamos ponerlo a vuestra disposición, pero en cuestiones de funcionalidad técnica, hemos hecho unos avances rompedores (¡perdón por el juego de palabras!).

Todo el mundo ha estado puliendo detalles y corrigiendo bugs, y todavía nos están llegando algunos contenidos procedentes de varios departamentos, contenido que incluye más elementos de audio que suenan fabulosos. Nuestro especialista en diálogos ha estado en Pinewood Studios (famosos por las películas de James Bond y el juego "Privateer 2: the Darkening") y en SIDE UK para grabar más fragmentos de diálogo referentes a grabaciones de audio, que están resultando ser un elemento de exploración muy divertido de buscar.

Todavía nos estamos peleando con el sistema EVA para conseguir alcanzar ese punto en el que nos parezca que está perfectamente terminado, pero al menos le estamos sacando más jugo a los sistemas de la nave en lo que concierne al comportamiento de la IA. La IA tendrá en cuenta ahora los nuevos encuentros y escenarios a los que los jugadores se enfrentarán en Crusader. Por ejemplo, la construcción del mapa está equilibrada para que si el jugador se aleja demasiado de la seguridad de las zonas de la UEE, puede que tenga algún mal encuentro, o a lo mejor tiene suerte y no sufre ningún disgusto. ¿Quién sabe? La belleza de todo ello es que es todo una jugabilidad con enfoque sistémica en la que cada encuentro posee su propio potencial único.

¿Y qué pasa con la parte relacionada con "Star Marine"? Con nuestras botas en el suelo, estamos viendo algunas mejoras notables en las animaciones de recarga de armas del FPS, apuntar con la mira y empezar a moverse y parar, por lo que estamos muy contentos de que todo esté empezando realmente a cobrar forma, y no sólo es que los personajes tengan mejor aspecto, sino que el entorno también lo tiene. El equipo de Entorno ha estado ocupado con las distintas estaciones espaciales en sus etapas finales de diseño artístico, y la Central de Carga Covalex justo acaba de recibir una pasada completa de iluminación, ¡por lo que estamos seguros que va a dejar apabullada a la gente!

Crusader en todo su conjunto parece ahora mucho más vivo y con más interacción con los bots de reparaciones y la implementación de los sistemas de simulación de tráfico de fondo, ¡que servirá para darle auténtica vidilla al mapa con todos esos comerciantes y patrullas de la UEE deambulando de aquí para allí! Éste es otro de esos primeros pasos que Star Citizen dará con esta versión, ya que el universo empieza a cobrar vida poco a poco gracias a la creación de todos los sistemas que producirán de forma orgánica las economías y comunidades con las que podrás jugar.

Por último, hay algunas grandes mejoras referentes al rediseño de las IU de las pantallas internas de las naves, rediseño que se ha hecho para que tengan en cuenta todas las mecánicas de juego nuevas asociadas a las naves multitripuladas. El equipo de diseño de IU está realmente emocionado por el aspecto que está adquiriendo todo, y cualquiera de nuestros lectores al que le guste trastear con aparatitos se sentirá entusiasmado cuando pueda por fin manejar la primera implementación de la pantalla de ingeniería, que permite un mayor control sobre la distribución de potencia y los sistemas de escudos de vuestras naves. Esta nueva pantalla, además, se centra en la funcionalidad para permitirte pasar tu atención de forma rápida y sencilla a cualquiera de las pantallas individuales que hay distribuidas en tu puesto. Las IU de estas pantallas necesitaba tanta consideración porque supondrán los cimientos de todo el resto del sistema durante los próximos años, y nos permitirán irles añadiendo cada vez más funcionalidad a medida que naves más y MÁS grandes van llegando al juego.

A continuación tenéis un resumen general de en qué está atareado cada uno de nuestros departamentos...

JUGABILIDAD E INGENIERÍA

  • Las naves llegan con mayor precisión al final de las sendas de vuelo de IA.
  • Las naves que siguen sendas de vuelo de IA utilizan mejor la esquina dinámica de obstáculos.
  • Se ha mejorado la conducta de huida de una nave cuyo caso haya sufrido daños graves.
  • Se ha mejorado el uso de misiles por parte de las naves.
  • Las naves son más precisas a la hora de esquivar obstáculos.
  • Se ha cambiado la relación entre los brazos del personaje y la cámara, lo que mejora el apuntado con la mira y los disparos desde la cadera.
  • Se han solucionado problemas con los saltos del jugador.
  • Se han pulido los conjuntos de movimientos de la pistola para que estén al mismo nivel que los del fusil.
  • Se ha mejorado el uso de las físicas de "muñeca de trapo".
  • Las partidas en red tienen ahora en cuenta el combustible cuántico.
  • Se ha añadido un test de colisión antes de iniciar el viaje cuántico. Sirve para informarte de si hay objetos entre ti y el destino programado.
  • Se ha añadido soporte para balizas de navegación para viaje cuántico descubribles.
  • Se ha mejorado/pulido la funcionalidad del dron de reparaciones.
  • Optimización de la red.

IU (interfaz del usuario)

  • Mejoras en el HUD de viaje cuántico
  • Ahora hay círculos alrededor de los puntos de interés
  • Se ha añadido la cantidad consumida de combustible cuántico
  • Se ha añadido un mensaje de "fuera de alcance" se tratas de hacer un salto para el que no tienes suficiente combustible.
  • Casi todas las naves tienen ahora HUDs de viaje cuántico
  • Se ha entregado la primera iteración del gestor de misiones
  • 5 pantallas para el mapa de Crusader
  • Se ha entregado una implementación básica de las pantallas de Ingeniería con apartados de Potencia, Escudos, Resumen General y menú minimizado (hace falta ponerla a prueba).
  • Se ha pulido la pantalla de Ingeniería.
  • Implementación de "spawneo" de naves.
  • Mejoras en el gestor de misiones.
  • Ahora aparece una lista de las misiones completadas.

ARTE

  • Nuevas iteraciones del Cutlas, el Retaliator y la Constellation en sus pasos finales de la cadena de montaje.
  • Mejoras finales del arte y efectos visuales para el entorno.

ANIMACIONES

  • Más iteraciones de las interacciones con el entorno, EVA, movimiento y uso de armas en FPS, reacciones al sufrir impactos y morir, y secuencia de "dejarse caer".

SONIDO

  • Sesión de grabaciones de diálogos para algunas frases adicionales y regrabado de algunas ya hechas antes.
  • Se ha empezado a trabajar en mejoras en el audio de las naves.
  • Implementación de más música para mejorar el "feeling" de cada zona y "venderte la escena".
  • Se ha trabajado en parámetros de "rigores del vuelo" que serán aplicados a tu nave bajo ciertas condiciones.
  • Se ha empezado a diseñar audio para esas condiciones.
  • Mejoras en el sonido de las armas y utensilios del FPS.
  • Se está ampliando la variedad de sonidos de pisadas que se pueden oír en cada superficie.
  • Se está trabajando en mejor las cualidades atmosféricas de las estaciones espaciales.

BLOQUEADORES

  • A los personajes les faltan secciones interiores de sus cascos.
  • Las armas balísticas causan un cuelgue del juego y hay otros problemas de estabilidad que deben arreglarse.
  • El sistema de "tirar y empujar" parece estar en conflicto con algún otro sistema de control, ¡porque ahora mismo catapulta al jugador hacia lo más profundo del espaciooooooo!
  • Las partículas parecen dejar de renderizarse en algunas zonas con gravedad, ¡pero no en todas¡ ¡Esto hay que investigarlo!

MIRANDO HACIA EL FUTURO

¡Uf, vaya semanita! Como podéis ver, estamos haciendo muchos progresos en lo que parece ser la versión más emocionante de Star Citizen hasta la fecha. Tras la publicación este mismo día (en el momento de colgar este artículo en la página de RSI) de la versión pública de "Star Citizen Alpha 1.3", ¡nuestro siguiente objetivo es la versión PTU de "Star Citizen Alpha 2.0"! No podemos esperar a que podáis explorar (y, para seros sinceros, ¡romper!) el Mini PTU. Todo el equipo está trabajando lo más duro posible para ponerlo a disposición de los backers para que puedan probarlo.

Tened en cuenta que aunque durante esta semana nos hemos centrado sobre todo en la Aplha 2.0, el informe de la semana que viene traerá más detalles sobre "Star Marine".

Traducción por Vendaval para Ciudadano Estelar

6
Sphere

¿El FPS cuando lo piensan sacar? ¿Para 2025?

2 1 respuesta
FrostRaven

#18110 El FPS va a ser parte del siguiente parche 2.0 (se va a poder hacer FPS en estaciones espaciales y tal), pero el Star Marine como tal (el rollo PVP enlatado tipo CS) saldrá en un parche posterior. Por el momento se quieren centrar en unificar todo y luego sacarán la parte más competitiva para equilibrar cosas.

2
FrostRaven

Anvil Crucible, Nave de Reparación Concepto Original de Ryan Church
Gurmukh Bhasin: comenta que esta semana ha estado estableciendo el aspecto interior de la Crucible para que sea más Anvil y actualizando la guía de estilo de esta compañía. Admite que le cuesta poner por escrito lo que para él define el "estilo Anvil".
Olwin Bachiller: explica que es desafiante hacer el interior de la nave por lo complicado que es definir exactamente qué va a ser lo más grande que podrá ser reparado en su interior (en torno a tamaño Hornet) de su bahía de popa. La bahía se puede intercambiar por otro tipo de equipamiento.
Tendrá brazos CANADARM, que se utilizarán en el complejo sistema de reparación externo que tendrá el juego.

Khartu-Al
Están construyendo el kit cultural de los Xi'an. No va a tener exactamente el mismo aspecto que tuvo durante su diseño conceptual en cuanto a colores, textura y todo eso. Será construído en Austin.

Cadena de Montaje de Personajes
Omar Aweidah: Es difícil encontrar el punto dulce en que se permite a los jugadores tener personalización sin que al mismo tiempo se pierda calidad en los shaders. Están empujando la tecnología todo lo que pueden mientras al mismo tiempo mejoran el rendimiento. Ahora mismo, en la oficina, se puede cambiar muy fácilmente de color, material, envejecimiento y suciedad de la ropa. La idea es que la ropa sea estandarizada en los trajes y pueda combinarse un casco de un tipo con unos guantes y botas distintas.
Parece que no van a utilizar Nvidia Gameworks o Physics para las físicas de la ropa, pero tendrán físicas de todas formas. Están en ello.
Habrá diferentes tipos de ropa como Terra Casual, Alta Moda, etc y habrá marcas equivalentes al Gucci de Star Citizen, etc.
Por supuesto, los trajes espaciales se sellarán en el espacio y no tendrán los cuellos expuestos al vacío XD

2.0
Vendrá con al Constellation Andromeda y la Retaliator. Luego irán implementando otras naves, como la Freelancer, y finalmente pasarán a variantes.

1
X

Veo que en esta última newsletter no han puesto como bloqueantes los problemas de red. Se habrán desecho por fin de los fallos de sincro, o simplemente han omitido ponerlos? Porque es uno de mis mayores temores, la verdad.

1 respuesta
Xeros_Grey

#18113 opino igual

por mucho que digan hasta que no lo vea funcionando...

ro_B0T_nik

En reddit lei que si no lo ponen se entiende que de momento lo tienen controlado, pero no implica que este limpio al 100%. Ya les ha pasado otras veces que lo consiguen eliminar como bloqueador y les vuelve en la siguiente build interna.

ro_B0T_nik

Star Citizen Alpha 2.0: Flight Model Changes

Si joder.

2
FrostRaven

COMIENZO
El parche 1.3 está fuera y la gente se ha vuelto un poco loca con los Buggies. Ben admite que están un poco bugueados; pero necesitaban hacer un test de carga de las mecánicas de colisión. 1.3 es un parche post-fusión de todas las versiones del juego que han estado en desarrollo paralelo los últimos meses, pero también metió la nueva zona de la Galería y un par de armas nuevas en Arena Commander.

El equipo de la Comunidad irá a Austin en un par de semanas para grabar un ATV allí. También harán allí un evento en un bar de Austin para los mecenas de la ciudad.

NOTICIAS

CIG Santa Mónica - Arena Commander Eric Kieron Davies y Vince Sinatra.

  • Vince Sinatra, Jede de Control de Calidad en L.A., se ha unido al equipo de allí para ayudar a probar las mecánicas de la nave durante su diseño.
  • Se está trabajando en el anillo de atraque de la Constellation, de la mano de Olwin Bachiller, así como en los LODs de la nave.
  • Randy Vazquez está haciendo el diseño técnico de la Caterpillar.

CIG Austin - Universo Persistente Jake Ross, que regresó de sus vacaciones en las Smoky Mountains

  • La UI de Compra está siendo mejorada entre Tony Zurovec, Zane Bien y Carl Jones, de la que pronto tendremos una previsualización de su aspecto y de como fluirá.
  • Casaba Outlet, la tienda de ropa, ya está toda hecha en whitebox y están haciendo el modelado final para que se puedan mover por dentro los jugadores bien y accedan a las estanterías de la ropa bien.
  • Trabajando en un efecto de "amortiguación" de la cámara en primera persona durante los emotes, ya que algunos eran realmente molestos al seguir la acción del personaje con la cabeza, especialmente bailando.

CIG Manchester - Escuadrón 42 Tom Kewell y Simon Vickers

  • Tom ha estado trabajando en Star Citizen Alpha 2.0 en la mecánica temporal de reparación que van a meter mientras se desarrolla la mecánica real que tendrá el juego, en la que podremos ensuciar nuestras manos. Lo están haciendo así para que se repare rápidamente y se pueda explorar y testear el 2.0 por ahora.
  • Simon ha estado poniendo Eventos de Fondo en el sistema para mostrar al jugador el estado de este cuando lo visita, como cuando vas a localizaciones como una estación de reparación. Hay una posibilidad de que algo aparezca en esa localización, como una nave IA, que te muestre el tráfico normal de esa localización. En el caso de 2.0 encontraremos un conflicto entre los piratas y las fuerzas de la UEE, con apariciones de patrullas de la UEE o emboscadas piratas o mercaderes independientes buscándose la vida. Todas las IAs reaccionarán entre si de manera sistemática: las patrullas atacarán a los piratas si los ven o el pirata intentará atacar mercaderes para robarles su carga. Estas naves visitarán las estaciones de reparación de Tom de la misma manera que la de los jugadores, recibirán daños etc para crear un pequeño diorama de lo que será finalmente el juego.

CIG Frankfurt - FPS/Motor Gráfico Brian Chambers

  • Brian nos hace un pequeño tour a las nuevas oficinas de Frankfurt a partir de 9:26-12:00. No mucho que comentar aquí, salvo que han aumentado la plantilla a 30 desarrolladores y en sus amplias y cómodas oficinas tienen espacio para 49.

ENTREVISTA CON PETE MACKEY Y JOHN PRITCHETT SOBRE MODELOS DE VUELO

Jared Huckaby: Hola a todas. Han tenido lugar recientemente algunas conversaciones sobre los próximos cambios por los que pasará el Modelo de Vuelo. Conmigo hoy tengo al Diseñador Pete Mackey y al Programador de Físicas John Pritchett para hablar algo del mensaje de Modelo de Vuelo que con suerte publicaremos al final del día de hoy para explicar cómo avanzará este tema de ahora en adelante.
Para empezar las preguntas, ¿cómo hemos evolucionado hasta tener el modelo de vuelo que tenemos hoy en día?

John Pritchett: Los dos objetivos principales que me plantee desde un principio con el modelo de vuelo fue:

  • Asegurarse de que el comportamiento durante el vuelo fuese bueno y suave, porque en el vuelo espacial quieres notar que las naves tienen mucha inercia y
  • Que este fuese altamente dinámico y adaptable a variaciones y condiciones inesperadas que nos encontrásemos. Desde un principio queríamos que hubiese daños a los impulsores, por lo que no quería ir administrando esto de nave en nave y era obvio que necesitábamos un sistema de respuesta. Y eso es lo que hice. El Algoritmo de Control de Respuesta es básicamente un control de aceleración exponencial, que nos da algo mejor que un cambio de aceleración instantáneo, que es lo que tenemos con movimientos de segundo o tercer orden: las aceleraciones no pasan de 0 a máximo instantáneamente, lo hacen gradualmente. Lo malo de esto es que el tiempo de ajuste exponencial puede ser muy largo y los jugadores notarían eso cuando pasan de máxima velocidad a cero, y es algo que quería mejorar.

Jared Huckaby: Pete, ¿qué opinas del modelo de vuelo actual?

Pete Mackey: Lo que los jugadores han reportado en algunos casos es que parece poco riguroso. El efecto secundario que obtienes al tener una aceleración exponencial es que es un poco inestable en su extremo de la curva. (risas)

Jared Huckaby: Muy bien. Hemos tenido el modelo de vuelo ya durante un año. ¿Qué es lo que hace que este sea el momento adecuado para cambiarlo?

John Pritchett: Nos llevó algo de tiempo tener el tiempo para ponerlo en las manos de los jugadores y obtener sus opiniones sobre lo que debía cambiar, pero una vez que nos dimos cuenta de esto no quise dar un paso atrás en la calidad del movimiento y su adaptabilidad, por lo que me llevó algo de tiempo encontrar la solución apropiada. Lo que se me ocurrió fue que utilizásemos movimientos del tercer orden: un cambio de aceleración que no asume que la aceleración pueda cambiar instantáneamente. Me llevó tiempo hacerlo funcionar de manera apropiada con el complejo sistema que tenemos.

Jared Huckaby: (risas)... el complejo sistema que tenemos... Esto era algo que siempre estaba planeado que sucediese. No es que sea una nueva idea que se nos acaba de ocurrir hace unas semanas. El desarrollo de juegos es iterativo y esto siempre iba a ser el siguiente paso.

John Pritchett: Si, bueno... volviendo un poco a los comienzos, podría utilizar el sistema como un sistema de respuesta de manera que cuando introduzcas un cambio a tu velocidad se introdujese un nuevo punto de velocidad que el sistema de respuesta de control suavizaría por ti para solucionar el error de velocidad actual hasta llevarlo al deseado; pero eso es lo que introduciría ese tiempo de respuesta, esa falta de reacción torpe de la que hablamos.
Tras haber reconocido eso, tomamos la decisión de introducir un perfil de movimiento más óptimo que se aprovechase del todo de la aceleración y velocidad de la que disponía la nave, para que pueda cambiar de un estado al otro en la menor cantidad de tiempo posible optimizando lo que puede hacer la nave.

Pete Mackey: Respecto al tiempo que nos ha llevado.. esto es algo de lo que hemos hablado yo y John desde Diciembre del año pasado, inicialmente, y le presentamos nuestra idea a Chris oficialmente en Abril o Mayo, por lo que recibimos la luz verde para empezar a trabajar en ello hace unos cuatro meses. No sólo trabajamos en el movimiento estándar del que estamos hablando ahora, si no todo el paquete que estamos bautizando como IFCS 2.0.

Jared Huckaby: Gran introducción. Hablemos de lo que vendrá con 2.0. ¿Quien quiere empezar?

Pete Mackey: Además del trabajo que ha estado haciendo John con los algoritmos de control de movimiento, también hemos estado haciendo otras mejoras de jugabilidad. Estamos añadiendo tres nuevos modos a IFCS y esto nos proporciona mucho más control en diferentes circunstancias. Tenemos:
1 - Modo de Precisión: que te pone un límite en la velocidad máxima y escala tu aceleración en función a la cantidad de movimiento que le des. Esto da mucho más control cuando estas cerca de una plataforma de aterrizaje o extrayendo mena de un asteroide o haciendo salvamento de materiales. (Risas)
2 - SCM, Velocidad de Maniobra Espacial: superficialmente es muy similar a lo que tenemos actualmente, pero en vez de tener una velocidad máxima estáticamente definida ahora estará determinada por tu aceleración. Así que cualquier cosa que altere tu capacidad de acelerar modificará tu velocidad máxima. Cualquier cosa que cambie tu masa (como la configuración de tu nave, añadir carga, mejorar tus impulsores) alterará tu velocidad máxima.
3 - Modo de Crucero: Mientras que SCM se trata de controlar tu velocidad máxima, Crucero se trata de obtener la velocidad máxima que puedas al precio de sacrificar tu maniobrabilidad. La velocidad máxima será significativamente mayor que en velocidad de Maniobra. Si ahora mismo los máximos están en torno a los 300 m/s, crucero los puede elevar hasta los 1.000 m/s. Aún estamos intentando determinar qué máximo será apropiado para el Universo Persistente, pero ahora mismo está en 1.000 m/s. A esta velocidad es muy fácil perder la consciencia y es muy difícil recuperarse de una maniobra de deslizamiento, por lo que aplicamos un límite de giro a la rotación de tu nave: la orientación de tu nave está fijada en la misma dirección que tu vector de velocidad. Maniobrar a esta velocidad va más de hacer correcciones de dirección y menos de hacer giros. (risas) Definitivamente, no es una velocidad que quieras utilizar en un campo de asteroides o en un lugar donde hay muchas naves volando por ahí.

Jared Huckaby: ¡Acepto el desafío!

Pete Mackey: (risas) Ah, y otra cosa que me olvidé mencionar es que junto a SCM tenemos los Posquemadores también aplicados a tu aceleración en el nuevo sistema, lo cual permite que tu velocidad máxima también sea incrementada dinámicamente durante esos períodos. Este incremento de velocidad te permitirá mantener relativamente el mismo grado de control sobre tu nave. Como no queríamos perder que este incremento de aceleración fuese útil para maniobrar cerca de asteroides, por ejemplo, hemos separado el Modo Postcombustión (Afterburner Mode) del Modo de Impulso (Boost Mode) para que puedas tener la maniobra ágil sin incrementar tu velocidad máxima, lo cual proporciona mayor control. El Modo Postcombustión te da el mismo control pero mayor velocidad máxima. Ahora tienes esta elección dual, tienes que escoger en qué inviertes tu combustible: ¿Postcombustión o Impulso? Ambos estarán disponibles con sólo pulsar un botón.

Jared Huckaby: ¡Mola! Eso significa que habrá cambios a la interfaz de usuario, ¿no?

Pete Mackey: Si, tenemos algunos cambios. Zane y el departamento de UI te ayudará en esto, indicándote en que modo de vuelo te encuentras y a cual cambiarás si usas el botón de modo de vuelo, pero creo que tiene planes a más largo alcance sobre esto... (risas) aunque no quiero hablar por él.... para mostrar del todo las capacidades de este sistema.

John Pritchett: Voy a intentar cazar unas cuantas capturas de pantalla. Si no lo tenemos listo para este vídeo lo veréis cuando salga 2.0.

Jared Huckaby: ¡Mola muchooo! (risas)

Pete Mackey: El mensaje es muy largo, así que dejaremos para ello algo allí y que se lo lean, pero John, quería que hablases algo sobre el error antes de que terminemos esto. ¿Qué nos puedes contar sobre el sistema de errores?

John Pritchett: Uno de los problemas que tuvimos con el sistema desde un principio es que era demasiado perfecto. El movimiento podía parecer tan mecánico que parecía un videojuego. Uno de los principales principales objetivos del sistema es que se pudiese adaptar bien a condiciones cambiantes e inesperadas, por lo que estamos empezando a aprovecharnos de esto ahora que tenemos el tercer orden de movimientos, el nuevo perfil que tenemos ahora, que te dice cómo debería moverse la nave... pero no hay ninguna expectación de que se mueva así por una serie de razones. Esas razones podrían ser, por ejemplo, imperfecciones en la respuesta de los impulsores que se pueden incrementar a medida que son dañados. Puedes decirle al impulsor que empuje en cierta dirección con cierta potencia; pero no va a hacer eso a la perfección, y eso lo percibes como la turbulencia de un avión al desplazarse. Estamos trabajando en esto para que sea algo cosmético, no queremos que sea una molestia o tenga un enorme impacto sobre cómo se comporta el vuelo para los jugadores, por lo que lo ajustaremos según pase el tiempo. Queremos que la nave tenga algo de movimiento y no se sienta tan rígida al maniobrar.

Jared Huckaby: Si. Queremos que cada nave tenga su propia personalidad, no sólo en su aspecto si no en sus característica de vuelo.

Pete Mackey: Por supuesto.

John Pritchett: Si.

Jared Huckaby: Así que, a partir de ahora y de ahora en adelante esto no será el fin de los cambios del equilibrio del modelo de vuelo. Es sólo el comienzo de la siguiente fase. Pondremos este mensaje en la página web y recibiremos sus opiniones en los foros cuando salga el parche 2.0. Vosotros os habéis presentado voluntarios a pasaros por allí de vez en cuando y responder a las preocupaciones de la gente y leer sus opiniones, descubrir lo que es relevante y lo que podéis incorporar a vuestro plan. ¿Qué pueden hacer, de ahora en adelante, para ayudaros?

Pete Mackey: Ahh, bueno, estamos mirando todas sus opiniones, sean dirigidas específicamente a nosotros o comentarios puestos aquí y allá. Pero déjame volver un poco atrás. El cambio del modelo exponencial al modelo de tercer orden es significativo a nivel de sensaciones de pilotaje. Aunque las naves entreguen el mismo rendimiento en lo que respecta al tiempo que les lleva completar una acción, la sensación de eso no se parecen en nada. Eso va a cambiar y eso es lo que vamos a utilizar para dar a cada nave su propia personalidad. Estaremos mirando en dos direcciones distintas. ¿Funciona este equilibrio para las naves? ¿Las naves se perciben idénticas al maniobrar con naves de rendimientos similares pero diferente diseño? Estas son las dos cosas principales que vigilaremos y cualquier opinión que recibamos en este sentido será más que bienvenida.

Jared Huckaby: Aseguraos de indicar que nave estáis pilotando y, una vez que el sistema de itemización esté implementado, aseguraos de indicar también qué impulsores estáis utilizando y la configuración. Siempre estamos leyendo.

Pete Mackey: (Risas) ¡Por supuesto!

Jared Huckaby: Yo siempre leo. Chicos, muchas gracias. El mensaje debería salir más tarde y este vídeo debería estar incrustado en él si no lo viste. John, Pete, gracias por hacer esta conferencia conmigo.

Ben Lesnick: Calyx, Pete, y John han estado duramente trabajando en hacer este mensaje realidad.

CÓMO SE HIZO EL SONIDO DEL MAPA ESTELAR 29:30 El Mapa Estelar del Arca ha sido nominado en múltiples premios web, incluyendo ganar el Premio CSS.

Philip Smallwood: Hola, soy uno de los diseñadores de sonido de Foundry 42. Cuando empezamos a trabajar en el sonido del mapa, yo y Matt nos dividimos el trabajo a partes iguales. Estuve feliz por combinar nuestros esfuerzos.

Una de las primeras cosas que me encargaron fue los puntos de salto cuando se viaja de un sistema solar a otro. Lo diseñé tomando una serie de sonidos de un puñado de bibliotecas de sonido que tenemos a nuestra disposición. Aquí los podéis ver en el programa de edición, efectos de viento, de retumbes, truenos. Tenía unos sonidos del Cometa Rosetta que molaban mucho; pero no pude utilizarlos por razones de copyright. (risas)

Lo que intentamos conseguir fue tener un aspecto elemental, así como uno más digital; porque es una representación digital del espacio y conexiones a lo largo de la galaxia, pero también queríamos que tuviese un "peso" estilo ciencia ficción. Una mezcla de elemental con interfaz de usuario

Matteo Cerquone: La primera cosa que hice, obviamente, fue escucharme el sonido que Philip había ya creado.

Philip Smallwood: Lo que hago típicamente es arrastrar un montón de recursos sonoros al editor y entonces procesarlos para obtener unos elementos más ciencia ficción de ellos, como esta explosión real pasada por un efecto de cristalización y volcán para darle una buena reverberación con mis plugins, que aquí no hay...

Matteo Cerquone: (risas) Yo no tengo tantos instalados como el resto de la gente, si.

Philip Smallwood: No pasa nada (risas, toquetea explosión y trueno antes de llegar a una explosión sintetizada con un toque de volcán). Y también cosas de la "vieja escuela" como "whoooshes", viejos trucos como coger una explosión, duplicarla y revertirla.

Matteo Cerquone: Yo intenté no pensármelo mucho y crear sonidos para ver cómo de bien encajaban con las imágenes en si. El problema que teníamos al principio es que cuando creábamos los sonidos, como el de punto de salto o zoom, es que eran muy potentes al poner la música. Y como la música era tan inmersiva y los sonidos la ahogaban tanto tuvimos que volver a ajustarlo. Lo que tenemos aquí es una combinación de diferentes sonidos. Normalmente, en mi tiempo libre, intento crear mis propios sonidos para poder usarlos de referencia o reutilizarlos. Es como este que tengo aquí renombrado como "sonido de arma de ciencia ficción", lo diseñé específicamente como el ruido que se hace al desenfundar un arma con un toque de ciencia ficción, pero cuando volví a revisar mi diseño de sonido me gustó mucho y decidí que lo quería tener en el mapa.
La capa de sonidos es siempre un conjunto de bibliotecas de sonidos. Yo uso todo el rato Massive, por ejemplo.

Philip Smallwood: Cuando nos asignaron el mapa estelar nos lo entregaron con unos sonidos temporales de referencia que teníamos que sustituir. Lo que hicimos fue buscar las cosas que molaban más del mapa y quedarnos con ellas. Yo me quedé con los puntos de salto, zoom in y out y entre yo y Matteo hicimos los sonidos.

Matteo Cerquone: De nuevo, es difícil explicar lo que hicimos en realidad porque básicamente lo que hacemos es darle al botón de grabar y empezar a glitchear cosas (Philip sonrie), por lo que hicimos estas regiones muy grandes de sonidos y regresamos a ellos para editarlos cuando los oíamos de nuevo para tomar los elementos que más molan.

Philip Smallwood: No hay un rendimiento en esto. Tienes que grabarlo y toquetear cosas aquí y allá. Una gran parte de lo que hacemos son felices accidentes y no obtienes lo que quieres. ¡Lo difícil es recrear lo que hiciste!

Matteo Cerquone: Exacto.

Philip Smallwood: Saber lo que pensabas cuando lo hiciste. Intentamos ir en nuevas direcciones y también usar sonidos muy reconocibles en la cultura popular.

Matteo Cerquone: Al final, no hay reglas fijas. Como era en el espacio queríamos que fuese algo artístico y bello que encajase con la música en vez de intentar hacerlo muy específico.

Philip Smallwood: Es encontrar un punto medio y crear algo especial.

EMPIRE REPORT, ÚLTIMAS NOTICIAS 36:30

Alan Nuevo: Estamos recibiendo noticias de que ha tenido lugar una gran explosión industrial en Marte. Conectaremos ahora con Victoria Hutchins, la cual estaba allí en otra comisión cuando tuvo lugar el siniestro. ¿Victora?

Victoria Hutchins: Así es, Alan. Fue hace aproximadamente una hora. Estaba paseando junto a muchas otras personas en Port Renatus cuando tuvo lugar una gran explosión. Aunque los detalles aún no han sido confirmados, una gran humareda parece que se eleva desde la Refinería de Shubin Interstellar, la cual opera una muy atareada operación geológica aquí. De nuevo, no hay nuevas noticias sobre la extensión de los daños o las heridas que hayan tenido lugar en estos momentos.

Alan Nuevo: Gracias, Victoria. Más detalles en cuanto estén disponibles y esperad ver una actualización completa sobre esta noticia en el Empire Report de esta noche.

MVP
Stargazer, que voló junto a la Agencia Espacial Francesa y llevó su modelo de la Constellation para que volase en gravedad cero.

  • También agradecemos a los miembros de Operation Pitchfork que nos hayan enviado su manual de operaciones para nuestros escritores, que incluye los parches de logos que han creado... es un proyecto que mola mucho y que tenemos muchas ganas de masacrar sin piedad.

SNEAK PEAK
Otra versión de la Khartu-al

5
FrostRaven

EL FUTURO DEL VUELO

Desde el lanzamiento original del Arena Commander, hemos incrementado la velocidad máxima, reducido la disponibilidad de los posquemadores y reducido la potencia de los impulsores de maniobra. Aunque estos han tenido drásticos efectos sobre el juego, ninguno de estos han sido un cambio fundamental en la manera en que en realidad funciona el juego... ¡lo cual demuestra cuanto puede afectar a un sistema el equilibrado de unas estadísticas! Sin embargo, entre bambalinas, hemos estado trabajando en unos cambios más profundos al modelo de vuelo y estamos acercándonos al momento en que parte de ese trabajo pueda ser puesto frente a los jugadores.

Modos de Vuelo (también conocido como IFCS 2.0)

La característica nueva más ostentosa es los modos de vuelo adicionales: Precisión, Maniobra de Combate Espacial (SCM) y Crucero. Todos estos son perfiles de IFCS que hacen que el comportamiento de la nave se centre en objetivos muy diferentes como ajustes de muy baja tolerancia, acciones de combate y vuelo de larga distancia. Aunque sólo puedes usar uno de estos modos al mismo tiempo, acoplado/desacoplado y la colección de asistencias de vuelo todavía pueden ser utilizadas para mejorar todavía más su manejo.

Modo de Precisión

Cuando despegues empezarás en Modo Precisión. En Modo Precisión, la velocidad máxima se verá reducida de manera significativa y el empuje y aceleración son re-escalados de manera que se mejore el control cuando se maniobre en las cercanías de otros objetos. Esto hace que el aterrizaje y el despegue sean mucho más fáciles, pero también mejora el control en torno a otros objetos como asteroides, naves a la deriva o cuando te aproximes a otra nave en movimiento durante las maniobras de Repostaje en Vuelo o el Abordaje.

Modo SCM

Una vez te hayas separado de los objetos que estén cerca y hayas alcanzado cierta velocidad querrás cambiar al modo de Maniobra de Combate Espacial. SCM es uno de los mayores cambios en el sistema de control de vuelo, pero superficialmente imita mucho las mecánicas de vuelo que tenemos ahora y a las que os habéis acostumbrado en Arena Commander. El auténtico poder del modo SCM es que la velocidad máxima será calculada ahora de manera dinámica como una función de la fuerza y la masa: F/m * T = Velocidad Máxima en SCM. Hemos incorporado el cálculo de SCM de tal manera que es tu habilidad de detenerte por completo desde cualquier eje de giro (x o z) la que determinará la velocidad máxima a la que podrá volar tu nave. Esto significa que mejorar los impulsores de maniobra generalmente implicará que se permitan mayores velocidades máximas a través del IFCS. Además, esta velocidad es determinda por el mejor eje de giro de la nave, lo cual significa que el mejor control de deriva se obtendrá girando sobre el eje más fuerte, en vez de sobre el más débil. Cada nave tendrá una configuración distinta de ejes débiles y fuertes y es cosa del piloto aprenderlas y utilizarlas en su favor.

Posquemador

Hay otro emocionante beneficio a este cambio del SCM: Posquemador (afterburner). Mientras que la mecánica de impulso (boost) actual te proporciona mejor aceleración y control de deslizamiento, el Posquemador te proporcionará una mayor velocidad máxima mientras se mantiene un control similar. Esto funciona así: en modo SCM la velocidad máxima es obtenida mediante tu habilidad de acelerar en una cantidad de tiempo. Ya que el impulso incrementa tu aceleración, tu velocidad máxima también se incrementará. El Impulso tal y como funciona ahora mismo todavía está en este sistema, pero ahora los jugadores tendrán la elección sobre cómo quieren utilizar su limitada cantidad de combustible de impulso: en máxima velocidad para cambiar la distancia con rapidez o en una mejor capacidad de frenado para mejorar su maniobrabilidad.

Modo Crucero

Para el viaje a larga distancia en la misma zona local los Pilotos tendrán ahora la habilidad de utilizar el Modo Crucero. Si el límite de velocidad definido en SCM da al piloto control a cambio de velocidad, el Modo Crucero da al piloto velocidad a expensas del control. Y aunque la velocidad máxima es alta, la aceleración disponible no cambia, lo cual significa que alcanzar la máxima velocidad de Crucero llevará de más de 15-20 segundos, la velocidad de giro no escala con la velocidad y detenerte por completo llevará mucho más tiempo usando los retro-impulsores normales de la nave.

Ya que las velocidades de crucero pueden alcanzar con facilidad x5 veces más velocidad que lo que puede controlar con seguridad el modo SCM, el IFCS fuerza el giro controlado para asegurarse de que los pilotos no se metan en deslizamientos sin control. Esto significa que el morro de la nave está fijado al vector de velocidad y que las maniobras en modo Crucero consistan más de ajustes de tu curso y menos en hacer giros. No hace falta decir que el Crucero no está diseñado para ser utilizado en combate, campos de asteroides o rutas espaciales con mucho tráfico.

Por supuesto, siempre se puede utilizar el modo desacoplado para rotar libremente a velocidad de crucero. Los pilotos astutos descubrirán con rapidez cómo usar el modo desacoplado y el impulso para frenar con sus motores principales tan rápido como sea posible. De la misma manera, los pilotos descubrirán que intentar cambiar de dirección 90 grados usando modo desacoplado es un billete expreso al mundo de los sueños, ya que las altas fuerzas-g implicadas en tales maniobras te llevarían rápidamente a un desvanecimiento o a la eritropsia.

Salto Cuántico

Más allá de esos modos de vuelo estará el Viaje Cuántico, la única situación en la que todas las naves están limitadas a la misma velocidad de 0.2c. Una vez que se ponga en marcha el Motor Cuántico, la nave acelerará rápidamente hasta alcanzar el límite de 0.2c - los pequeños saltos puede que nunca lleguen a ir tan rápido - con la propia nave experimentando una aceleración relativamente pequeña. A estas velocidades, pequeñas variaciones de ángulo resultarían en vastos cambios de trayectoria, por lo que aquí es donde las naves más lentas tendrán la oportunidad de escapar de las naves más rápidas que les persiguen. Por supuesto, viajar a estas increíbles velocidades es bastante peligroso, por lo que la computadora de la nave te sacará automáticamente de Viaje Cuántico si se detecta la posibilidad de una colisión o la nave tiene algún escudo bajado.

Módulos de Control de Vuelo y Mejoras

Uno de los objetivos de diseño que se presentó en el alba de este proyecto es el concepto del que el software de control de vuelo debería estar representado de manera física como un objeto en el mundo de juego. Pero hasta ahora el sistema IFCS ha estado completamente entre bambalinas y ha sido administrado a través de unos (relativamente) estáticos archivos XML. Se ha hecho mucho trabajo durante los últimos meses para preparar los bloques de parámetros del IFCS para su migración a el módulo de aviónica, que podrá ser cambiado por otro o mejorarlo. Cada módulo es utilizado con una nave específica y contiene todos los ajustes y parámetros que necesita conocer el IFCS sobre la nave para hacerla volar dentro de las especificaciones de ingeniería establecidas. Esto hace que para los diseñadores sea vastamente más sencillo el ajuste y equilibrado de las naves y de las mejoras de impulsores y nos da a nosotros más flexibilidad a la hora de dar características únicas a las distintas variantes de casco de las naves. Pero la parte más excitante es que los jugadores pronto podrán mejorar su software de control de vuelo junto a sus hardware de impulso para construir una nave que se ajuste a su propio estilo.

Control de Movimiento

El mayor cambio en el IFCS es su cambio a un sistema de control de tercer orden de movimiento. Antes de este lanzamiento, el IFCS ha usado un sistema de control por respuesta en su control de movimiento espacial. El perfil de movimiento para este sistema de control de respuesta (un controlador PI) es un sinusoide exponencialmente amortiguado. El gráfico 1 muestra tanto la aceleración como el control de velocidad a medida que la velocidad pasa de 0 a 100 m/s.


Gráfico 1

Este es un sistema de control iterativo que no hace ninguna suposición sobre el estado futuro o pasado del sistema y simplemente actúa para suavizar el error entre el estado actual de la nave y el estado objetivo. Debido a esto, es muy apropiado para nuestras necesidades, ya que las condiciones de daño y las fuerzas externas inesperadas pueden causar movimientos impredecibles.

Para complicar todavía más el asunto, debido a que el IFCS está limitado por la cantidad de empuje disponible por los impulsores de la nave, el auténtico perfil de movimiento del juego está limitado. Este perfil se puede ver en el Gráfico 2, con el perfíl sin límites mostrado detrás como referencia.


Gráfico 2

El gráfico de la segunda imagen es una descripción bastante ajustada del actual control de velocidad en las naves de Star Citizen, tanto para el control lineal como el rotacional. Aunque hay múltiples ventajas en este perfil de movimiento, hay algunas desventajas significativas, incluyendo A) Una dificultad en predecir el futuro estado de la nave cuando se mueve bajo este control y B) una respuesta de control asimétrica con un tiempo de asentamiento extendido. En particular, los jugadores han indicado a menudo que el tiempo de asentamiento extendido que tienen las naves hace que el vuelo de la naves de Star Citizen parezca "descuidado".

Para ocuparnos de estos problemas, el nuevo lanzamiento del IFCS empezará a usar un sistema de control de dos niveles. El primer nivel, el control de prealimentación (feed-forward), calculará el movimiento ideal que tendría la nave, mientras que el segundo nivel, el control de realimentación (feedback), proporcionará la corrección de errores que mantendrá la nave tan cerca del movimiento ideal como sea posible, incluso bajo una condición dañada o bajo fuerzas externas inesperadas. Así pues, el algoritmo de movimiento actual seguirá siendo parte del sistema, proporcionando la misma tolerancia a los errores, pero no será ya el perfil de movimiento dominante (excepto si se encuentra bajo un error del sistema extremo).

El sistema de control de prealimentación usará el movimiento ideal de tercer orden, tal y como indica el Gráfico 3.


Gráfico 3

Al contrario que el algoritmo de retroalimentación, este perfil de movimiento es completamente predecible. En cualquier momento, se sabe cuando tiempo tardará la nave en llegar a una nueva velocidad o posición desde cualquier conjunto de condiciones iniciales. También se podrá ajustar la fase de incremento de aceleración para que las naves tengan un movimiento natural y suave, sin el excesivo comportamiento de ajuste que tiene el actual sistema de control.

En la práctica, esto resultará en que habrá un abanico de comportamientos mucho más amplio, desde una respuesta potente y nerviosa como la de un coche deportivo, a una menos ágil pero suave, como la de un coche de lujo.

El ritmo de cambio de la aceleración se denomina como "arranque" (Jerk), y es esencialmente la aceleración de tu aceleración. Una manera fácil de entender lo que es el arranque es pensar en cómo conduces tu coche. Cuando frenas tu coche para que se detenga por completo aplicas una cantidad constante y firme de deceleración y la frenada es mucho más suave y cómoda. Frenar suavemente es una acción con bajo arranque, mientras que pisarlo a fondo es una acción de alto arranque.

Como referencia, el gráfico número 4 muestra el típico movimiento de segundo orden (aceleración constante, velocidad linear) utilizado en muchos juegos.


Gráfico 4

Aunque el movimiento de segundo orden es un modelo de control mucho más sencillo, proporciona un movimiento de nave muy rígido y mecánico. El sistema de tercer orden nos permitirá ajustar las naves para que sean tan rígidas o suaves como necesitemos que sean.

Equilibrado

El equilibrado del vuelo de naves es una de las tareas más delicadas y difíciles que tenemos en este proyecto. El movimiento a un sistema del tercer orden y la adición de un modo de velocidad dinámica determinado han requerido de una re-equilibrio prácticamente desde cero de las características de control de las naves. Esto significa que cada una de las naves probablemente se notará muy distinta respecto a lo que solíais sentir en el Arena Commander. Se ha tenido mucho cuidado, asegurándonos de que cada una de las naves retuviese su propio lugar en relación con las otras naves del universo. Somos conscientes de que cualquier cambio de esta magnitud va a iniciar un vivo y apasionado debate entre lo viejo y lo nuevo, pero estamos seguros de que los cambios nos permitirán hacer que las naves parezcan más reales y que esto les permita tener una personalidad más única de lo que antes tenía y al mismo tiempo se les proporcione un control más preciso.

El cambio a los arranques significa que las acciones erráticas que se utilizan para hacer maniobras evasivas sean nerfeadas de manera natural, ya que ahora el sistema es ligeramente más lento a la hora de tomar acciones contrarias, mientras que las órdenes dedicadas, como las que se usan para lograr un deslizamiento, no se verán muy afectadas. El movimiento de tercer orden también es algo mucho más natural para el cerebro humano, así que el control será más intuitivo y por lo tanto las sobre-compensaciones serán menos necesarias.

Ahora que el arranque está disponible como un nuevo parámetro, un nuevo comportamiento de "vuelo estabilizado" está a nuestra disposición. Esencialmente, esto significa que al poner un pequeño valor de arranque en un motor este pueda ser ajustado para que tenga un alto Valor de Carga relativo a su tamaño, permitiéndonos crear naves - como la serie-Hull o la Aurora - capaces de transportar mucha carga sin que se conviertan al mismo tiempo en las naves más rápidas del universo cuando no estén cargadas. Y, aunque las naves serán más rápidas sin carga que con carga, podremos configurar naves distintas para que tengan diferentes niveles de pérdida de rendimiento cuando se vaya aumentado su carga.

La primera pasada que lancemos al PTU será simplemente eso: una primera versión. La intención es que indique el tono general en que se dirigirá cada una de las naves, no su destino final. Como siempre, continuaremos probando y ajustando, y estaremos observando vuestros comentarios para ver si nosotros necesitamos ocuparnos de algún caso extremo o alguna consecuencia no pretendida.

Hay algunas cosillas más que vendrán como consecuencia a estos cambios, pero por ahora, hablemos de la deriva de empuje (thrust shunting)

El Indomable Will Deriva
(ndt: Good Will Shunting, lo siento, el juego de palabras aquí con The Good Will Hunting no tiene mucho sentido XD)

La Deriva de Empuje es el proceso mediante el que un empuje es generado en el motor principal y luego redireccionado a través del sistema de conductos de la nave hasta llegar a las distintas toberas (o "mavs", tal y como la comunidad los ha apodado, ndt: de maneuvering thrusters, impulsores de maniobra) a través de los cuales se usa la fuerza. Esto significa que los motores principales serán mucho más importantes ahora de lo que nunca hemos visto en Arena Commander, y más adelante, significará que podremos tener salas de máquinas enteras en nuestras naves capitales. En vez de tener motores repartidos por toda la nave ahora tendremos simplemente unas toberas accionadas, así que si el motor principal es dañado los impulsores de maniobra dejarán de funcionar. Cuando esto suceda, las naves tendrán giroscopios internos que podrán ser usados en caso de emergencia o para maniobras de intensidad super-baja, pero serán débiles y lentos. Lo más fantástico de esto es cómo esto abre nuevas oportunidades a la hora de dañar los comportamientos de vuelo de las naves.

Un conducto de empuje dañado reduciría proporcionalmente el empuje disponible en esa tobera, y podría incluso introducir un impulso no pretendido en el punto de impacto.

Las propias toberas tendrán clasificaciones de calor y potencia, limitando la cantidad de empuje disponible - un límite que podrías exceder, aunque bajo tu cuenta y riesgo. El resultado es un equilibrio de comportamientos de vuelo que se refuerza por el propio diseño de la nave y el estado de sus componentes, comportamientos que un piloto habilidoso podrá llevar a su límite para cabalgar la delgada línea que separa la victoria de la catástrofe.

Error de Impulsores y Turbulencia

Hay muchas maneras en las que el estado actual de la nave puede desviarse del estado ideal solicitado por el IFCS. Hasta este momento hemos permitido que el sistema de control tenga un control perfecto bajo condiciones ideales, y esto crea un movimiento demasiado mecánico y a menudo de aspecto "muerto". Con el nuevo lanzamiento, esto ya no sucederá. Siempre habrá algún nivel de error en los impulsores y el sistema en tu control de vuelo. Esto se manifestará como una turbulencia menor bajo condiciones operativas ideales, pero se volverá mucho más extremo cuando los impulsores sean dañados, se sobrecalienten u otros factores.

El gráfico número 5 indica una muestra de un perfil de velocidad del tercer orden. El IFCS debería solicitar empuje al sistema de impulsores para lograr este movimiento.


Gráfico 5

Pero, debido al error de los impulsores, el cual puede incluir una serie de cosas desde un vector o potencia de empuje incorrecto, un vector o empuje inestable, etc, el movimiento real de la nave se podrá desviar del movimiento ideal. El siguiente gráfico muestra un ejemplo extremo de un error aleatorio en los impulsores que causa que la velocidad de la nave se desvíe de la velocidad ideal en una transición desde los 0 a los 100 m/s. Debido a los errores que tienen lugar durante las aceleraciones aplicadas (todas las acciones de una nave son finalmente aplicadas como aceleraciones, nunca directamente como correcciones de posición o velocidad) a lo largo del tiempo, la velocidad final lograda durante un cambio en la velocidad de la nave puede ser significativamente distinto del que se pretendía. El IFCS solicitó la velocidad de más arriba y obtuvo la mostrada en el gráfico número 6.


Gráfico 6

Aquí es donde el sistema de retroalimentación original entra en juego. Este compara el estado actual de la nave y lo compara con el estado pretendido y genera aceleraciones correctivas adicionales para mantener el movimiento tan cerca de lo ideal como sea posible.

El ejemplo mostrado en el Gráfico número 7 es para el error en la velocidad y la corrección de retroalimentación, pero un ejemplo más obvio en el juego se encontraría en el control de posición. El IFCS tiene un sistema de control de reacción (RCS, reaction control system) que mantiene la posición de la nave tal y como ha sido indicada por el piloto (el marco de control). Debido al error de los impulsores, así como otros factores externos, la posición real de la nave se puede desviar de la posición ideal. El RCS utiliza el sistema de control de retroalimentación para generar impulso y mantener la posición de nave en su posición pretendida. En la práctica, la turbulencia de los impulsores generada por un rendimiento de impulso imperfecto generará una pequeña cantidad de juego de impulsores en el morro de la nave, especialmente cuando se disparen los impulsores a máxima potencia y cuando se intente pasar a un estado inmóvil. Pero, de nuevo, el objetivo es que este nivel de errores sea sutil a no ser que se encuentre bajo condiciones de daño extremas. Esto gira más en torno a la estética del movimiento que en torno al comportamiento de vuelo.


Gráfico 7

Listo para el Combate

Al final, la experiencia de Star Citizen es una combinación de todos sus sistemas, así que para explicar el vuelo de verdad, tenemos que hablar también sobre el combate.

El objetivo del combate en Star Citizen es proporcionar acción frenética y rápida mientras al mismo tiempo se recompensa la planificación y las tácticas astutas. Esto significa cosas distintas en las diferentes escalas de naves - desde las intensas escaramuzas de los cazas monoplazas, a las batallas de maniobras de giro estilo SGM para poner todas las armas sobre el enemigo de las multitripuladas, hasta llegar a las guerras de desgaste y posición de las gigantescas naves capitales - cada una ofreciendo su propio sabor al combate. Aún así, la filosofía para todas ellas es básicamente la misma: el combate es más divertido cuando se está jugando con diferentes niveles de riesgo, recompensa y entrega.

Para la mayor parte de las naves, el mínimo denominador común de cualquier orden es la rotación. Los límites de seguridad de la tripulación limita que las naves realmente grandes hagan giros agresivos, pero para las naves más pequeñas, el giro es mucho más fácil. Ofensivamente, esto hace que la puntería sea más importante (de nuevo, con rendimientos decrecientes en función a la escala), pero defensivamente, los pilotos habilidosos intentarán tomar los impactos que no se pueden evitar donde sus escudos y blindajes son más fuertes. El manejo de la rotación se mejorará con la adición del modo de estabilización del manejo (Ndt: input stabilization mode), el cual restringe las rotaciones a su menor índice máximo disponible, eliminando una gran parte del error de escala en el marco de control. Las propiedades de la nave no se ven afectadas por esto, por lo que las maniobras todavía favorecen de manera realista un eje en particular de acuerdo a su diseño, pero el propio manejo es mucho más predecible e intuitivo.

Generalmente las naves son diseñadas para que se favorezca el uso de los motores principales, aunque los índices de potencia de estos son en su mayor parte los que crean la personalidad de cada nave. Esto significa que el deslizamiento, como hemos visto en los parches más recientes, y las maniobras de vuelo requieran algo más de planificación, incluso con el uso del modo de impulso. Esto hace que disparar sea de nuevo más fácil, pero recibir daño es también un gran parte de la experiencia de Star Citizen y es algo que apoyamos a todos los niveles. La elección a la hora de incluir múltiples componentes de cada tipo nos permite tener una degradación de capacidades mucho más significativa y que las naves sigan estando operativas a niveles de daño mucho mayores. Tras la lucha, tu nave estará llena de cicatrices de su última aventura. O, si las cosas se ponen feas, serás capaz de reparar las naves sobre la marcha y hacer triage de los daños que se vayan aplicando. Será probablemente una buena idea que te ocupes de esos conductos de disipación que fallan antes de que provoquen un escape descontrolado en el motor y este una fusión total del reactor de tu planta de energía que vuele tu nave por los aires (te estoy mirando a ti, Connie...).

Con la habilidad de las naves de recibir más daño vienen mayores niveles de compromiso, lo cual significa una cantidad mayor de administración de cosas como el combustible, el calor, y las fuerzas-g. Cuantos mayores atajos tomes, más acorralado te encontrarás. Los capitanes tendrán que considerar el riesgo a largo plazo de la recompensa a corto plazo si quieren salir victoriosos.

Equilibrio

Por supuesto, todas estas cosas al final parten del equilibrio para el apoyo a estos sistemas, y el equilibrio es un proceso largo y profundo. Llevará algo de tiempo conseguir que el equilibrio sea el apropiado, pero el objetivo es que se aproveche de los puntos fuertes de cada escala, y de las oportunidades que permitirán en su jugabilidad. En las naves más pequeñas, la maniobrabilidad es la reina, así que la ventaja se obtiene forzando a tu oponente a tomar más riesgos, pasarse de listo y hacerse vulnerable a un ataque mortal. La rotación es sencilla en el espacio, por lo que podéis estar seguros de que cualquier nave a la que le dispares te disparará a ti poco después. Una de las razones para esto es las simples físicas, ya que a medida que las naves se vuelvan más masivas el empuje necesario para ofrecer rotaciones rápidas escalará drásticamente, y por razones de retroalimentación de control y de manejo funcional, las rotaciones de nuestras naves tendrán menores posibilidades de error que las traslaciones. Las naves multi-tripulación podrán permitirse tener mayores períodos de vulnerabilidad, ya que las próximas mecánicas de reparación, manipulación de escudos y enrutamiento de conductos ofrecerán a una nave bajo ataque múltiples maneras de mejorar su situación y cambiar el rumbo de la batalla.

A medida que estas naves se vuelvan cada vez más grandes, la jugabilidad empuja cada vez más la aparición de un pensamiento táctico más exigente, con la administración de los recursos de la nave y su posicionamiento convirtiéndose cada vez más en las preocupaciones más importantes de una lucha. Un objetivo clave de este tipo de combate es evitar que el éxito o el fracaso se conviertan en algo demasiado binario, o permitir que la batalla sea determinada por unos pocos (incluso pequeños) errores. A un nivel fundamental, Star Citizen es un juego en el que combate de nave a nave debería seguir siendo divertido y justo aunque una nave de transporte se viese atacada por pirata o una nave capital por cazas, ya que la pérdida de propiedades y vidas tienen un precio muy alto. No ganarás siempre y cuando sufras una pérdida, queremos que se perciba como que al final fue una cuestión de habilidad. Queremos que esté basado en tu habilidad, pero también queremos que exista una sensación de progresión en el Universo Persistente. Un Hornet F7C debería ser una nave objetivamente mejor que una Mustang Alpha, pero las diferencias de potencia no deberían ser tan extremas que un piloto de Mustang no pueda derrotar jamás a un Hornet: sólo sería una lucha más desafiante.

Star Citizen es un juego sobre elecciones, así que cada vez que abandones tu hangar tendrás que decir qué naves quieres pilotar, qué equipo quieres instalar, a quien escoges como tripulación e incluso dónde y cuando almacenarás carga. Cada nave tiene su personalidad, cada nave su ventaja y su desventaja: cada camino tiene sus peligros. El objetivo no es hacer que sea todo para todo el mundo, si no crear un ecosistema en el que los jugadores puedan encontrar la combinación apropiada para ellos. Algunos preferirán especializarse, y en la muy estrecha ventana de su especialidad encontrarán el éxito: otros preferirán ser autónomos y encontrarán una variedad de configuraciones que se ajuste a los distintos obstáculos que se encontrarán. Estas elecciones lo afectan a todo, desde el consumo de energía a la carga de calor, hasta llegar a lo rápido que vuela una nave o cuanto se desliza.

No hay una nave perfecta: sólo la nave perfecta para ti.

Únete a la discusión aquí.

FIN DE LA TRANSMISIÓN

5
Y

".MODOS DE VUELO."

El nuevo cáncer de Star Citizen dicho con otras palabras.

En vez de dejar que todos tengamos a nuestra disposición la decisión de maniobrar la nave como nos salga del cojón derecho, nos van a poner 3 modos de vuelo que en esencia son scripts que cambian completamente la manera en que el juego aplica los imputs que percibe de un mismo movimiento de un eje analógico (joystick, acelerador, etc).

Por ejemplo. Si movemos la palanca de gases al 50% en un modo concreto, la nave se pone a 100m/s y en otro modo diferente la nave se pondrá a 200m/s así por arte de magia, aunque la palanca de gases siga estando en el 50% todo el tiempo.

Eso señoras y señores es una puta mierda más arcade que la hostia.

Ya las físicas dan risa con ese motor gráfico que está pensado para caminar por la tierra en un fps de toda la vida como Crysis. Los vehículos y aeronaves son secundarias y no fue pensado para esto. Pero es que encima no paran de arcadizar más el juego que se suponía que sería un simulador espacial. No un arcade espacial.

2 respuestas
Xeros_Grey

#18119 Eso es una estupidez. ¿Desde cuando poner más opciones es sinonimo de arcade?

Son tres modos de vuelos seleccionables (espero) según la necesidad, tu comparación con la palanca de gases es acertadas, pero eso tambien lo podrias aplicar a las marchas de un coche, el elite tiene un sistema similiar cuando sacas el tren de aterrizaje y no veo echar mierdas sobre eso pero claro el hate puede más que la objetividad.

5 1 respuesta