A ver, almas de cántaro, traducción completa:
-----------------------------------------------------
Dammit dammit dammit dammit.
Estamos trabajando en la actualización del ingeniero. Es una clase muy interesante en la que trabajar, ya que tiene una mayor influencia sobre el campo de batalla que el resto de clases. Esto significa que tenemos muchas opciones con las que trabajar, y el set de ideas resultantes es bastante impresionante (N. del T.:en el sentido de tener chorrocientasmil ideas posibles). Ya que hemos creado y probado varias cosas que NO han funcionado (sin ninguna falsa modestia, creo que hemos perfeccionado el arte de crear cosas rápidamente que no son divertidas), pensamos que sería interesante mostraros algunos de nuestros experimentos fallidos.
Nuestra primera idea era una nueva construcción, conocida internamente como el "Repair Node" (Nodo de reparaciones). Le dabamos a los ingenieros la posibilidad de cambiar uno de sus edificios por el nodo (Ambas partes de los teletransportes se consideraban un único edificio para este sistema).
Una vez construido, el nodo usaría energía que tendría almacenada para arreglar edificios cercanos que hubiesen sido dañados. Una vez agotada la energía, dejaría de reparar temporalmente para regenerarla hasta el máximo, creando una ventana de oportunidad para los atacantes. Si fuese sapeado por un spy, dejaría de reparar durante la duración del sapeo (N. del T.: No especifican, pero da la sensación de que el sap, a este edificio, no lo destruye, sino que solo lo deshabilita temporalmente).
El objetivo del nodo era resolver un problema de la experiencia de juego como ingeniero: siempre están atados a su base. Una vez construida y mejorada, el ingeniero tiene bien poco que hacer, aparte de esperar al típico espía que quiera sapearle, o esperar a que la línea de combate llegase a su base. La idea del nodo era la de permitir al ingeniero separarse temporalmente de la base, bien para recoger más metal, o bien para molestar al enemigo a escopetazos.
Normalmente, así es como tomamos nuestras decisiones de diseño de juegos: identificamos un problema, y discutimos cómo podríamos resolverlo. Nuestra experiencia nos dice que, aunque el ingeniero no esté bajo presión inmediata, no se puede alejar mucho de su base. Si un spy, soldado o demoman solitarios consiguen alcanzar la base abandonada, ésta tardará poco en hacerse añicos. Cuanto más se aleja el ingeniero, menos edificios podrá salvar de los sapeos. También notamos que al ingeniero le cuesta mucho trabajo el establecer nuevas bases que pueden ser muy fácilmente destruidas. Y así nació el nodo de reparaciones.
Las pruebas de juego con el nodo nos mostraron un resultado esperado, y 2 (parcialmente) no esperados. El esperado, es que las bases son mucho más dificiles de destruir, y el "turtling" (N. del T.: quedarte cubierto tras las bases del ingeniero, usándolas como el caparazón de una tortuga, a modo de barrera) se convertía en una estrategia muy efectiva. Por suerte, este tipo de problema se puede arreglar ajustandole las tuercas al diseño del aparato, y el nodo tenía muchas tuercas. Podíamos reducir la velocidad de reparación, reducir la capacidad de energía de reparación, aumentar el período de vulnerabilidad mientras recarga, etc etc. Probamos varias opciones. Un cambio que hicimos fue añadir rendimientos decrecientes, de tal forma que si ponías 2 nodos juntos, no funcionaban del todo perfectamente, y poner un tercero no daría ningún beneficio.
A pesar de las diferentes posibilidades de diseño a nuestra disposición, jamás conseguimos hacer que el nodo fuese visto como un edificio "balanceado" por el equipo atacante. Los mapas del TF2 suelen estar diseñados teniendo en cuenta posibles puntos estratégicos para la construcción de sentrys, así como su posible duración. Pero el nodo distorsionaba estos valores, tanto en viejos mapas favoritos, como en nuevos que pudiesen estar siendo testeados, ya que exageraba sobremanera los cuellos de botella que habían sido creados intencionalmente, pero además permitía la creación de nuevos donde antes no había.
El primer resultado inesperado del nodo fue la apreciación por parte del equipo de cuán valiosos son los dispensers y los teletransportes para muchos aspectos del ritmo de juego. Si el ingeniero no puede construir un dispenser, se pierde la capacidad de soporte de éste por completo. En la mayoría de partidas, los dispenser son ubicuos. No eres capaz de darte cuenta de lo que has perdido, hasta que lo has perdido. Cuantos menos dispensers, más lento es el ataque por varias razones: los equipos son más frágiles, el metal es más dificil de conseguir, y es más problemático el definir puntos donde poder reagruparse.
Un ingeniero que elige el nodo por encima del teletransporte hace a su equipo aún menos viable. El ritmo de los mapas se perdía completamente al no tener teletransportes disponibles. Los equipos no eran capaces de empujar (N. del T.: se sobreentiende que se refiere a empujar el frente) con la misma efectividad, y el frente se acercaba mucho más a los spawns. Esta falta de flexibilidad significa que el equipo atacante no es tán capaz de mantener el terreno ganado, y las partidas eran mucho más largas.
El segundo resultado inesperado era una consecuencia del primero. Los equipos percibían a los ingenieros que usaban los nodos como menos útiles, específicamente porque no construían o dispensers o teletransportes. Pensándolo bien, los datos viejos que ya teníamos a nuestra disposición deberían habernos permitido prever esto. Antes del lanzamiento del TF2, el medic disponía de armamento mucho más poderoso, lo cual provocaba que muchos jugadores de gran habilidad jugasen con el médico únicamente como clase de combate. Además de los problemas de balanceo, esto causó que a los medics ya no les interesase curar, lo cual no le sentaba muy bien a sus compañeros de equipo. Su idea era que el trabajo del médico era curar. Todo médico que no curase era tratado como un mal jugador de equipo -- la misma reacción que ante un ingeniero que no construye teletransportes o dispensers. Como en muchos ejercicios de diseño, no hemos aprendido que hacer, sino qué NO volver a hacer:
>Lección 1: El problema de que el ingeniero esté atado a su base aún persiste, pero el nodo ha resultado ser una solución demasiado forzada. En el futuro, si conseguimos resolver este problema, tendrá que ser de tal manera que no trastoque el balance existente entre equipo atacante y cuellos de botella de defensa.
>Lección 2: El dispenser y los teletransportes son muy buenos. Esto es algo que ya sabíamos, pero no nos percatábamos de cuán MUY MUY buenos son. Intentar animar a los ingenieros a no construirlos, o a construirlos de maneras extrañas solo provocó una rotura instantánea del ritmo de juego. Nuevos edificios en la actualización del ingeniero serán probablemente o bien mejoras, o bien nuevas opciones junto a los edificios viejos, en vez de reemplazarlos.
Puede que parezcan lecciones obvias, pero el saber con certeza el por qué una cierta idea no funciona, es normalmente tán valioso como una idea que sí funciona. Este proceso nos dejó bien claro el enorme valor del ingeniero, y cómo el alterar este valor lo más mínimo puede tener consecuencias catastróficas para el juego.
Al final, el nodo fue descartado porque hacía el juego muy repetitivo. Conseguía el objetivo de facilitar el mantenimiento de una base, pero no hacía el juego más divertido. Sí, el ingeniero ganaba algo de diversión, pero en cambio, como resultado, todas las demás clases sufrían.
--------------------------------------
Paso de traducir la chorrada del video del spy & pyro, que además aquí la mayoría de la gente ya lo conoce
ala, a pescar anchoas a la luna.
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
(tío, tq :**** )
![[Ooooo]](/images/smilies/nuevos/sorprendido_ani1.gif "Oooooo")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[nop]](/images/smilies/nuevos2/nop.gif "no")
