(problemas de sonido, repiten lo que comentan en ATV 3.7).
Tyler Witkin (Community Manager): Sé que este es un momento muy ocupado en la compañía, y en especial para vosotros, tras 2.5, Gamescom, Citizencon a la vuelta de la esquina. Se invierte mucho trabajo y tiempo en hacer docenas de versiones para preparar estas cosas. ¿Podrías decirnos cómo se ven esas cosas desde un punto de vista interno, en DevOps?
Mike Johns (Director de DevOPs e IT): Todos los eventos comienzan por el Departamento de IT, preparando el equipo, probando el equipo, hacer que funcione tras instalarlo allí y así sucesivamente. Desde el punto de vista de DevOps tenemos que acelerar muy rápidamente hasta 2 o 3 meses antes de una presentación en directo de este tipo y la razón es la cantidad de cambios y características que son necesarias para mostrar los cambios en público. Esto significa que tenemos que aumentar la cantidad de versiones que producimos en el Sistema de Versiones para acelerar el desarrollo, se nos pide lanzar nuevas versiones más a menudo y esto requiere de mucha más actividad en el PTU antes de un evento. Lo que la gente puede que no se de cuenta es que hacemos una enorme cantidad de actividad dentro de la compañía, porque cada vez que un desarrollador quiere añadir un cambio y ver cómo afecta a la versión en sí y cómo interactúa con el resto de cosas y funciona, empujamos una nueva versión... y a veces sacamos 6,7 u 8 versiones al día, dependiendo del grupo y sus necesidades. Esa es una de las cosas que nos mantiene ocupados.
La otra cosa es que, no importa cuanto mejoremos nuestros sistemas e infraestructuras, a menudo nos encontramos al límite del hardware y la red que tenemos. A menudo los equipos de producción nos pide que hagamos algo que no hemos hecho antes y esto requiere que los chicos pongan un esfuerzo adicional porque una de las cosas que procuramos es cambiar y mejorar los sistemas sin pérdida de productividad, sin tiempo de mantenimiento. Para poder lograr eso no hay realmente un buen momento para desactivar un sistema porque tenemos gente trabajando en multiples franjas horarias, por lo que siempre acabas afectando a alguien. Trabajamos las 24 horas al día para estar a la altura de estos cambios y no impactar el calendario de desarrollo o publicación.
Como funcionamos 24/7 solíamos tener un calendario de las horas a las que teníamos que estar de guardia, pero ahora somos mucho más informales porque básicamente todo el mundo está de guardia, simplemente depende de quien es necesario para arreglar el problema. La mayor parte de los chicos no tienen problema con esta realidad. Algunos dejan conectado su ordenador conectado toda la noche, dejan su móvil con Skype abierto junto a su cama... así que nuestro tiempo de respuesta durante grandes eventos como Games o Citizencon es muy rápida.
Tyler Witkin: Tras trabajar en Control de Calidad puedo entender fácilmente eso. Muchas veces me pregunta la comunidad, ¿Cuando duerme el equipo de Control de Calidad? Nos ven en los foros, discord, cargando versiones... Siempre nos ven a todas horas, pero, sinceramente... desde nuestro punto de vista estamos haciendo preguntas similares a las vuestras a DevOps. Si, puede que trabajemos a horarios muy locos o flexibles por razones del negocio, pero a veces veo mensajes de nuestro Ingeniero de Redes Miles Lee que escribe algo por Skype a la 1, 3, 6 y 9 de la madrugada y no está realmente teniendo un descanso de calidad, pero no nos importa porque estamos realmente dedicados a esto.
Mike Johns: Si, es bastante raro, para ser sincero a menudo me acerco a alguien que sé que ha trabajado un montón de horas y le digo que se vaya a casa. Él no quiere hacerlo y le digo "tienes que irte a casa".
Tyler Witkin: ¿Has dicho Ahmed? (risas) ¡Ahmed, tienes que irte a casa! ¡Lárgate de aquí!
Mike Johns: Si, y el problema es que se van para casa, abren su portatil y siguen trabajando desde allí. (Risas) Creo que hay una relación con el orgullo que sentimos haciendo lo que hacemos y de sentirse bien con uno mismo cuando eres la persona que responde esa pregunta o lanza esa versión o soluciona un problema gordo. Piensa en ello: si la cagamos durante la creación de una versión y se detiene el momento de lo que hacemos hay un efecto en onda sobre la gente que está trabajando en eso. La productividad de DevOps es exponencial, crece realmente rápido, y nos gusta trabajar en ello.
Tyler Witkin: () Todos aquí en Austin apreciamos lo que hacéis.
¿Cuanta gente tiene el equipo de DevOps?
Mike Johns: 9, contándome a mi.
Tyler Witkin: Es justo. ¿Hay alguien fuera de Austin o están todos concentrados aquí?
Mike Johns: Yo los veo como un gran equipo y sinceramente no importa donde estemos sentados. Si enviamos a alguien a otro estudio a dar algo de apoyo extra pues seguimos trabajando en equipo. Pero si, el grueso está en Austin porque aquí tenemos el centro de publicación de la compañía.
Tyler Witkin: Mucha gente no entiende la importancia de vuestro equipo, de cómo sin DevOps publicando versiones no podríamos asegurarnos de que la gente recibe las cosas en un tiempo razonable. Ayer mencionaste las reducciones de tiempo de los parches y Pickett mencionó en ATV hace un mes el Parcheo de Deltas. Mucha gente no se da cuenta de que todo esto nos afecta internamente también: copiamos parches y los parcheamos igual que externamente. Es para que la gente se de cuenta y piense que cuando a ellos les molesta descargarse casi el juego de nuevo en un parche... nosotros también queremos mejorar eso porque nos facilita las cosas y nos ayuda a hacer más rápido el juego y que sea más eficiente.
Mike Johns: Si. Movemos una enorme cantidad de datos. Internamente movemos más datos de los que queremos mover externamente, por supuesto, pero si, utilizamos la misma tecnología de entrega de datos internamente que la que usamos externamente y es así porque queremos tener consistencia en las pruebas. Queremos estar mirando lo mismo que estarán mirando los usuarios finales y si, hay un impacto.
Este proyecto del parcheador es ENORME para nosotros. Intentamos arreglarlo antes y creo que hicimos grandes avances. Pasamos de super-lento a super-rápido; pero todavía tenemos problemas con el tamaño de los parches y hay razones técnicas detrás de eso que mencioné ayer. Lo importante que la gente tiene que entender es que "nos comemos nuestra propia comida para perros" (risas)
Tyler Witkin: Es una analogía rara, pero la comprendo.
Mike Johns: Si. Hay un impacto. Y si te acuerdas, ayer viniste a mi oficina quejándote de que la velocidad de la red era lenta y yo te dije que estábamos subiendo tantos datos a través del sistema para Control de Calidad que estaba saturado. Y resultaba que tú estabas en la misma red que ellos y te cambiamos a otra.
Tyler Witkin: Si. La cambiaste. Pensé que estabais enfadados conmigo por alguna razón... (risas)... vamos a bajarle la velocidad a Tyler.
Mike Johns: (risas) No, no... Este cambio en el parcheador va a tener un enorme impacto. Lo tendrá para los usuarios finales (ndt: jugadores) pero también va a ayudarnos a nosotros, porque entregaremos versiones mucho más rápidamente y eso ayudará a todo.
Tyler Witkin: Si, va a ser genial, no sólo para los parches públicos si no para el entorno del PTU, que es una de las cosas con las que tenemos problemas porque sacamos una versión para probarla y ver cómo funciona a gran escala pero descubrimos que el tiempo de descarga y prueba es muy largo, la gente tiene máximos de descarga mensuales o bajas velocidades etc
Mike Johns: Si, y hay muchos pasos que hacer cuando se publica algo. Ahora mismo estamos hablando de sacar algo para que lo pruebe la gente internamente, pero cuando lo sacamos externamente hay muchas más listas de comprobaciones, verificaciones, dobles revisiones, triples revisiones en algunos casos... y es algo más tedioso, porque tenemos más cosas que hacer para que todo se alinee. No sólo son cosas de debugging internas, estamos hablando de datos reales de los jugadores cuando se pone ahí fuera, por lo que es un proceso más específico.
Tyler Witkin: Absolutamente. ¿Desde una perspectiva de DevOps cual es vuestro mayor desafío diario y cómo impacta otros departamentos?
Mike Johns: Esa es una pregunta dura, porque todo lo que hacemos podría ser considerado un desafío duro; pero creo que esto es lo que nos gusta hacer, tenemos suerte por hacer este trabajo, porque nos lo pasamos bien cuando sale un desafío. Puede que suene algo ñoño; pero es cierto. Los chicos son tan buenos en lo que hacen... No quiero repetir lo dicho, pero el tema del parcheador ha sido un gran problema para nosotros y no es porque sea técnicamente desafiante si no porque es un tema de orgullo. No es una de esas cosas de las que queremos oír todo el rato. Por supuesto la gente debe quejarse de esto y nos movemos todo lo rápido que podemos; pero para hacerlo bien (porque ya hicimos un intento y fracasamos) no queremos cometer ningún error y esto incluye muchos departamentos, porque a veces has dado un paso adelante más y tienes que esperar a que te alcance otro departamento y luego ellos están esperando por nosotros. Es otro desafío.
La razón por la que no consideramos el resto de cosas un desafío es que nos gusta dar respuesta a los problemas. Cuando llegó Gamescom doblamos e incluso triplicamos la cantidad de versiones y las pusimos todas en la misma ventana de trabajo debido a las zonas horarias. Eso fue un desafío, pero salió bien y luego era todo el rato "choca esos cinco" y "¿Cual es el siguiente?".
Tyler Witkin: Si. () Mucha gente en la comunidad no entiende lo que hay tras el lanzamiento de un parche. Los que se quedan por Discord ven que hacemos "Luz Amarilla", "Luz Verde" y luego una "Alta Luz Verde" (ndt: no entendí bien esta última luz XDD) para indicar las distintas fases en que nos encontramos a lo largo de un parcheo. ¿Qué aspecto tiene desde dentro lanzar un parche?
Mike Johns: Creo que lo explicaré de manera MUY general y sin dar una lista paso por paso porque si no... Típicamente creo que el proceso empieza cuando Control de Calidad nos da una luz verde interna () y esperamos a que el equipo de Producción nos de la luz verde. Una vez tengamos esto pasamos a hacer nuestras listas de comprobación y empezamos a pasar por los pasos para producirlo. Dependiendo de si es para Producción, PTU o Público cambia la cosa.
Si es PTU lo que hacemos es mover una copia de la versión a todos los servidores y hay unos truquillos que utilizamos para que suceda simultáneamente. Hay una serie de pasos porque tenemos que poner las bases de datos, hacer copias de reserva, movemos datos de un sitio a otro... También intentamos que haya 0 pérdida de tiempo en nuestros lanzamientos, por lo que subimos la nueva copia a servidores que nadie puede ver mientras los otros siguen usándose. De esta manera cuando llegamos al estado en que podemos comprobar nuestro trabajo Control de Calidad nos echa una mano y prueban un rango específico de IPs.
Tyler Witkin: Esto me trae recuerdos...
Mike Johns: (risas) Si. Una vez que recibimos la segunda Luz Verde "si, funciona", empezamos el proceso de parcheo para todo el mundo, Control de Calidad vuelve a probar que el sistema de parcheo funciona para asegurarse de que no pasa nada raro. Y esto es un ejemplo de que cuando tenemos un "bache" en nuestros procesos ponemos una comprobación adicional a partir de entonces: la interacción entre el Departamento de Control de Calidad e IT es REALMENTE importante. Por eso trabajamos los unos al lado de los otros físicamente, facilita las comunicaciones. Una vez que eso esté hecho Control de Calidad da su luz verde final, "vale, todo va bien". Luego Keegan le da a un botón y eso hace que TODO se vuelva público.
Tyler Witkin: Genial, es un proceso excitante. Siempre que puedo hablo de Control de Calidad, creo que nunca pierdes el lazo con ellos.
Mike Johns: Yo de hecho comencé a trabajar en Control de Calidad.
Tyler Witkin: ¡Mucha gente comienza en Control de Calidad! De hecho, esto lleva a la siguiente pregunta. ¿Qué habilidades son necesarias para trabajar en DevOps?
Mike Johns: Cambia de compañía a compañía, DevOps es un término general, pero cualquier compañía de Redes/IT/Web que te haya dado experiencia es buena; pero en nuestro caso buscamos gente con experiencia de ingeniería de redes y con mucha experiencia en el lado de LINUX, porque nuestros servidores funcionan sobre LINUX. Esta es una de las cosas que la gente no mira mucho cuando estudia esta área, cuanto trabajo necesitas hacer en LINUX. Si vas a publicar webs, bases de datos de webs, no tendrás que interactuar mucho al nivel LINUX. Como estamos en tiempos tan tempranos estamos haciendo cambios a estos servidores sobre la marcha para hacer más con el SO que tenemos. Y por eso pedimos esa experiencia.
Tyler Witkin: Esta pregunta ha salido mucho: ¿Por qué los de DevOps tienen todos barba?
Mike Johns: Oh, no sé quien comenzó esta tendencia... (risas) Te lo diré de esta manera: se ha establecido claramente que, a nivel global de la compañía, yo he ganado el concurso de bigotes. Así que me fijé que mucha gente estaba dejándose la barba, y por lo tanto decidí dejarme barba hasta que dejase claro quien manda. (risas) En realidad no sé por qué la gente se deja barba, pero para mi empezó con Gamescom... probé una barba cuando era joven...
Tyler Witkin: (Risas)
Mike Johns: ...¡trabajamos a todas horas y no me apetece afeitarme! Así que al final decidí dejarme la barba.
Tyler Witkin: Así que para cuando llegue Citizencon ya podrás hacerte unas cuantas trencitas...
Mike Johns: Quizá tendré aspecto de Gandalf o algo así para entonces.
Tyler Witkin: Muchas gracias por responder a nuestras preguntas, Mike. Quería ponerte en cámara hace tiempo y aunque estoy decepcionado de que ya no presumas de bigote, ha sido un placer tenerte ante las cámaras. Gracias de nuevo.
()
A continuación se une a nosotros Josh Coons, Artista 3D que estuvo trabajando en la Herald de Drake recientemente y previamente trabajó juntoa Chris Smith en la Constellation Andromeda.
¿Trabajasteis juntos en la Herald de Drake?
Josh Coons: No, es oficialmente la primera nave que hice yo en solitario, a excepción de algo de trabajo en tandem junto al desarrollo de la Caterpillar, que es de la misma compañía. Compartimos algunos recursos pero yo tuve control completo sobre la dirección artística de la nave. En la Connie Chris hizo el interior y yo el exterior, y colaboramos entre nosotros... esa nave fue gigantesca.
Tyler Witkin: () ¿En la Caterpillar tienen un ejército de artistas trabajando en ella?
Josh Coons: Si, la manejas como en cualquier otro videojuego a la hora de hacer un entorno, que se hace en equipo. Esa nave es tan grande que tienes que hacerla como un entorno con múltiples personas. Intento recordar cuanta gente trabajó en ella... Técnicamente yo hice algo de arte para ella, pero creo que hay 4-5 artistas trabajando en ella ahora mismo. Algunos hacen texturas, otros hacen kits, otros hacen nuevos kits con lo que se hizo en el pasado para montar la nave, bug fixing... y eso es sólo un departamento.
Tyler Witkin: Si, todas las manos están en cubierta. Diseño tiene que meterse... () ¿Para empezar, por qué no nos recuerdas en qué naves trabajaste tú antes?
Josh Coons: La última nave en la que trabajé con Smith fue la Khartu-al, de hecho, la nave de reconocimiento Xi'an. Querían que saliese bastante rápido y trabajamos en ella al mismo tiempo.. esa ha sido la nave que hemos hecho más rápido. Antes que esa hicimos la Connie que nos llevó un montón de tiempo. Antes de esa hice la Mutang Delta, la militar, pero no cuenta como mi primera nave en solitario porque me dieron la base ya hecha y no pude hacer todo... aún así fue muy divertido.
Tyler Witkin: Mucha gente ama esa nave.
Josh Coons: Si, mi hermano está decepcionado porque no pudo comprarla.
Tyler Witkin: ¿Por qué?
Josh Coons: Por que estuvo a la venta de manera limitada.
Tyler Witkin: Ah, claro. La Khartu-al fue una nave muy distinta en la que trabajar, ¿no? Tiene un estilo muy distinto a otras naves.
Josh Coons: Oh, si.
Tyler Witkin: ¿En qué sentido fue distinta la Drake Herald respecto a otras naves en las que trabajaste en el pasado? ()
Josh Coons: Fue la primera nave que pude hacer a mi ritmo. Tenemos unos hitos que alcanzar al hacer una nave: Whitebox (unas cajas que representan los volúmenes de la nave para que Diseño pueda repasarlos, detectar problemas evidentes y las métricas, y "plancharlos" antes de que se avance más en el modelado y sean enormes problemas de rediseño como una puerta que es pequeña y eso afecta en cascada a toda la nave), Greybox (modelado al detalle) y Lista para el vuelo. Yo lo veo como una barra de carga, 0%, 20%... y a veces retrocede, wimp, y es en plan. Ay..
Tyler Witkin: Creo que es lo mismo con todos los proyectos. Cuando pintamos la habitación del fondo verde la barra de carga iba bien hasta que nos dimos cuenta de que había pintura en la moqueta y tuvimos que retroceder.
Josh Coons: (risas)
Tyler Witkin: ¿Cómo te inspiras a la hora de crear un proyecto o nave? Cuando trabajas en una nave tan detallada e intrincada, ¿cómo haces para inspirarte en esas cosas?
Josh Coons: Normalmente miro cual es el espíritu que tiene esta nave y empiezo por la compañía, Drake. Desde que llegué a CIG tener unos perfiles bien claros para cada compañía me fue algo muy importante, porque puedes tomar de allí un montón de detalle, igual que hacen las marcas de coches como BMW, Volkswagen... Drake es industrial, muy esencial, con la estructura al aire. Así que me inspiré en equipo de construcción, miré muchas fotos y vídeos de pruebas de misiles con el motor a chorro dispuesto sobre una mesa con todas sus tripas metálicas al aire y haciendo pruebas. Use mucho de eso a la hora de hacer la Herald porque esta nave es básicamente un gran motor conectado a una cabina.
Tyler Witkin: Si, me encantan los cables expuestos del look de Drake. Es algo que atrae a mucha gente a ese fabricante.
Josh Coons: Si. Eso no estaba previamente allí y yo dije "nah, tenemos que hacer que esto tenga un aspecto mucho más esquelético".
Tyler Witkin: () ¿Cómo se implican otros departamentos en la creación de la nave? Imagino que hablan de Diseño, Efectos especiales...
Josh Coons: Se me suben a la chepa, no hay manera de quitármelos de encima, tío.
Tyler Witkin: (risas) ¿Os pasáis la nave entre vosotros constantemente durante la fase de modelado?
Josh Coons: Si, en todas las fases, especialmente hacia al final que es cuando los Productores se lo pasan bien porque es cuando empiezan a surgir todos los problemas. Es cuando dicen "¡eh, no había visto esto!" Y esa es la razón por la que tenemos Whitebox y Greybox, para eliminar esas situaciones, para que la culminación de la nave no sea tan "bomba atómica" para nosotros.
Tyler Witkin: Si, siempre se acaba cerrando el círculo sobre la palabra iteración. Imagino que muchas cosas que modelas tienen que encajar con Diseño y la funcionalidad de la nave.
Josh Coons: Me gusta enviar las cosas a Diseño y hablar con Diseño cuanto puedo, tanto como sea posible, porque incluso la cosa más pequeña puede ser un enorme problema al final y obligar a los artistas a rehacer un montón del trabajo. Si la cagas con una métrica... Por eso siempre estoy conectado con Diseño y asegurándome. Justo antes de venir a esta entrevista estábamos hablando sobre las métricas de los impulsores, asegurándome de que todos estábamos al día, efectos y esos detalles. Cuanta más comunicación tengas menos problemas tendrás.
Tyler Witkin: Esto totalmente de acuerdo (). ¿En qué tipo de nave prefieres trabajar? ¿Carreras? ¿Combate? ¿Profesión?
Josh Coons: Son un gran nerd de la Segunda Guerra Mundial, por lo que siempre que algo es militarizado...
Tyler Witkin: La Delta fue probablemente buena para ti.
Josh Coons: Si, fue un caso de "eh, haz esto rápido, toma la base y militarízala con el concepto".
Tyler Witkin: Salió realmente bien.
Josh Coons: A mi me gustó, me gustó realmente esa nave.
Tyler Witkin: ¿Es esa tu nave favorita hasta la fecha?
Josh Coons: No lo sé, me gustan muchas de esas naves. Es como tus hijos, los amas todos de maneras diferentes porque cada uno tiene sus características especiales y personalidad. Es lo mismo con tu arte.
Tyler Witkin: ¿Firmas tu trabajo de alguna manera, quizá dejando tu firma oculta en algún sitio?
Josh Coons: A veces.... quizás... tendrás que encontrarla. Cuando hago conceptos pongo mi firma porque es un hábito tradicional de la pintura. Este es un tema candente en la industria, sobre si deberías firmar o no tu arte. Sé que hay muchos artistas de texturas a los que les gusta poner sus iniciales en la página de la textura, de manera que está en el juego pero no es visible en los UVs. Si alguien extrae los archivos puede ver quien trabajó en cada cosa. Lo he visto antes.
Tyler Witkin: ¿Qué recursos artísticos son comunes entre la Herald y la Caterpillar?
Josh Coons: Todo tipo de cosas. Para hacer que el estilo sea el mismo intentamos reutilizar tantas cosas como sean posibles. Texturas... si la Caterpillar no las tiene las creo yo y si las crea otra persona las uso yo. La Herald reutilizó texturas enteras.
Tyler Witkin: Así que son un montón de pequeñas cosas aquí y allá.
Josh Coons: Si. Otro artista, Daniel (Kaminsky, probablemente), se volvió loco creando texturas nuevas y yo dije, "joder tío, estás son realmente buenas." Y ararhrahr (hace gesto con los brazos de acopiar cosas). Recuerda "el buen artista copia, pero los genios roban".
Tyler Witkin: No les digas eso...
Josh Coons: No, no, es una frase hecha... (ndt: Picasso XD).
Tyler Witkin: Ok, entonces vale. ¿Pusiste tus toques personajes en la Herald que no estaban específicamente indicados en el documento de diseño?
Josh Coons: Oh, si. ¿Te fijaste en todos esos enormes tubos que hay fuera de la nave? Eso es algo en lo que me arriesgué un montón porque no está en el concepto. Pero cuando CR lo vio dijo "Me gusta" y yo salí en plan "Gran éxito" (puño en alto). Rediseñé un montón los ángulos, la hice un poco más agresiva. Tenía un aspecto abotargado estilo garrapata... parecía una garrapata. (cara de asco) Y quería que tuviese el aspecto de una garrapata muy malota, una garrapata cabreada.
Tyler Witkin: (asiente)
Josh Coons: Así que hice los ángulos mucho más "dish dish dish" (hace ruídos de corte estilo Transformers).
Tyler Witkin: Eso es bueno, si, porque va con el estilo de Drake.
Josh Coons: Si.
Tyler Witkin: ¿Hacer naves de distintos tamaños crean desafíos distintos? ¿Cual es tu tamaño favorito de nave para trabajar?
Josh Coons: Si, es distinto según el tamaño, pero en general me gusta un poco de todo. Me gusta el trabajo en equipo trabajando con Smith, me encantó conversar con otro artista e intercambiar ideas e impresiones en equipo, fue muy divertido. Así que cuanto más grandes o cuanto más pequeñas son divertidas por razones distintas. Todo tiene su ventaja y su desventaja. Cuanto más pequeña sea antes la terminarás y te verás recompensado por tu trabajo más rápidamente, mientras que con las más grandes como la Connie... ese fue el recurso artístico en el que he trabajado más tiempo en toda mi vida, pero cuando estuvo terminada rememoré aquella época y me di cuenta de que me lo pasé muy bien trabajando en ella.
Tyler Witkin: Pero con las mejoras de la estructura, de la cadena de montaje y de las comprobaciones... todo va a ser cada vez más y más rápido.
Josh Coons: Oh, si, las variantes de la Connie van a salir en una décima parte de lo que llevó hacer la Andrómeda.
Tyler Witkin: Eso es divertido, porque la siguiente que preguntan es: ¿Cual es la siguiente nave en la que trabajarás?
Josh Coons: (Señala un poster detrás de él) Ahora tengo la Cutlass.
Tyler Witkin: El rediseño de la Cutlass.
Josh Coons: Haré que la Cutlass Black tenga un aspecto molón como hizo Smith con el nuevo Hornet. Y después de esa haré la variante de Carga de la Connie (Taurus), que tiene el espacio de carga ampliado.
Tyler Witkin: Y luego tienes la infame variante de la Connie que tiene un jacuzzi en su interior...
Josh Coons: La Phoenix, si.
Tyler Witkin: El tema del jacuzzi es muy divisivo en la comunidad, unos quieren que se quede y otros lo odian.
Josh Coons: Os haré felices a ambos grupos y os daré lo que queréis.
Tyler Witkin: ¿Podrías explicarnos eso un poco más o es pronto para ello?
Josh Coons: Un mecenas hizo un tour por el estudio y creo que era dueño de una Phoenix... y hablamos del Jacuzzi. Y hemos encontrado una solución para el Jacuzzi que gustará a todo el mundo, pero no quiero arruinaros la sorpresa.
Tyler Witkin: ¡No puedes dejarnos así!
Josh Coons: Bueno, pues no será como el jacuzzi de tu porche que no se puede mover de ahí. Si vas a la zona vivienda y le das a la mesa (replegable) te harás una idea de lo que pensamos hacer con él.
Tyler Witkin: Esa es una buena manera de terminar el programa. Muchas gracias por venir y responder nuestras preguntas. ()
