Randy Vasquez, Productor de LA
Mark Abent, el Bugsmasher, Programador de Jugabilidad
1- ¿Alguna vez has tenido un bug cuyo arreglo se haya vuelto algo cíclico? Por ejemplo, arreglar un trozo de código y te das cuenta de que ya no funciona por lo que lo arreglas y de nuevo no funciona.
Mark Abent: Esto pasó recientemente. Para 2.4 teníamos movidas persistentes en que te acercabas a tu nave y si tenías un arma en ella podías seleccionarla y quitarla. Para poder verla e interactuar con ella tuvimos que usar nuestro sistema de interacción que fue desarrollado por completo para el Sistema de Objetos 2.0 y no para el sistema de objetos original. Así que tuvimos que hacer que el sistema de objetos original funcionase con este sistema de interacción, lo cual significó que tuvimos que instalar un nuevo componente de red, un nuevo componente de físicas, y finalmente el componente de interacción. El de red e interacción no tuvieron problemas, pero el de físicas dijo "no no no.. Tengo bugs para ti". Cuando finalmente lo instalé, Control de Calidad comenzó a encontrar bugs.
Randy Vasquez: Tuvimos una inundación de bugs de esto, "¡estamos cayéndonos a través de las cosas!". Las torretas no funcionaban.
Mark Abent: Si ponías un poster en la pared y le dabas un golpe caía al suelo...
Randy Vasquez: Era muy divertido... (risas)
Mark Abent: Había una cosa de las armas que re-cargaba la munición y podías empujarla dentro de la pared. (pone la mano en la frente) ¡Oh Dios mio, qué he hecho! (risas) Así que si, arreglas uno y aparecen un montón más. Los de Control de Calidad, especialmente Andrew, te llamará con una risa cínica y te dirá "he encontrado algo". Oh Dios...
Randy Vasquez: Es todavía peor cuando reabre el error y dice, "Por cierto.."
Mark Abent: No, no, te llama directamente por Skype para que escuches su carcajada. Es fantástico... (suspiro) Arreglas, se rompe, pasa todo el rato. Vuelves al tema y lo arreglas. Por suerte para eso tenemos Control de Calidad. Nuestro CC es maravilloso.
Randy Vasquez: Si.
2- Recuerdo una historia curiosa de cuando se implementaron las primeras físicas, en que las cosas no funcionaban correctamente y un desarrollador se pasó horas comprpbando una y otra vez lo que pasaba hasta que se lo dijo a Chris Roberts y este le explicó que "CryEngine estaba simulando todo como si estuviese bajo el agua". Probablemente no he contado bien esta historia, pero me gustaría saber más anécdotas sobre bugs que parecían dificilísimos a alguien que no conocía las curiosidades de cómo funciona el motor gráfico.
Randy Vasquez: Esto pasó antes de que me uniese a la compañía. ¿Qué pasó aquí?
Mark Abent: Oh, es una buena. Pasó hace dos años más o menos, antes incluso de lanzar Arena Commander. El programador de físicas John Pritchett voló desde Kansas aquí porque estábamos trabajando en sacar el AC. Todo estaba saliendo bastante bien y de repente nuestras naves empezaron a comportarse de manera rara. Volaban, pero de manera extraña y en la dirección equivocada y de repente de ibas deteniendo.
Randy Vasquez: ¿Como nuestros misiles a veces?
Mark Abent: ¡Peor! De hecho, nuestros misiles estaban también bajo el agua pero esa es otra historia (risas). Estamos intentando descubrir qué está pasando y Pritchett está debugueando, debugueando durante dos o tres días porque todos somos todavía nuevos trabajando con el motor (especialmente él) e intentamos descubrir qué está pasando. ¿Es el código del juego, son las físicas, son los impulsores? Es un sistema enorme. Y al final se acerca a nosotros y nos dice.... (aún recuerdo su cara) "Ya he descubierto lo que pasa. Nuestras naves están bajo el agua". Todo el mundo que estaba a su alrededor dice "¿nos puedes repetir eso?" (risas) "Nuestras naves están bajo el agua" Y lo que pasó es que CryEngine por defecto....
Randy Vasquez: Tiene agua por debajo del nivel del mapa.
Mark Abent: Todo por debajo de 0 en el eje Z (Vertical) está "bajo el agua". Cualquier entidad en una coordenada negativa era etiquetada con la propiedad "bajo el agua".
Randy Vasquez: (risas)
Mark Abent: Así que si volabas en positivo no pasaba nada, pero tan pronto como te metías en negativo estabas bajo el agua.
Randy Vasquez: Incluso aunque el plano es invisible porque no hay terreno.
Mark Abent: Nos deshicimos del terreno y del agua. Aunque estuvieses en el espacio seguías metiéndote bajo el agua. Era algo sencillo de solucionar. "¿De verdad? Oh Dios Mio" Y hemos tenido muchos bugs así.
Randy Vasquez: Si, puedo imaginarme la cara de John en plan "Por cierto... Esto es agua y todo está bajo ella". Mola.
Mark Abent: No sé cómo sabías esa historia, pero es una buena anécdota. (risas) Pasemos a nuestra siguiente pregunta.
3- Desarrollo abierto contra desarrollo cerrado. ¿Qué cosas buenas y cosas malas tienen?
Randy Vasquez: Hemos explicado ya esto, pero básicamente tienes configurados los equipos de desarrollo de manera distinta cuando estás en desarrollo o con el juego ya lanzado. Los jugadores no tienen oportunidad de ver lo que se hace cuando está en desarrollo y que aspecto tienes cuando estás con las puertas cerradas. Recuerdo que cuando trabajaba con otros estudios como Diseñador antes de lanzar nada en estado beta o alpha teníamos la oportunidad de trabajar en nuestra parte del juego y hacerla a la perfección. Control de Calidad no revisaba eso porque sabía que todavía estaba en desarrollo.
Ahora, como estamos en desarrollo abierto, siempre tenemos el juego "lanzado" y la gente puede ver todos y cada uno de los avances que se hacen y las características que llevamos adelante. Control de calidad es magnífico porque es nuestra última línea de defensa y además trabaja tanto en la versión pública, como en la interna... Están haciendo informes de bugs de TODO.
Mark Abent: E incluso hablan con la comunidad para averiguar lo que tienen ellos, consiguen sus opiniones e información y nos la dejan en nuestros escritorios en plan... (risas)
Randy Vasquez: Creo que para mi el Desarrollo abierto lleva un poco más de tiempo, creo que eso es el lado negativo; pero de nuevo tiene de bueno que recibimos opiniones muy tempranas sobre las cosas que hacemos. Sé que la modificación de puertos en 2.4 recibió muy buenas opiniones e ideas y cosas en las que no pensamos que nos hicieron decir "ohh, si.... Vale, no nos dimos cuenta de eso. Gracias." Porque en Control de Calidad creo que tenemos 30 personas...
Mark Abent: Creo que tenemos más, porque Reino Unido y Austin tienen un montón.
Randy Vasquez: Bueno, pero creo que está en torno a 30 y eso no es suficiente para todo lo que tenemos que hacer. Necesitamos que más gente pruebe las cosas, así que ese es el lado positivo del desarrollo abierto. En desarrollo cerrado no tenemos los números para probar las cosas y hacer pruebas de juego, especialmente no es fácil convencer a los desarrolladores para que se tomen algo de tiempo para jugar y probar las cosas. Lo hacemos de vez en cuando...
Mark Abent: Si, es cuando les preguntas "¿Estás haciendo pruebas del juego?" "Sólo 5 minutos". (risas)
Randy Vasquez: Así que esa es mi opinión de Abierto respecto a Cerrado. No tengo una preferencia en particular. Supongo que si estoy trabajando en una nueva característica tengo la preferencia de que sea cerrado (risas) pero si no estoy trabajando en algo así y estoy ayudando a apoyar otras cosas prefiero el Abierto.
4- Creo que Mark es tanto un aplastador de bugs como un programador de nuevas características. ¿Te asignan la solución de tus propios desarrollos? También he visto que la mayor parte de los bugs que solucionas son de código de programación, ¿Tiene CIG un sistema similar para aplastar los bugs de Diseño?
Randy Vasquez: Esto se resume en "tengo que hablar con los ingenieros" o "tengo que hablar con los diseñadores". Diseño es raro en cierto sentido porque son el pegamento de múltiples departamentos y todos los departamentos aquí en CIG trabajan cerca los unos de los otros. ¿Cuanto trabajas con Diseñadores? Al menos todos los días.
Mark Abent: Si.
Randy Vasquez: ¿Y cuanto trabajas con los artistas? Así que cada departamento es cíclico y trabajan los unos con los otros. El equipo de Contenido Técnico, Artistas Técnicos, Artistas Normales... cuando están haciendo geometría y no funciona correctamente en la tecnología tienen que hablar con los que hacen la tecnología.
Así que no creo que haya un sistema general para toda la compañía, si no que cada departamento tienen sus propios procesos a la hora de ocuparse de los bugs. Por ejemplo muchas de los bugs de naves los discutís tú y Kirk. Y tú y Sherman hablabais sobre problemas con las armas hace un semana.
Mark Abent: Probablemente.... No me acuerdo. Con el Sistema de Objetos 2.0 estamos cambiando un montón de los sistemas. Voy a Diseño y me dicen "Hey, así es como estamos pensando en implementar esto..." Por que ellos son los que van a hacer a base de fuerza bruta eso: aquí están los XMLs, aquí están los archivos, este es el flujo en el que estoy pensando, pégalo todo junto y "dime cual es tu opinión sobre ello." Y luego iré al "Malvado Mark", que es como llamamos a Mark McCall, (risas) que hará el recurso artístico, la animación, y los enlazará con los objetos. Por lo que Diseño tiene un área específica, Diseño Técnico tiene un área específica y voy a cada uno de ellos para asegurarme de que cuando hago cosas nuevas ambos puedan trabajar juntos.
Randy Vasquez: Si. Es una gran mezcla, todo el mundo tiene su propio proceso y necesidades y depende de qué es el bug y lo que necesitan para solucionarlo y con quien tienen que hablar.
5- ¿Alguna vez os ha pasado que arreglasteis un bug y os disteis cuenta de que el bug procedía de otra parte del código y tuvisteis que deshacer el otro "arreglo"?
Mark Abent: Si.
Randy Vasquez: Si. (risas)
Mark Abent: Creo que han un episodio en particular de Bugsmashers con precisamente esta situación, tendría que buscártelo.
Randy Vasquez: Creo que estoy en uno o dos de ellos, aunque sea como voz en off.
Mark Abent: Si, todo el rato. Un ejemplo sería que con el viejo sistema de objetos teníamos estas entidades y tienen propiedades de (coge una taza de cartón y un bolígrafo) una taza y cuando le golpeas reacciona con físicas de taza y para esta taza/objeto tenemos una ranura en la que encaja su geometría y físicas. Y podemos tener toda una serie de "ranuras/espacios", pero en general tenemos un espacio para cada objeto. Pero para poner en marcha este sistema de interacciones necesitamos físicas en distintas localizaciones y en este punto activa la energía o abre una puerta. Por lo que ahora tenemos una entidad con dos "espacios" y tenemos que fisicalizar ambos. Y debería ser tan simple como decir "negative 1" y que repasase cada espacio y los fiscalizase. Eso es algo que hicimos hace dos años para el sistema de vehículos y conectamos estos objetos a las naves, pero tan pronto como los desconectamos y los pones en el suelo no tienen físicas y era por ese cambio. Y estaba en plan "¿Qué demonios está pasando? ¡Esto funcionaba hace dos años!"
Randy Vasquez: Siempre es divertido cuando aparecen bugs como estos porque entonces estáis luchando contra viejo código. Una vez me acerqué a tu escritorio y tenías abiertos doce archivos y me dijiste "No sé dónde está..." (risas)
Mark Abent: Estaba rastreando el historial... pero al final no encontré lo que estaba provocando ese bug. Cuando era "negative 1" el código abortaba, cuando antes eso simplemente hacía que no estuviese nada allí. Estaba rastreando literalmente la historia del código para saber qué estaba pasando, porque este código estaba allí. Y descubrí que hace un año hubo una integración con una nueva versión del motor con código de 64 bits y durante ese proceso se quitó parte del código y nunca nos dimos cuenta de esto porque no necesitábamos hacer este tipo de cosas con los vehículos. Cada uno de los vehículos tenía un código completamente distinto por lo que no nos dimos cuenta de esto. Así que pusimos el viejo código y cuando dejamos los objetos en el suelo tienen de nuevo físicas. Es como si el historial me estuviese persiguiendo. (risas) "¡Arreglé esto hace años!"
Randy Vasquez: No te envidio para nada...
Mark Abent: (risas) Con suerte por Perforce puedes hacer scroll por la historia para ver cómo cambió el código y "ahí está". (risas) Le llamamos "El Historial de la Culpabilidad". (risas)
6- ¿Cuando se acerca un lanzamiento qué porcentaje de la compañía está dedicada a sacarlo (arreglando bugs, probando cosas y todo eso)? De manera similar ¿qué porcentaje de la compañía no se ve afectado por el ciclo de lanzamientos y sigue trabajando a su propio ritmo (como haciendo niveles de Escuadrón 42)?
Randy Vasquez: Esta no puedo responderla de manera genérica porque depende un poco de las circunstancias de cada lanzamiento. Para 2.4 estamos haciendo el Sistema de Objetos 2.0 aquí, Persistencia, Compras, rehaciendo cosas artísticas aquí y allá... Pero seguimos haciendo la Caterpillar, Personajes, y equipo para ellos que se suponía que iba a salir en este parche como un Jetpack. No todos están trabajando en la misma cosa pero todos están trabajando en el objetivo del lanzamiento, unos puntos principales mínimos que queremos poner en cada parche y esto lleva a la resolución de bugs y la administración de los mismos para asegurarse de saber qué apoyo necesita cada uno y avanzar a partir de allí.
Por ejemplo, tú estabas a veces trabajando en nuevas características como los Asientos y administración de controles con los nuevos ingenieros, enlaces de conexión, conductos y una corta lista de cosas... y el pobre Abent tiene que ser reasignado para ayudar un día en 2.4. Paul ha sido un auténtico loco, ha estado trabajando...
Mark Abent: Buff, un montón...
Randy Vasquez: Ha estado echando adelante las cosas de 2.4 y se ha centrado en eso para que su equipo se pueda centrar en las características. Es una bestia. La cantidad de cosas que sabe en general, sobre el motor y globalmente, es una locura. ¡En mi cerebro no pueden caber tantas cosas!
Mark Abent: Si, le pregunto algo y me dice... "Espera un momento" y veo como su cerebro se pone en marcha y tick tack ahí está la respuesta. (risas)
Randy Vasquez: Cada lanzamiento es completamente distinto. Las cosas que tenemos planeadas para 2.5 y a partir de ahí necesitará de recursos distintos y todos los distintos estudios que trabajan en esto interna y externamente están haciendo cosas distintas para cada lanzamiento.
Mark Abent: Puedo añadir que yo puedo estar trabajando en una pequeña selección de cosas dentro del Sistema de Objetos 2.0 y luego no puedo trabajar en la siguiente cosa porque estoy esperando a que Patrick o Chad terminen algo. Así que pongo mi código ahí para que sea revisado y luego voy junto a Paul y le digo que estoy bloqueado y si necesita ayuda con algo de 2.4 y cuando se desbloquea lo mio vuelvo a ello.
Randy Vasquez: Ahora mismo entre tu, Paul, Chad... sois los veteranos de los Ingenieros. Sois básicamente el equipo viejo y tenemos una nueva oleada de ingenieros que llegan y Humpfrey es un veterano del motor por lo que con suerte se convertirá en un Senior aquí.
Mark Abent: Es otro Paul (risas)
Randy Vasquez: Va a ser una locura teneros a vosotros dos juntos. (risas)
7- ¿Nos podéis hablar más sobre las herramientas que habéis desarrollado internamente, como un herramienta para equilibrar las naves y armas? Si no existe, ¿estáis planeando hacerla? ¿Cómo sería?
Randy Vasquez: John Pritchett está trabajando en algo que nos sirva para el Ajuste de la Gold, para que los diseñador puedan introducir cambios en plan tabla de datos para que puedan poner lo que quieren que haga la nave y el sistema extrapole todo para que funcione con el IFCS. Y que también las grandes naves como la Idris, Javelin... tengan esta herramienta.
Mark Abent: Eso es enorme, porque su sistema está basado en físicas por lo que tienes que tener físicas apropiadas con un montón de parámetros. Y el Diseñador está en plan "qué hace esto..." señalándola con el dedo
Randy Vasquez: Básicamente... (risas)
Mark Abent: Y es que John tiene todo en su cabeza.
Randy Vasquez: Lo sé. Me asusta. (Risas)
Mark Abent: Todas estas variables que él conoce y sabe lo que quiere por lo que está haciendo esta bonita herramienta para dentro del juego para que puedas decirle lo que quieres y genere los valores y parámetros apropiados.
Randy Vasquez: Me acuerdo de sentarme con John y decirle "explícame esto" y él me dice "Vale". Y me lo explica. Y yo con la boca abierta, ojos vidriosos...
Mark Abent: (risas)
Randy Vasquez: "¿Demasiado? (risitas)" (risas) Me encanta hablar con él, es divertido, "Oh Dios mio, todo el detalle que estás poniendo en esto es una locura." De hecho esta es la segunda semana que ha estado en Reino Unido trabajando en el Sistema de Ajuste para la Gold antes de salir ahí fuera a entrenar a Andrew Nicholson sobre cómo ajustar las cosas para que estén equilibradas. Ha sido bueno que haya ido allí y se haya sentado con los chicos para que se lo explique, porque ajustar una nave solía llevar una o dos semanas dependiendo de cómo de complicadas fuesen o si funcionaban los impulsores. Ahora lo hacen en unas pocas horas. Es una gran y destacable diferencia a la hora de equilibrar las naves.
Mark Abent: Eso también. Nos encontramos con diferentes problemas, pero como lo hemos hecho tantas veces ya sabemos cuales van a ser somos capaces de hacer estas herramientas para que los Diseñadores pueden hacer los arreglos con mayor rapidez. Lo está convirtiendo en una ciencia ya.
Randy Vasquez: Es muy bueno a la hora de sentarse con los Diseñadores para saber qué es exactamente lo que necesitan. Recuerdo que en la primera nave que trabajé me dijo "Vale, vamos a poner en vuelo esta nave" Yo en plan "Vale.." Y se puso a hablar de todos los algoritmos matemáticos intentando ajustar los impulsores y encontrando un equilibrio entre ellos y yo me quedé de piedra "Son tantas cosas... Oh Dios"
Mark Abent: Él hace muchas cosas que ayudan, como dibujos para mostrarlo visualmente.
Randy Vasquez: A veces te gustaría poder ponerle una pajilla (pajita) en la cabeza y sorberle el cerebro para chupar sus conocimientos. (risas)
Mark Abent: Y su campo se encuentra más dentro del motor debugueando cosas que cosas externas, pero tenemos herramientas de debugueado como Dataforge o la otra cosa que está haciendo Ariel.
Randy Vasquez: Dataforge es importantísima porque nos ayudó a limpiar muchas cosas que antes indexábamos a mano y ahora ya no haces el scripting a mano. Haces las cosas con una herramienta que te limpia el interfaz, te permite leer las cosas con mayor facilidad y puedes ver dónde están los problemas.
Mark Abent: ¡Se acabó editar XMLs a pelo! (Risas) Y Ariel está trabajando en el Editor de Puertos de Objetos que ayuda un montón, porque ves en tu pantalla dentro del juego el personaje, nave etc para poner o quitar cosas. Y puedes ver que algo no encaja ahí porque el tamaño está mal.
Randy Vasquez: El puso la previsualización de eso la semana pasada y ha sido muy bueno, porque Sean Tracy y Mark McCall y Link (el chico nuevo) están dándole sus opiniones para que esa herramienta mejore. Y todas las herramientas son fantásticas, porque nos ayudan a desarrollar más rápido, mejor...
Mark Abent: Y si no tienes herramientas puedes ser como Calyx y escribes tu propia GUI en Python para hacer equilibrado de Calor. Y si, él hizo eso.
Randy Vasquez: Si, si, lo hizo. "¡Estoy prototipando esto!"
Mark Abent: ....Vale...
Randy Vasquez: Al menos no está haciendo gráficos de flujo.
Mark Abent: ¡Lo hizo! (se lleva la mano a la cabeza)
Randy Vasquez: Lo hizo (risas).
Mark Abent: Hizo todo el sistema en Gráfico de Flujo (Flow Graph) y cuando descubrió cómo quería que fuese hizo la GUI para poder explicárselo mejor a los demás.
Randy Vasquez: Si, porque la mitad del tiempo el Flow Graph parece unos sphagettis.
Mark Abent: Si.
Randy Vasquez: Me acuerdo una vez que hizo el Flow Graph de cómo se podía interactuar con las cosas de la cabina y tú y Paul le preguntábais. "¿Y cómo funciona eso?". Se encogió de hombros y dijo "No sé... Funciona sin más" (risas)
Mark Abent: El consigue que sus prototipos funcionen genial, pero son prototipos (risas)
Randy Vasquez: Intenté hacer funcionar sus Grabby Hands en uno de mis niveles para el Cargamento y el Salvamento y no era capaz. "¡Calyx! ¡No entiendo esto!" (risas)
Mark Abent: No, no vas a conseguir hacer funcionar su prototipo. (risas)
8- ¿Cómo fue tu transición de Desarrollador a Productor? ¿Te gusta tu nuevo trabajo o echas de menos andar jugando con la Caterpillar?
Randy Vasquez: La transición continúa todavía. He sido productor 3 meses ya, no, 4 meses.
Mark Abent: Se siente como si fuesen años...
Randy Vasquez: (risas) Gracias.
Mark Abent: Temo cuando te acercas.
Randy Vasquez: "¡Vuelve al trabajo!"
Mark Abent: Y yo le digo que no, no hay una tarea en Jira.
Randy Vasquez: (dibuja Jira en un papel y se lo enseña) "Hay una tarea en Jira, caballero"
Mark Abent: Tenías que hacer eso... ¡Lo hace todo el rato!
Randy Vasquez: (risas)
Mark Abent: Viene y me dice que hay un bug que tengo que hacer. Y yo le digo que no hay un aviso en Jira y que no puedo hacerlo. Y me señala que ahora si que lo hay. "Tú..... de acuerdo...." (risas) E intento escaquearme diciendo... "¿Lo sabe mi Jefe de Departamento?"
Randy Vasquez: Randy levanta el papel donde ha escrito, "Lo sabe"
Mark Abent: Paul levanta el pulgar desde su mesa y yo en plan "suspiro, bien, lo haré..." (risas)
Randy Vasquez: Siempre hay este problema en desarrollo. Mi trasfondo está en el desarrollo y al transicionar a Producción sé los trucos que usan los desarrolladores diciendo que no pueden hacerlo si no está en Jira... "y yo me conozco esos trucos" (risas) "¡por que yo mismo los he usado!"
Mark Abent: ¡Nos has traicionado, eres un espía! (risas)
Randy Vasquez: Soy un espía bastante abierto, creo.
Mark Abent: Tus tácticas de espionaje necesitan ser mejoradas... (risas)
Randy Vasquez: (risas) Sigo en la transición, me gusta mi trabajo aunque odio con pasión hacer los calendarios. Hacer un calendario en este tipo de entorno es complétamente asíncrono, porque vosotros estáis trabajando en una cosa mientras otros trabajan en una muy distinta. En todos los desarrollos que trabajé antes que eran MMOs normales con zonas y las misiones que se podrían hacer allí y la progresión que habría allí, teníamos todo planeado desde nivel 0 al que fuese el nivel máximo. Era fácil mirar al calendario y hacer una previsión de lo que llevaría. Siempre he sido un desarrollador híbrido con producción porque usaba mucho Jira para controlar las características en las que yo estaba trabajando. Cuando estaba en 38 tenía un equipo de 9 personas y era su jefe, además de estar a cargo de las herramientas de las misiones y esto toca TODO lo que hay en el juego. También tenía el tema de las localizaciones y diálogos por lo que siempre he hecho Producción pero no era oficial. Sigue teniendo una lucha interna de desarrollador contra Producción, pero mola porque puedo ir a las reuniones como la de las Puertas, (¿te acuerdas? y cuando repasamos su lógica podía entenderlo porque he hecho esto antes y he sido Desarrollador una temporada. Pero el otro Productor se había perdido, "Sólo estamos hablando de Puertas..."
Mark Abent: Sean se puso en pie y dijo "Sólo se trata de hacer una Puerta" (risas)
Randy Vasquez: Puedo hablar de Lógica y dar ayuda para facilitar las cosas, saber lo que necesita el equipo de desarrollo. O os veo coger un encerado y me levanto en plan "¿Qué estáis haciendooooo?"
Mark Abent: Necesito hacer un calendario de mis cosas... (risas)
Randy Vasquez: (risas) Y te ayudé a hacerlo y a ponerlo en la lista de tareas para asegurarme de que la gente con la que necesitabas trabajar, como Patrick, estuviese sincronizada y con información sobre quien tiene que hacer cada cosa. Ellos no tienen, necesariamente, la misma visión de conjunto que tengo yo.
Mark Abent: Si, si necesito la ayuda de Kirk para hacer ciertas cosas para poner en marcha las cosas.,,
Randy Vasquez: Hay que dejar claro que un Productor nunca es el jefe de desarrollo: su trabajo es facilitar las cosas, quitar los bloqueos. La gente que está fuera de la industria cree que el productor es el jefe pero no es así. Siempre que queréis hacer una cosa Paul y tu preparo yo la reunión, aclaramos el objetivo y vosotros decid lo que necesitáis, apunto todo y lo organizo en tareas para que podáis hacer. Pero vosotros ya sabéis como hacerlas, yo sólo me aseguro de que vuestro trabajo sea visible para otros y que sepan lo que estáis haciendo.
Mark Abent: Y rastrear lo que estamos haciendo. "¿Qué están haciendo?" "No tengo ni idea..." (risas)
Randy Vasquez: Cosillas, trabajo...
Mark Abent: O estamos atascados.
Randy Vasquez: Tú sueles romper cosas.
Mark Abent: Tienes que romperlas para hacerlas.. (Risas)
9- ¿Con el tipo de cambios fundamentales que trae 2.4 hace el equipo Público algo especial en preparación del mismo o es básicamente el mismo al transicionar entre PTU y versión pública?
Randy Vasquez: No hay equipo Público. Básicamente todo el mundo es usado según sea necesario, en función al lanzamiento en si. La transición se hace todos los días entre los estudios americanos y los europeos y viceversa y los productores se ocupan de los principales puntos de contacto entre los distintos estudios, donde tenemos las reuniones de "lanzar-no lanzar" algo al PTU. A veces teníamos basura completa bugueada, pero simplemente queríamos probar ciertas cosas con software de tracking para que la gente del PTU nos ayude para situar las cosas y comenzar a probar cosas.
Mark Abent: E indicamos que se va a romper tal cosa, pero queremos que probéis esa otra cosa. (risas)
Randy Vasquez: A veces desactivamos cosas, como Arena Commander que está desactivado en el 2.4 porque queremos probar la compra y persistencia. No hay necesidad de introducir más bugs y crashes de los necesarios.
(ndt: Thomas Hennessy les dispara con una NerfGun un par de veces porque no paran de irse por la tangente. "Me has dado justo en el alma")
10- ¿Los informes de bugs que enviamos en el PTU sirven para algo? Nunca recibo un mail indicando que ha sido resuelto o nada similar.
Randy Vasquez: Si, si que sirven, tanto en el Council o en los foros o los informes de Crashes. Muchas gracias, no podríamos hacer nuestro trabajo sin vuestra ayuda.
Mark Abent: Hay bugs que no podríamos replicar. Todos vuestros informes son compilados en una enorme entrada de Jira explicando qué es lo que pasa y vuestras teorías de por qué pensáis que sucede. Gracias a eso hemos rastreado y eliminado montones de bugs.
Randy Vasquez: Control de Calidad es la que recibe esos informes, la verifica, añade pasos adicionales de reproducción, maneras para solucionarlo etc Un caso de esto fue por ejemplo el spawneo masivo de piratas que nos llevo 3-5 días aislar. Muchas gracias por ayudarnos a probar cosas, usar sistemas de informe y a hacer este juego realidad.
Mark Abent: Si no recibís un mensaje da igual, sabed que vuestra información está siendo usada para que nuestro equipo de Control de Calidad diminuto hace lo que puede por clasificarla e informarnos. Si no responden a todo el mundo es por eso, porque no tienen tiempo.
