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
Shaka

Hacia casi un mes que no entraba y ... lo veo mas fluido ????

1 respuesta
X

#19939 Si no recuerdo mal, el 2.1 salió "oficialmente" en Enero. El PTU es un mundo aparte. El 2.2 tendría que salir en Febrero para mantener el ritmo mensual.

2 comentarios moderados
dewasha

soy yo o me parece que ultimamente el desarrollo esta un poco apagado o aburrido? nose antes en cada nueva nota mensual o 10ftc veias cosas interesantes y relevantes y ahora parece que son reuniones de colegas que traen pocas o 0 novedades o cosas interesantes sobre el desarollo en este año...

1 1 respuesta
FrostRaven

#19951 Hacen optimizaciones, entre ellas que las IAs no petardeen el servidor con peticiones aunque no las veas, que la Constellation no tenga un bug que baje los FPSs cuanto más cerca estás de ella, han estado añadiendo más LODs a las naves y optimizando los que ya tenían, mejoras del código de red etc A veces sube y a veces baja, depende del parche.

#19955 Siempre pasa lo mismo. De Agosto a Diciembre es subidón porque van revelando en eventos cosas guapas y todo eso y luego llega Enero y a la gente se les baja la sacarosa y se dan cuenta de que el juego sigue en desarrollo y no pueden sacarse de la manga algo increíble cada semana XD Míralo en perspectiva, esto pasó todos los años.

Ahora mismo están trabajando en poner pilotables la Sabre. La Reliant, la Khartu, la Herald y la Starfarer se acercan al hangar y que luego sean pilotables, mientras en el 2.2 ponen al menos el vuelo EVA fisicalizado y algunas cosillas más.

X

Por cierto, la semana que viene, 2.2 en PTU. No van a dar acceso a todo el mundo, este va a ser por tandas de invitaciones. Ya sacarán las novedades del parche cuando lo saquen.

FrostRaven

COMIENZO
Sandi y Ben inician el programa repasando los contenidos de este episodio y el Señor Lesnick comenta que el Parche 2.2 está muy muy cerca de salir ya en el PTU. Tan pronto como el equipo de Control de Calidad interno lo haya purgado de los peores bugs lo pondrán en el PTU, estad atentos al commlink.

Star Citizen ya se ha separado de la campaña para un sólo jugador, Escuadrón 42 Episodio I. Ahora mismo se pueden comprar Star Citizen por separado y Escuadrón 42 en un bundle junto a Star Citizen. Escuadrón 42 se venderá por separado a partir del lanzamiento de 2.2, porque necesitan algo de tiempo para asegurarse de que los poseedores de ese pack tengan un acceso funcional a Arena Commander.

BBC Click hizo un reportaje de Star Citizen que fue muy bien recibido y consideraron bastante objetivo. Echadle un vistazo si os interesa. (ndt: no dicen nada nueve en ese vídeo, así que tampoco hace falta traducirlo). También hicieron otro evento BarCitizen en Montreal con los chicos de Turbuent y Behaviour, que se reunieron con los fans como hicieron en el pasado en Austin o Los Ángeles.

NOTICIAS

CIG Los Ángeles - Arena Commander Eric Kieron Davies y Adrian Banninga

  • Gurmuckh está trabajando en arte conceptual adicional para la Caterpillar febrilmente.
  • Documento de Diseño de Escudos en revisión.
  • Arte conceptual adicional para personajes, especialmente los BDUs (Battle Dress Uniforms, uniformes de faena), de mano de Omar (Aweidah) y Jeremiah (Lee).

CIG Manchester - Escuadrón 42 Jake Ross y Tom Johnson

  • Jake está de visita por Manchester así que les pareció buena idea que presentase desde la "soleada" Inglaterra, donde están planeando futuros calendarios y mucho trabajo interesante en Microsoft Project del que no pueden hablar. Tienen que estar muy sincronizados entre las zonas horarias europeas y las americanas para solucionar bugs y trabajar juntos.
  • Jason Eli de Austin está trabajando con los de Turbulent para traer por fin persistencia al 'verso, creando una comunicación entre la plataforma web y el servidor del backend.
  • Para Compras en el 'verso están trabajando en una fórmula de precios para cada uno de los artículos de ropa que podremos encontrar y comprar en Casaba Outlet. Tendrán unas cuantas opciones de ropa y luego variantes de las cada una de estas.

CIG Frankfurt - FPS/Motor Gráfico Brian Chambers

  • Están repasando la información que obtuvieron de las reuniones con Tony y Chris y Erin durante las semana pasada, y discutieron las escenas que tienen ya bloqueadas, el trabajo coordinado de cinemáticas entre Inglaterra y Alemania, el sistema de aprobación de trabajos etc
  • Se ha aprobado los cambios que harán al motor gráfico durante 2016 dando prioridad a algunas cosas y retrasando otras.
  • Se centraron mucho en la tecnología procedimental de los planetas y cual debe ser el estandar y las normas que utilizará el arte que crearán para los mismos.
  • Tuvieron discusiones sobre la tecnología de asteroides y cómo estos serán escalables una vez que los jugadores los puedan probar.
  • Muchas discusiones sobre IAs, ya que es bastante densa en este juego y empujando mucho lo que tradicionalmente se hacer con una IA: conversar, interactuar, sus reacciones positivas y negativas... Tienen toda una serie de terminología especial para estas cosas, pero como no sabe lo que han publicado oficialmente se corta y no comenta nada más, excepto que se habló mucho sobre IA de personajes, de naves espaciales y sobre la arquitectura IA que controla todo esto, de cuales necesidades tienen en el Universo Persistente y Escuadrón 42 para ver cuales se solapan.
  • En Producción han mirado que contrataciones tienen que hacer para los siguientes 6 meses y qué gente necesitan.
  • Diseño miró los sistemas de misiones en el Escuadrón 42.
  • Tony habló mucho de los módulos prefabricados que se usarán en el Universo Persistente y el sistema de conductos que utilizarán los entornos igual que las naves, como se comentó en esta misma sección en pasadas semanas por parte de Todd Papy.
  • Han clarificado responsabilidades y trabajos entre cada departamento y estudio, lo cual siempre es bueno.
  • Finalmente, agradece a los mecenas el apoyo que les han dado, cómo han apreciado el trabajo que hacen en Frankfurt y comenta lo contentos que están de trabajar en este proyecto y en un equipo global con tanto talento. Se lo están pasando genial.

ENTREVISTA CON ADRIAN BANNINGA, ADMINISTRADOR DE ARTE SENIOR

Jared Huckaby: Muy bien. Eres el Administrador de Arte Senior en la oficina de Reino Unido. ¿Qué es lo que haces?

Adrian Banninga: Soy el tipo que ayuda al Director de Arte, que las tareas asignadas al Equipo de Arte fluyen adecuadamente hasta que estén terminadas y que Producción no le mate.

Jared Huckaby: (risas) Han habido unos cuantos atentados a lo largo de los años, si... ¿Para qué tipo de cosas usamos a artistas externos subcontratados?

Adrian Banninga: Depende de nuestras necesidades en cada momento, básicamente. Los usamos para conceptos de naves, personajes, animaciones, creando algunas naves que hicimos en el pasado también... Lo que necesite arte en ese momento.

Jared Huckaby: En estos momentos tenemos artistas externos trabajando en la Prowler de Esperia.

Adrian Banninga: Bueno, la Prowler no está siendo trabajada en estos momentos porque hemos decidido ponerla en pausa porque decidimos volver a la especie Tevarin y conceptar apropiadamente su civilización. Hemos adaptado la Cadena de Montaje de Naves para que hagamos las cosas más estructuradamente que lo que hacíamos en el pasado. Primero tenemos que hacer la especie físicamente, hacer su guía de estilo artística de especie y a partir de ahí moverse adelante con las naves de la especie.

Jared Huckaby: ¿Quién está trabajando en los Tevarin ahora?

Adrian Banninga: Mark Skelton está dirigiendo a Chris Olivia a la hora de crear el concepto original de los Tevarin, y eso está sucediendo en estos momentos. Una vez que tengamos unos diseños bocetados se los enseñaremos a Chris y él eligirá los que le gusten, los iteraremos un poco más y refinaremos más las formas.

Jared Huckaby: Y entonces cuando estemos felices con los Tevarin, enviaremos la Prowler a un artista externo, ¿no?

Adrian Banninga: Cuando la especie tevarin esté definida el equipo de arte hará su Guía de Estilo, cosas como qué tipo de ropa visten, qué tipo de diseños tienen, qué tipo de arquitectura tiene su civilización siguiendo la ficción que han creado los escritores y a partir de ahí diseñamos la nave.

Jared Huckaby: Estás aquí de visita durante una semana. ¿Qué estás haciendo aquí?

Adrian Banninga: Repasando los artistas subcontratados externos que tenemos, viendo cómo podemos mejorar el proceso que tenemos, mantenerme al día revisando artísticamente lo que les hemos encargado y pensando en qué necesidades tendremos de contratación externas en el futuro, en 1 o 3 meses, y cómo podemos acomodar esto.

Jared Huckaby: El desarrollo de videojuegos es iterativo, por lo que siempre estás evaluando y reevaluando tus procesos para hacer mejor tus procesos.

Adrian Banninga: Si.

Jared Huckaby: ¿Cuanto tiempo llevas con CIG?

Adrian Banninga: Empecé hace 7 meses y medio.

Jared Huckaby: ¿Y dónde estuviste antes?

Adrian Banninga: Trasfondo muy variado. Antes estuve trabajando en un juego indie mío, llamado Darkout. Un pequeño juego basado en Terraria en un universo de ciencia ficción con una mecánica de luz y oscuridad cazando criaturas de las sombras con luz, intentando hacer algo distinto a lo que hicieron los chicos de Terraria. Los sandboxes eran muy populares cuando empecé a desarrollarlo, pero el proceso fue más largo de lo que imaginé, no me estaban pagando porque me prometían royalties futuros y es mucho más difícil que tener un juego completamente financiado.

Jared Huckaby: ¿Cuanto tiempo trabajaste en él?

Adrian Banninga: Unos tres años.

Jared Huckaby: ¿Está disponible ahora?

Adrian Banninga: Si, está en Steam.

Jared Huckaby: Mola, pues está allí si os interesa.

Adrian Banninga: Tuvo buena recepción en el aspecto visual, es un juego muy bonito.

Jared Huckaby: No quiero hacer esto muy largo, ¿pero dijiste que cruzaste a vela el Océano Atlántico cuando eras más joven?

Adrian Banninga: Si.

Jared Huckaby: Estábamos antes intercambiando historietas de nuestra juventud y ¿dijiste que cruzaste desde Ciudad del Cabo al Caribe? ¿Cuanto tiempo te llevó?

Adrian Banninga: Me llevó unos tres meses.

Jared Huckaby: ¿Por quéeee? ¿Por qué lo hiciste?

Adrian Banninga: A mis padres se les metió en la cabeza esta idea loca cuando yo tenía 16 años de construir un barco y surcar los mares. Y yo me apunté enseguida: ¿Quien quiere ir a la escuela cuando puedes irte a navegar? Así que acabamos construyendo en nuestro jardín nuestro barco y cuando tenía 19 años terminamos. Y nos llevó 3 meses ir desde Ciudad del Cabo al Caribe. Empezamos bien el viaje con una bonita tormenta en el Cabo, esa fue su propia aventura. Y luego todo lo que vino. No lo cambiaría por nada, fue una fantástica aventura.

Jared Huckaby: Es curioso tener alguien que construyó su propio barco dirigiendo la Cadena de Montaje de Naves espaciales (Risas)

Adrian Banninga: Cierto... ¡No lo había pensado así hasta ahora! (risas)

Jared Huckaby: Si, puede que tengas experiencia en ello y otro punto de vista. Gracias por venir, Adrian.

CÓMO SE HIZO: DATAFORGE, CON MARK ABENT

Jared Huckaby: ¿Qué es Dataforge?

Mark Abent: Dataforge es nuestra respuesta para resolver todos nuestros problemas con los "datos salvados" o "metadatos" a través de XML. Nos queremos deshacernos de todos estos XMLs que se mueven por todas partes en el motor gráfico para tener sólo una localización central a la que se envían los datos, donde se pueden modificar y almacenar los datos.

Jared Huckaby: CryEngine usa XMLs por defecto. ¿Por qué es importante para nosotros mudarnos de ese sistema y centralizar los datos?

Mark Abent: XML tiende a provocar errores. Puedo modificar una pequeña cosa y ahora todo eso está roto. Esto ha pasado muy a menudo con los XMLs de nuestras naves. Añades un pequeño comentario (a mi no me gusta esto, porque CryEngine no puede tener un comentario dentro de un comentario) y todo el XML se rompe. Puedes tener cosas sencillas como esas, doble citas o la cosa equivocada allí y de repente toda tu nave ha desaparecido y no sabes lo que has hecho mal. Y se vuelve especialmente problemático cuando tienes a mucha gente trabajando en los mismos XMLs y modificándolos al mismo tiempo. Cuando los fusionas se vuelve un lío.

Jared Huckaby: Y por supuesto, el juego en el que estamos trabajando es un poco más grande que lo que CryEngine fue diseñado originalmente a hacer.

Mark Abent: Si.

Jared Huckaby: Creo que nos estamos moviendo a una fase en la que los XMLs no son lo suficientemente robustos para nosotros.

Mark Abent: Si. Estaba bien al principio cuando tenías a alguien como Calyx, trabajando en solitario en ellos, pero ahora tenemos una docena de estudios trabajando en las mismas cosas y se ha convertido en una pesadilla.

Jared Huckaby: Cuatro estudios internos y subcontratas, no hemos crecido de la noche a la mañana y nos hemos expandido a 12 sin decirle nada a nadie.

Mark Abent: (risas)

Jared Huckaby: ¡Va a haber un hilo sobre esto, lo va a haber! ¿Así que Dataforge es una herramienta interna creada por Ashley Cunning?

Mark Abent: Si, Ash y David Gill. Ash es el programador principal, pero David le ayudó en algunas cosillas.

Jared Huckaby: ¿Y Ash empezó a trabajar en esto hace un año, año y medio?

Mark Abent: Se unió al proyecto hace dos años, en el momento en que se abrió la oficina de Manchester. No iba a trabajar originalmente en esto, iba a ser un Programador de Jugabilidad, pero un par de meses después de que le contratamos decidimos que necesitábamos una solución como esta y Dataforge era la respuesta. No sabíamos lo que iba a ser; pero necesitábamos que alguien trabajase en ello y Ash dijo "yo lo haré" (risas)

Jared Huckaby: ¿Por qué no nos enseñas un XML y lo que puede hacer Dataforge por nosotros?

Mark Abent: Aquí tenemos un proyectil de 20 mm que está dividido en dos XML: el que maneja los datos del diseño, la interfaz, y el que maneja los efectos gráficos. Tuvimos problemas a la hora de trabajar en estas cosas porque los diseñadores y los artistas se pisoteaban los unos a los otros en el trabajo, por lo que lo dividimos en dos.

Jared Huckaby: Incluso algo tan sencillo como una bala tenía 2 XMLs. Okey....

Mark Abent: La otra razón por la que teníamos dos es que solíamos usar algo llamado ScriptMonkey, algo que escribí yo para que en Excel tuvieses las propiedades de diseño de las armas y proyectiles y generase automáticamente los XMLs. Cuando alguien se pone a modificar las estadísticas usamos eso y el problema es que reajustaba todo y rompía lo que hacían los artistas, algo que no sabíamos en aquel momento. Si un artista entraba ahí y cambiaba el color de un láser y otro detalle y luego un diseñador tocaba algo y generaba el nuevo XML todo se iba al garete y se borraba.
Así que queríamos mantener el diseño de poder scriptar estas cosas, cambiando el diseño en un simple XML y que generase los cambios, sin tener que repasar cada uno de los XMLs del juego; pero también queríamos que los artistas pudiesen cambiar los XMLs, por lo que se tuvo que duplicar la cantidad de XMLs.
E incluso ahora se rompe de vez en cuando y de hecho dejamos de usar ScriptMonkey porque se volvió horrible de mantener tener por un lado un Excel y un XML; la gente iba directamente al XML. Hasta hoy en día hay algunos conflictos divertidos....

Jared Huckaby: Muéstranos qué puede hacer por nosotros Dataforge.

Mark Abent: En Dataforge no usamos XMLs ya, en vez de eso usamos el programa en si. Almacena todos nuestros datos: modos de juego, sistemas de conversación, personajes, ropa y... específicamente, para nuestros proyectiles, tenemos este patrón maestro que tiene todas las propiedades que queremos que tenga por defecto esta bala en particular: tiene daño, tiene un tiempo de vida, sonidos, efectos... Así que tenemos un montón de balas con las mismas propiedades, pero no tenemos por qué copiar los datos una y otra vez: a Ash se le ocurrió el sistema de variantes. Con este puedes hacer botón derecho en una variante, copias el patrón maestro y cambias cosas aquí y allá.
Pero esto es tedioso para los diseñadores que aman el EXCEL, así que puedo importar ciertas propiedades al patrón maestro desde la página de EXCEL. Y puedo crear nuevas propiedades o quitarlas.
Pero la belleza de este sistema es que un artista no tiene porque usar EXCEL, puede ir directamente a Dataforge y añadir partículas y efectos para esa variante en particular. Es un poco lo mejor de ambos mundos.
También es bueno que si un diseñador decide que algo ha dejado de existir, como este proyectil, los artistas se enteran automáticamente y dejan de trabajar en eso. También aseguramos el archivo para que sólo una persona pueda modificarlo al mismo tiempo.

Jared Huckaby: Tenemos aquí una lista de cosas como velocidad física, daño físico... Estos no son valores finales. Fue configurado así para la demostración, así que no os excitéis con lo que veáis en el programa.

Mark Abent: De hecho los autogeneré con un script antes de empezar a grabar esto. Tenemos que pasárselo a los diseñadores para que metan los valores reales.

Jared Huckaby: Veo que aparte de munición tenemos ahí niveles del juego, modos de juego...

Mark Abent: Tenemos propiedades para los niveles del juego y ciertas cosas. Si tenemos que añadir algo a un modo lo marcamos así, como que no puedas disparar en el modo de carreras.

Jared Huckaby: Dataforge no sólo es una herramienta elegante para crear XMLs, ¿almacenamos los datos de una manera distinta que en un XML, no?

Mark Abent: En la primera fase se introducen los Datos a partir de XML para salvar la información. Esto es sólo en el lado de los desarrolladores. Cuando llega a los jugadores se almacena en un blob (ndt: blob, no hay traducción perfecta así lo dejé igual) de datos binarios y lo que eso significa es que no tenemos que cargar un XML distinto cada vez que se dispara un proyectil, que aparece una nave... Si no que ya tenemos esa información en algún lugar de la memoria y cogemos la que nos hace falta. Es muy rápido.

Jared Huckaby: Estamos hablando de milisegundos, pero cuando hablas de cientos de miles de personas jugando a un juego... los milisegundos importan.

Mark Abent: Importan... tremendamente. Cuando tenemos docenas de personas (ahora puedo usar esa palabra) que tienen armas como una Gatling que puede disparar 900 balas por minuto vas a estar cargando un montón de XMLs y no queremos hacer eso: vamos a blob de datos binarios y cogemos la información que queremos.

Jared Huckaby: ¿Ahora mismo tenemos almacenadas esos blobs de datos binarios en un servidor?

Mark Abent: Ahora mismo están almacenados en nuestros servidores dedicados, pero en algún momento del futuro tendremos un servidor centralizado del que podrán tomar información los demás servidores. Con Dataforge tenemos la habilidad de "cambiarlo en caliente" o sobre la marcha, cambiando un blob de datos binarios por otro que hayamos modificado y los cambios se reflejarían al momento. Así podremos equilibrar cosas sobre la marcha en el futuro.

Jared Huckaby: ¿Es Blob Binario (Binary Blob) su nombre oficial?

Mark Abent: Es usado en todas partes internamente, así que supongo que así se bautizará. (risas)

Jared Huckaby: Los cambios hechos aquí se actualizarán al juego. ¿Podemos ver un ejemplo aquí de cómo actualizas un arma?

Mark Abent: Si, mira, es como si estuviese preparado de antemano. Mira, aquí bajamos la velocidad de 1180 m/s a 118 m/s y puedes ver cómo el proyectil va mucho más despacio. Que no os extrañe que "caiga", esta demo está en una caja con gravedad.

Jared Huckaby: Ralentizar algo está bien, pero ¿Puedes convertirlo en algo completamente distinto como una nave?

Mark Abent: Voy a quitarle el material, porque todos usan el mismo solenoide, y voy a poner una M50. ¡Y ahora estoy disparando M50s! (risas)

Jared Huckaby: Ponle un efecto de sonido, a ver como suena...

Mark Abent: Pew, pew, pew...(risas)

Jared Huckaby: Revierte eso a su estado normal antes de que me meta en problemas.

Mark Abent: (risas)

Jared Huckaby: Gracias por darnos este breve tour del Dataforge que ha estado más de un año en desarrollo. Es excitante poder almacenar todo en un mismo sitio, ahorrarnos todos esos milisegundos llamando a memoria esos XMLs y tenerlo en los servidores dedicados.

Mark Abent: De nada.

Jared Huckaby: En serio, arregla la nave...

Mark Abent: (risas)

CLASE DE DISEÑO DE NAVES ESPACIALES

Gurmukh terminó de explicar una clase de diseño de naves en 3D y han hecho cazas monoplaza. A Ben Lesnick le emociona que vivimos en un mundo en el que se enseñe a hacer naves espaciales con los estudiantes.



Gurmukh Bhasin: El propósito de la clase era intentar que la gente se sintiese cómoda explorando conceptos en 3D. Una de las cosas que hago en Star Citizen es diseñar naves en concepto 3D completo y quería compartir mi técnica con gente que estuviese interesada en esto para explorar ideas y conceptos en 3D.
El objetivo era hacer un caza monoplaza similar a la Gladius. Quería que fuese para Aegis porque es uno de los fabricantes más bonitos del juego y quería que fuese un caza monoplaza porque el curso es de 10 semanas y creo que todos los estudiantes no habían hecho un concepto en 3D anteriormente, era su primera vez usando 3D para muchos o creando algo así para ellos.
El objetivo es que se sintiesen cómodos diseñando una nave estilo Star Citizen en 3D a partir de la nada y creo que todos los que entregaron su proyecto hicieron un gran trabajo.



MVP
El de esta semana va a Ghost sobre su vídeo "What is Star Citizen: A full explanation". Es prácticamente imposible resumir Star Citizen en 18 minutos, pero hizo un gran trabajo.

SNEAK PEAK
Asientos de la Reliant.


9 1 respuesta
Akiramaster

Bienvenidos al infierno de las tarifas de datos.

Rigal01

Todavía estan haciendo arte conceptual de la caterpillar ? no van a cabar nunca.
Me mola mucho que estén con el diseño de los escudos, yo que no disfruto gran cosa pilotando quiero ver todas las mecánicas de cabina y multi crew cuanto antes.

Es gracioso que entras a ver el juego de steam de ese tio y todos son criticas de que es un scam y lo dejaron abandonado y vendido en varios DLCs

1 respuesta
FrostRaven

#19960 Es que van a hacer caso a los sueños húmedos de los fans y van a convertirla en un transporte de cazas, probablemente de Dragonflys. Y metiendo mecánicas nuevas con la nave. Cada nave es un copo de nieve especial, si no es de combate pura como la Sabre, y lleva su tiempo de concepto y diseño adicional.

La Caterpillar es una nave que se hizo en su día y moló lo bonita/fea que era y se guardó en un cajón, ahora tienen que hacer que tenga sentido, meter componentes internos físicamente dentro, ver cómo se navega por su interior y mil detalles que lleva hacer una nave de este juego. Además, tendrá la movida de que el módulo de mando de desacopla de la nave y eso va a ser un buen quebradero de cabeza a nivel de programación seguro XD

Rigal01

En mi opinión portar naves no es algo que le hiciese falta a la caterpillar. A más le tenía enamorado por el concepto dennave de asalto de emplearse y dividirse en dos, y también como bodega de carga para naves pirata. Lo de dividirse también lo hará la enevour así que supongo que tendrán algo pensado. Yo quiero múlti crew.

1 respuesta
FrostRaven

#19962 Es un módulo, así que no hay problema. Si le puedes poner un Módulo que lleva 2 Dragonfly dentro pues es como tener una P52 en una Constellation: es un añadido adicional. A esta nave que es superlenta le hace falta algo rápido para poder interceptar naves que sean más rápidas y un par de naves ultraligeras no le vendrían mal, aún le quedarían 4 módulos para llevar carga. Es la belleza de esta nave.

Sigo sin verle mucho uso a desacoplar el Módulo de Mando, excepto para escapar en plan Doctor Claw XD

1 respuesta
Rigal01

#19963 Si los contenedores valiesen mucho menos que el puente de mando y el puente de mando pudiese lanzar el contenedor como un proyectil y largarse, tendría sentido.

grafito

¿tu vida vale menos que la carga?
sin el soporte de vida (puente de mando) no eres mas que un filete de pescado congelado flotando entre estrellas. Y entonces creo que los contenedores pierden importancia.
:)

1 respuesta
Rigal01

#19965 No entiendo qué quieres decir.

1 respuesta
Galea

#19966 Te dice que tu vida siempre valdrá más que tu carga, que vaya, que el soporte vital y todo lo necesario para llegar a buen puerto sin morir en el intento está en la zona que se desacopla.

Cuando juguemos recuérdame que tu vida valga menos que mi carga xD

#19958 Gracias Frost.

1 1 respuesta
Rigal01

#19967 El contenedor de la caterpillar tiene motores, yo entiendo que es un ariete para abordajes, lo sueltas para que se estampe con otra nave. Dentro del contenedor de abordaje de la caterpillar hay vidas. No creo que el contenedor desplegable de la caterpillar esté ahí sólo para abandonar la carga y que dejen de seguir a la cabina.

2 respuestas
Galea

#19968 Que ganas le tienes a la 'Pillar, jodio

FrostRaven

#19968 La Caterpillar nunca fue diseñada para embestir a otras naves y tiene todavía menos sentido que lo pienses cuando la parte con la que embistes es modular y se te desmonta fácil en cuanto choque.

Además, por lo que dijo Randy Vazquez cuando trabajaba de Diseñador Técnico cada uno de esos módulos centrales de la nave tiene su propio generador de energía, su propio soporte vital y sus propios impulsores, por lo que pueden sobrevivir por separado. La zona central donde están los motores tiene más soporte vital y generadores y hay también redundancia en el Modulo de Mando. Es por todo esto que me parece complicado que la nave sea tan "barata" viendo todo el hardware que le quieren meter al final, es un chollo comparando con naves del mismo rango de precios.

1 respuesta
Rigal01

#19970 pero si tiene forma de ariete. Si no por qué una nave de carga solo tiene torretas defensivas delante ?

Sólo venis aquí a romperme las ilusiones restregándome la realidad. T_T

2 respuestas
FrostRaven

#19971 Tiene una torreta delante dorsal, una torreta trasera ventral, una torreta a babor que es de rayos tractores, el módulo de mando tiene una torreta dorsal trasera y cañones articulados frontales. Finalmente, la zona de ingeniería central puede que tenga misiles adicionales que se pueden instalar ahí en vez de otros componentes.

Resumiendo, 4 torretas con 2 cañones cada una (porque podrías sustituir el rayo tractor por un arma, tal y como esta diseñado), dos cañones articulados y posiblemente misiles. No me parece mala combinación de armamento, la verdad.

Rigal01

Es la mejor nave del mundo.

2 respuestas
FrostRaven

#19973 Claro, es la Overpillar :cool:

1
Galea

#19973 Ya veremos como acaba siendo la 'Pillar, ciertamente le tengo muchas, muchísimas ganas de ver cómo va evolucionando; a todo esto, ¿Cómo veis la Redeemer?

1 respuesta
Rigal01

#19975 Fea de cojones, incomoda de moverse con las escaleras en espiral. Yo la nave solo la veo si al final meten vuelo de superficie para hacer de apoyo al Mako como si fuese un Mi24.

1 respuesta
Galea

#19976 No hay escaleras en espiral y tu opinion ya la sé, ya lo hemos charlado xD

Rigal01

Drake es amor.

1 respuesta
NueveColas

#19978 Mira me cago en todo, ver una nave que roza la frontera entre un juego de naves y uno de hackeo escuchando el tema de el sótano de Picus me roza la fibra

Como me jode que no vaya a funcionar.

1 respuesta
Rigal01

#19979 Por qué no va a funcionar ? en el EVE Online tienen metida la mecanica dos veces.

Por un lado minijuego de hackeo como habilidad para la exploración. Aquí podría ser utilizado para abrir contenedores y cuadrar señales.

Por otro lado en el Eve tienen la guerra electronica que afecta a:
-La distancia que alcanzan los sensores
-La capacidad de targeteo de las naves
-La eficiencia de las torretas
-El alcance de las armas
-La regeneración de energía de la nave
-La capacidad de salto de las naves y la capacidad de usar afterburner

Simplemente copiando al EVE ya tienes un sistema de hackeo que puede funcionar tal cual en el Star Citizen. Sólo queda por definir los minijuegos para hackear.

1 1 respuesta