CCP Greyscale firma el que es, hasta la fecha, probablemente el cambio más grande en la historia del juego en lo que a gameplay se refiere. Y no es de extrañar que en tan solo unas pocas horas hayan corrido ríos de tinta como pocas veces se ha podido ver.
Bajo el título “LONG-DISTANCE TRAVEL CHANGES INBOUND” viene el primero de los cambios drásticos que tienen como objetivo terminar con el estancamiento que sufre 0.0 desde hace un tiempo. En este dev-blog se explica la primera oleada de cambios. CCP Greyscale ha estado desde la publicación del mismo respondiendo dudas en el hilo oficial del foro.
A continuación, la traducción (libre) del dev-blog.
Hola a todos,
Estamos a punto de hacer cambios significativos a los distintos modos de viajar grandes distancias que hay en EVE, con el objetivo fundamental de incrementar el tiempo mínimo de viaje entre dos puntos arbitrariamente lejanos, más concretamente relacionados con los movimientos basados en jump drives y en portales. La razón para esto es que la actual sencillez de movimiento ha hecho que New Eden haya menguado de tamaño en la práctica, en detrimento a la experiencia del juego.
¿Por qué esto y por qué ahora?
Nullsec está anquilosado y necesita cambios. Este es el primero de muchos pasos en nuestro plan.
Las grandes batallas molan, pero hacen que las más pequeñas sean menos frecuentes.
Estos cambios serán positivos para la gente que no está relacionada con la guerra de soberanía, por ejemplo haciendo el uso de capitales en lowsec menos arriesgado.
Esperamos que estos cambios van a tener un impacto aún por determinar, y como consecuencia serán impredecibles y tomará un tiempo desarrollarlos en Tranquility. Esto entra en nuestros planes a largo plazo, tal y como veréis ahora.
¿Cómo encaja esto en el plan para nullsec?
Tal y como se anunció en el fanfest, en nuestro reciente post en el foro y en el primero de los episodios del The o7 Show, un grupo de desarrollo de CCP está encargado de trabajar en nullsec y en los sistemas de juego asociados con la meta de ir pubñicando una serie de cambios que sacudan el status quo y mejoren el estado global de nullsec. Esperamos desplegar estos cambios en distintas etapas, cada una de las cuales proveerá mejoras específicas con el objetivo de que todas ayuden al objetivo global.
La primera fase contiene los cambios a los viajes de larga distancia, además de otros cambios asociados que vendrán en Phoebe en Noviembre. Estos cambio no serán una bala plateada que resuelva todos los problemas de nullsec de un solo disparo. Por el contrario, representan una mejora considerable en ciertas cosas que afectan a nullsec (Y lowsec) y además sientan las bases de cambios posteriores.
La segunda fase está enfocada en cambios a medio plazo en el modo en que las organizaciones capturan y consolidan espacio y estructuras en nullsec. Estamos trabajando con el CSM a medida que desarrollamos los planes para esta fase y elaboramos prototipos internos. Es durante esta fase en la que esperamos hacer un progreso mayor hacia entidades soberanas más pequeñas y diversas. Es muy pronto aún para entrar en gran detalle, pero en la actualidad nuestra idea conceptual está centrada en soberanía basada en la ocupación y más sistemas “libres” que descentralicen la sov para que dependa más en el control de piezas concretas de la infraestructura. A medida que continuamos esta investigación seguiremos trabajando muy cerca con el CSM y del feedback obtenido de los jugadores.
La tercera fase es la etapa que CCP Seagull explicó en la EVE Keynote del fanfest de este año. Esta etapa está pensada para ser construida sobre los cambios que planeamos a las starbases y estructuras además de a las corporaciones y alianzas en 2015, cambios que abrirán nuevas posibilidades para una guerra más dinámica y un control más granular del territorio. Esta fase además tiene la intención de liderar el futuro de nuestra visión hacia las stargates fabricadas por jugadores.
Dividiendo las tareas de mejorar nullsec en trozos más pequeños, nos aseguramos de que obtengáis los mejores cambios lo antes posible en vez de tener que guardarnos las actualizaciones. Estamos contentos de poderos traer los primeros cambios significantes más adelante en este año.
¿Qué va a cambiar?
Vamos a permitir que las naves capitales utilicen gates en lowsec/nullsec, e intentaremos que el viaje gate-a-gate lleve menos tiempo que viajar distancias de más de ~20ly por el método tradicional. Hemos hecho simulaciones de naves capitales viajando entre puntos arbitrariamente lejanos y decidido que la velocidad de movimiento no debe ser mayor a unos 3 minutos por cada año luz, sobre 20 años luz. Esto nos permite traer el principal cambio que vamos a ver: un uso menos sostendo del viaje mediante jump drive, mientras que preservamos su valor para movimientos más puntuales.
¿Cómo se consigue esto?
El principal cambio es la adición de una nueva mecánica llamada jump fatigue (fatiga de salto).
La fatiga de salto es monitorizada para cada personaje, persistiendo entre sesiones de juego y downtimes.
Cada vez que usas un jump drive, jump bridge o jump portal (todos son tratados como “un salto” aunque esto no incluye saltos a través de stargates) acumularás fatiga de salto. Si tu fatiga está por debajo de 1 antes de un salto, tu fatiga será 1 + años luz viajados tras el salto. Para saltos subsiguientes, la fatiga se multiplica por 1 + años luz viajados. Esto permanece en el personaje y decae a un ritmo de 0.1 por minuto.
Tras compeletar un salto y antes de que la fatiga de salto se incremente, obtienes un cooldown timer de salto. El tiempo de este timer es un número de minutos igual a tu fatiga de salto (antes de ser incrementada por el que acabas de dar), y no puedes volver a hacer otro hasta que este timer expire. Hay que tener en cuenta que dado que la fatiga decae a menor ritmo que el cooldown timer, tendrás fatiga por la longitud del viaje incluso después de que el coodown timer expire (Ver apéndice A para ejemplos).
El estado tanto de tu fatiga como del cooldown timer se verá mostrado en la barra de timers en la parte superior izquierda de la pantalla:
Además:
Cualquier nave con capacidad de salto va a ver su alcance reducido a 5 ly tras skills. Esto es necesario para no penalizar movimientos a corta distancia de un modo limpio y también reducir la distancia cubierta en saltos individuales. Nótese que el alcance del jump portal es siempre igual al de su alcance con jump drive.
Por este motivo, las naves capitales podrán utilizar stargates, pero de momento seguirán estando prohibidas en highsec (es un tema que nos gustaría tratar más adelante).
¿Qué más?
Solo podrás mover tu medical clone a la estación en la que estás dockeado en este momento. Esto previene atajos evidentes con el pod-jumping o suicide-cloning. (Si tu contracto de cloning es revocado por el propietario de la estación, seguiremos manteniendo el comportamiento actual en el que se mueve al sistema definido como Home en tu character sheet).
Los hitpoints y resistencias en las estructuras de soberanía serán revisitados, para balancear la habilidad de los supercarriers contra ellos. Permaneced atentos para un próximo post al respecto.
Se irán sacando otro conjunto de cambios más pequeños en Phoebe que serán del interés de muchas de las mismas personas que se ven afectados por estos cambios. Esto incluirá el rebalance de las armas de POS, un rebalance a los bombers y heavy interdictors, permitir el uso de doomsday en lowsec, y cambios a las mecánicas de las bubbles de los interdictors.
¿Qué no va a cambiar?
Los jump bridges que se anclan en POS tienen un alcance de 5ly por lo que no necesitan ajustes de alcance. De momento no vamos a tocar las skills aunque serán abordadas en un futuro próximo cuando veamos el alcance de estos primeros cambios.
Los Jump clones van a ser dejados aparte de momento. Queremos revisitarlos para hacer reajustes una vez los primeros cambios hayan tenido lugar y el uso de stocks de naves quede más claro y demás, pero que sirvan para un gran abanico de posibilidades (movimiento null-null, null-high, cambio de implantes, etc) pero no queremos hacer muchos cambios drásticos tan rápido.
¿Qué se considera especial de todo esto?
Los Jump Freighter y Rorqual ganarán un role bonus: 90% de reducción al rango efectivo de salto a todos los efectos de los cálculos anterioers, pero sin dejar de estar afectados por los mismos. Esto significa que, dentro de todos nuestros cálculos, cada vez que utilizamos este tipo de saltos primero se multiplica tood por 0.1. Queremos no obstante revisitar el papel logístico de estas naves en el futuro, pero de momento queremos traerlas al sistema sin nerfearlas demasiado.
Las Black Ops no verán su rango disminuido (N. del T: tienen 3.5ly de base, como los titanes). Esto mantiene el alcance de sus portales hasta ahora. No consideramos que esto requiera un cambio pronto.
¿Cuales son las consecuencias inmediatas?
A corto plazo, esperamos una reducción en el modo en el que cualquier batalla no demasiado importante en la que hay naves capitales pueda escalar, y en el número de participantes involucrados. Esto creemos que aumentará la frecuencia del uso de capitales en enfrentamientos a pequeña escala, tanto en low como en nullsec.
A medio plazo, vemos el potencial de cambios más importantes en el status quo de nullsec dado que varias de las partes contendientes trabajarán para ajustarse a nuevos objetivos: parece plausible pensar que la reducción general del rango hará que se tienda a vivir en zonas más pequeñas, pero no queremos hacer predicciones. Estamos seguros de que estos cambios mejorarán las capacidades globales del gameplay de lowsec y nullsec hacia direcciones mejores, pero cualquier grupo de cambios que nos permita predecir con precisión sus consecuencias implicaría que los cambios son demasiado simples para ser interesantes.
¿Y después?
Hemos estado participando acetivamente en el hilo de comentarios de este dev-blog y escuchando en todo internet. Estos cambios aparecerán en Singularity en las próximas semanas. Avisamos de que vendrán con Phoebe, la expansión de noviembre y que verán ciertos ajustes y adiciones en Rhea, en diciembre.
Las consecuencias a medio plazo de estos cambios tendrán un impacto considerable en los cambios a las soberanía que vendrán el año que viene, por lo que todo esto es susceptible de sufrir alteraciones.
– Greyscale, en representación del Nullsec Working Group (Scarpia, Fozzie, Ytterbium, Rise, Bettik, Delegate Zero, Masterplan y Nullarbor).
P.S: Como se ha mencionado anteriormente, CCP Greyscale ha estado obteniendo feedback y contestando en el hilo, por lo que conviene fijarse en las barras azules (N. del t: los tags de dev en el foro). Greyscale ha hecho un pequeño FAQ en la primera respuesta de dicho post:
– ¿Podrán las supers usar gates tras este cambio?
Greyscale: Sí.
– ¿Este cambio hace que sea muy difícil para los jugadores entrar a 0.0?
Greyscale: Probablemente sí. Miraremos esto a partir de mañana para intentar hacerlo más fácil.
– ¿Es el balance final a las black ops?
Greyscale: No. Por favor, ¡dadnos ideas!
– Las matemáticas acerca del jump timer mínimo son inconsistentes en el dev blog, ¿verdad?
Greyscale: sí, lo intentaré arreglar tan pronto como sea posible, ¡el hilo se mueve muy rápido!
– Valores de fatiga muy grandes pueden tomar un tiempo enorme en decaer, ¿no es demasiado?
Greyscale: probablemente sí, le echaremos un vistazo.
Apéndice A – Ejemplos
Little Bobby Tables está en su archon en UJY-HE en la parte superior de Deklein, justo tras el release de Oceanus. Quiere viajar hasta Atioth, en la parte baja de Geminate, que está a unos 50 años a vuelo de cuervo-espacial (N. del T: juego de palabras con a vuelo de pájaro, crow/cuervo). Consulta una página popular para planificar los saltos, lo cual da una ruta total de cautro saltos y 53 ly. Va en travel fit y tiene skills másximas por lo que su jump range es de 14.625 LY y espera estar limitado tan solo por los session change timers. El viaje le lleva dos minutos.
Un mes más tarde, está de vuelta en UJY-HE y Phoebe acaba de ser implantada. Su Archon ahora tiene 5 ly de alcance. Consulta su jump planner, y encuentra que ahora la ruta son 12 saltos y 54LY. No tiene fatiga de salto porque no ha saltado desde la release.
N del T: este es uno de los fallos del dev blog, toma como cálculo Jump Drive Calibration 0 para tener el menor rango de salto, pero solo son 12 saltos porque no se ha dado cuenta de que el salto base de un carrier son 6.5 ly y por tanto sale 12 en lugar de los 14 que deberían ser. No obstante, a efectos de didáctica sirve igual aunque recordad que en el apéndice se toman por error 6.5ly en vez de los 5ly correctos. Podéis ver que hay una diferencia notable entre los 5ly y 6.5ly.
Su primer salto son 4.85ly le lleva hasta U-TJ7Y. Dado que no tenía fatiga de salto, gana el mínimo cooldown timer: 1 minuto más 4.85 minutos por la distancia viajada, un total de 5.85 minutos, o lo que es lo mismo, 5 minutos y 51 segundos. Gana además una fatiga de salto de 5.85.
Espera justo los 6 minutos para el siguiente salto. En este plazo, su fatiga de salto ha decaído hasta 5.27. Hace su siguiente salto de 3.75 LY hsata LEK-N5. Obtiene un cooldown timer de 5 minutos y 16 segundos porque su fatiga eran 5.27 cuando saltó, y el timer mínimo habrían sido 4 minutos 34 segundos basados en la distancia recorrida. Así, ve su fatiga de salto incrementada. Ahora esta fatiga de 3.57 se multiplica por 4.57, saltando hasta 24.06.
Espera a que pase el timer, lo cual reduce su fatiga a 23.53. Tras esto, hace el tercer salto a RO0-AF, una distancia de 4.19 ly. Gana un cooldown timer de 23 minutos y 32 segundos y su fatiga se multiplica por 5.19, hasta 122.14.
Tras esperar 23.5 minutos en la estación, su fatiga decae hasta 119.79. Vuelve a saltar hasta 2R-CRW – 4.9 LY. En este punto el cooldown timer es de 2 horas 2 minutos y 8 segundos y su fatiga de 706.73. En este punto ha cubierto 17.51 ly y le faltan aún 37.04 ly para llegar. Mira el mapa y observa que la ruta de 40 saltos a través de nullsec para cubrir esa distancia y tomando en cuenta que se tardan 2 minutos por sistema más o menos, el viaje restante por gates toma menos de la mitad del tiempo de cooldown que le queda ahora. Decide volar directamente en lugar de intentar seguir saltando.
La semana siguiente intenta usar su Ark desde HED-GP hasta 373Z-7 en la parte más baja de Stain. Ha pasado el tiempo suficiente para que su fatiga haya decaído por lo que empieza de cero otra vez. Calcula la ruta y parte.
Su primer salto le lleva a 5-N2EY, 4.73ly. Dado que el jump freighter cuenta la distancia como el 10% de la real, tiene un timer dee 1.47 minutos, o lo que es lo mismo, 88 segundos. Su fatiga son 1.47, decayendo a 1.32 cuando el timer se acaba.
Salta de nuevo cuando el timer expira hasta 4NBN-9, a 4.88 ly. El timer serían 79 segundos, pero dado que es un salto más grande, su timer serían 1.488*60 = 89 segundos. Su fatiga se multiplica por 1.488, siendo 1.97 y decayendo hsata 1.82 en cuanto el timer acaba.
Así sigue hasta que alcanza 373Z-7, con un viaje total de 7.5 minutos y habiendo saltado 22.3LY.
Hasta aquí llega el texto del dev-blog. Podéis seguir la discusión tanto en el foro oficial como en reddit o en cualquier sitio relacionado con EVE dado que estos cambios son tan drásticos que se ha esparcido como el fuego.
En los próximos días publicaré un análisis personal algo más detallado del asunto. Por ahora es pronto para sacar conclusiones sobre consecuencias.
Fleet: Don't jump! 