Reverse the Verse - Ed Suscriptores - Junio 2016

[Havok Specter]

Traducción por Frost en Ciudadano Estelar.


Jared Huckaby: ¿Podríais empezar diciéndonos qué es lo que hace el equipo de DevOps, porque hay mucha confusión?

Ahmed Sheiken (ndt: creo XD): El equipo de ingenieros de DevOps principalmente se dedica a ocuparse a las operaciones diarias que hacemos con el juego en la infraestructura de servidores y yo personalmente me ocupo de eso. Operaciones es un gran equipo, creo que los suscriptores conocen ya a algunos como Miles, Keegan, Andy, Jeffrey Peas... ese es el equipo de DevOps. Así que nosotros somos los que nos ocupamos de la Infraestructura de la Nube y de que vosotros podemos desarrollar y jugar en todo momento.

Jared Huckaby: ¿Dónde trabajabas antes?

Ahmed: este es mi primer trabajo en la industria de los videojuegos, antes trabajaba en la industria de las Webs. En el pasado trabajé en las webs de videojuegos; pero comencé en una empresa emergente de Egipto que se ocupaba del soporte web de otras compañías emergentes que tenían problemas haciendo todo el trabajo que tenían que hacer. Nuestro mayor segmento de mercado era de clientes que tenían mucho tráfico, así que necesitaban poder escalar en algunos momentos, y poder virtualizar sus plataformas en la Nube, de un proveedor de la Nube a otro, etc. Mi trasfondo está en la operación de la Nube y el escalado, así que cuando vi la oferta de trabajo de un juego de alta fidelidad de detalles en la Nube estuve interesado, especialmente por el estado continuo (statefullness, en contraposición a stateless, estado fluído) que tenía, algo que pensé que traería una locura de desafíos... y así fue, algo que nunca había visto antes.

Jared Huckaby: (Risas)

Ahmed: Y ya he estado aquí un año y tres meses.

Jared Huckaby: Luego ya comentaremos por qué tener un MMO en la Nube es interesante y un desafío. Jason, dinos qué haces para CIG.

Jason Eli: Esto a cargo de la arquitectura de los servicios del Backend, identificamos diariamente qué características necesitará el juego en el futuro en lo que respecta a servicios del backend. Cosas que la gente no suele ver lo que hacemos, por lo que en cierto sentido no nos aprecian mucho, pero cuando las cosas van mal somos los primeros en enterarnos.

Jared Huckaby: ¿Nos podéis dar un ejemplo de lo que es un Servicio de Backend?

Jason: Es como un servicio, tenemos persistencia ahora por lo que básicamente es responsable de traer los objetos de los servidores del juego y ponerlos en la base de datos y ese tipo de cosas. También tenemos el GIM (General Instance Manager) que está a cargo de lanzar o cerrar instancias y administrar partidas.

Jared Huckaby: ¿Y eso es distinto al Netcode?

Jason: El Código de Red es algo más de la relación entre los clientes y los servidores del juego, como una sesión de Arena Commander o cuando estás volando en Crusader. Ese es código que controla la jugabilidad de reflejos, momento a momento. Los servicios de Backend es más Mando y Control.

Jared Huckaby: Tom, ¿Tú qué haces para CIG?

Tom Sawyer: Soy el Programador Senior de Servidores al servicio de Jason y me ocupo de trabajar también en el backend ocupándome de todos los servicios que tenemos allí, ocupándome de un montón de herramientas de Mando y Control, y me relaciono con los chicos de Control de Calidad y Live Ops para tener una idea de lo que está sucediendo en los servidores públicos y cosas así. Y siempre que hay un problema yo me conecto y hago cirujía en directo en los servidores. A veces lanzamos un nuevo parche y aparece un problema, por lo que tengo que asegurarme de que las cosas funcionan sobre la marcha.

Jason: Nosotros tres somos la primera línea de defensa y los bomberos si algo va mal, en realidad.

Jared Huckaby: Es muy común veros conectados en Skype a altas horas de la madrugada tras el lanzamiento de un parche.

(risas) Estamos haciendo cosas muy arriesgadas, pero el "espectáculo debe continuar" y los servidores tienen que estar online.

Jared Huckaby: Y... Jason, ¿Dónde trabajabas antes de estar en CIG?

Jason: Comencé trabajando en Origin con Ultima: Crusaders y luego comencé mi propia compañía Asylum Software que se dedicó a hacer sus propios pequeños MMOs como Elder Lands, una pequeña selección de juegos de estilo retro. Y así es como me metí en la construcción de masivos mundos online. También trabajé en Qualcomm como Ingeniero de Servidores construyendo aplicaciones de red de alto rendimiento.

Jared Huckaby: ¿Y tú, Tom? ¿Dónde estabas antes de llegar aquí?

Tom: Estuve con Sony Playstation durante una década, en San Diego, en el Grupo de Tecnología Online. Construímos librerías de código de red para estudios internos y externos, y para cuando me fui habíamos lanzado 160 juegos de Playstation usando ese entorno de red. Tengo que admitir que era un tipo más de FPS, por lo que ahora que estamos en un MMO hay toda una serie de otros problemas que resolver. Y ahí es donde está genial tener la experiencia de Jason con los MMOs y la Persistencia. La Itemización, para mi, es la cosa más técnicamente compleja de un MMO: administrar todos estos objetos que pueden ser comerciados entre jugadores, vendidos en la web, su sincronización, su envío por correo internamente...

Jason: Y esta es una bestia completamente diferente en lo que se refiere a la Itemización habitual de los MMOs, de hecho varios órdenes de magnitud más que otros MMOs.

Tom: De hecho el lanzamiento del parche 2.4 fue enorme y una enorme inversión de tiempo hacer la Itemización bien hecha con Persistencia, porque cuando se habla de esto hablamos por supuesto de Persistencia en función a la cuenta del jugador, con tus cosas y naves. E iremos creciendo con el tiempo y teniendo Persistencia de la instancia y Persistencia extendida a mundos enteros.

Jason: Si, habrá tantos datos de Persistencia en el futuro...; pero lo más importante es sacar ahora la Itemización para que los jugadores puedan conservar el equipo y configuración que hayan escogido.

Jared Huckaby: La Persistencia es esencial para todos los MMOs. Hablamos a menudo como si fuese algo importante para nosotros, pero es como los neumáticos de un coche en lo que respecta a un MMO: no puedes tener un MMO sin Persistencia. (risas) Una de las razones por la que esto es tan importante para nosotros y hablamos tanto de ello es porque ningún otro MMO está "fuera" a estas alturas del desarrollo, publicando una alpha antes de la creación de su base de datos persistente. Vemos muchos comentarios de la comunidad sobre por qué es tan importante la Persistencia.... es importante porque es un enorme hito en nuestro desarrollo. Siempre estuvo en nuestro calendario de cosas a hacer desde el principio, pero debido a que estamos haciendo este juego frente a los ojos de la gente os tenemos que permitir jugarlo a medida que lo construimos. (risas) Están experimentando este hito que todo MMO supera, pero lo han experimentado meses e incluso años después de que saliese. ¿Qué nos podéis contar sobre construir la Persistencia mientras el resto de la gente está sentada frente a vosotros observándoos?

Jason: Es algo necesario y puede que la gente no se de cuenta de su importancia, no es algo sexy desde un punto de vista de Relaciones Públicas porque se espera que esté ahí por defecto; pero lleva una enorme cantidad de trabajo y tuvimos que tener mucho cuidado sobre cómo la introducíamos en el juego y de ponerla en el momento adecuado, y hablamos con Diseño de hacerlo después de que la itemización hubiese sido bien martilleada. Todavía queda mucho inventario que debe ser diseñado e implementado antes de poner auténtica Persistencia, pero teníamos que asegurarnos que las posesiones y naves y cosas que habían obtenido estuviese ahí desde el principio. En este juego van a tener miles y miles de objetos comparando con los cientos que son más habituales en otros MMOs, por lo que tuvimos que aproximarnos a esto desde otro ángulo y hacer los datos de una manera en la que no nos metamos en situaciones en las que nos empantanemos con su manejo.

Tom: Claramente es una característica que requiere de todo el mundo trabajando en ella, porque no sólo tienes a los Programadores del Backend ocupándose de todos estos datos para potencialmente de 50.000 a 250.000 jugadores al mismo tiempo dentro de nuestro servicio de caché, pero necesitas a los tipos de Jugabilidad, los de IU para manipular visualmente dentro del juego los distintos objetos, hacer cambios y actualizarlos en la base de datos o sacarlos al universo persistente. También tenemos los niveles de negocio para poder manipular la base de datos de los objetos, porque si no los tuviésemos podríamos cargarnos los drivers de la base de datos con todas las transacciones que están teniendo lugar.

Jason: Si, tenemos que tener todos estos diferentes niveles porque un servidor de juego en particular puede tener de 20 a 30 jugadores y muchos objetos están cambiando y siendo enviados a la capa de caché. Esta capa de caché almacena estos datos cambiantes durante cierta cantidad de tiempo antes de sobre-escribir la base de datos de manera controlada; pero cuando tenemos más de 100 servidores de juego esto se vuelve más complicado. Tenemos que tener múltiples niveles de aceleración y de caché para poder tener control completo sobre el ritmo al que los datos entran en el sistema del backend y su base de datos para asegurarnos de que no la matamos.

Tom: Y también hay que tener las herramientas de mando y control para soportar a los chicos de Atención al Cliente y Control de Calidad y todas esas cosas. Para cada uno de los objetos que hay en el juego tenemos un historial de donde estuvo en cada momento, cuando fue comerciado de un jugador a otro, cuando fue vendido o comprado o borrado de la página web y sincronizado con el universo. Cosas como esas. Hay muchas herramientas de ese tipo.

Jared Huckaby: Ahmed, has hablado sobre construir un MMO en la Nube y cómo es eso diferente. Dinos qué es lo que hace que Star Citizen en la Nube sea algo tan único.

Ahmed: No quiero irme mucho atrás en el tiempo, pero cuando comenzó el Movimiento de la Nube la gente dijo "Esto no es para todo el mundo." No puedes poner tu anuncio simplemente en la Nube en una VN, porque entonces no importaría si lo tienes en un entorno o en la Nube. Cuando estás en una de las Nubes tienes que usar múltiples capas de abstracción que te proporciona la compañía de la Nube. La Nube te proporciona almacenamiento en la Nube y estos se pueden mover de un VN a otro, las VN se integran de distintas maneras, hay diferentes conceptos de firewalls, diferentes conceptos de VNs. Es stateless. Y todo esto se te ofrece como un servicio a ti, evitando que te ocupes de todo este tedioso trabajo que es técnicamente como inventarse la rueda. Pero aún así, estás confiando en recursos compartidos con otras personas y todo el que te proporcione un servicio público de este tipo te dirá que tienes que diseñar pensando en los fallos: espera que esto se caiga en cualquier momento, espera que esto suceda, espera que las cosas cambien... Y por lo tanto, en las páginas web procuramos la mayor parte del tiempo tener un estado salvado externamente para asegurarnos de que en el caso de que la cantidad finita de recursos se caiga esta pueda ser accedido de manera básica: este es el concepto básico de un sistema distribuído. Tener esto en la web es como ser un Ciudadano de primera clase en un país que habla tu propio idioma: todo el mundo hace esto.

Pero no podemos usar este libro de reglas que todo el mundo utiliza en el mundo de los videojuegos. Los juegos son completamente opuestos a esto, son statefull, muy state full. No quieres que se escojan al azar, quieres que sean una decisión tomada. Esperas que puedas dejar encendida la máquina 24 horas y se mantenga así jugando durante 24 horas. Y tampoco vas a tolerar tener un 404 en medio de una apasionante batalla épica en medio de una jugada maestra. Así que obtener este tipo de estabilidad en la nube no es sencillo, no es fácil, incluso con todas las ventajas que tiene la Nube, porque esta hace mucho por ti pero también me quita mucho control de mis manos. "Podría haber hecho esto de esta manera o de otra, o quizá podría haber replicado esta parte". No puedo: estoy usando las herramientas abstractas que me ha proporcionado el dueño de la Nube como cualquier otro cliente.

El desafío es que los juegos MMO son un alienígena en la Nube, mientras toda la tecnología web son Ciudadanos de Primera Clase. Nadie está haciendo lo que nosotros estamos haciendo, así que hemos estado observando muchas otras compañías viendo sus sistemas, adaptaciones a la Nube.. No mucha gente ha logrado hacer que el simulador ( es decir, el servidor del juego) funcionando eficientemente y bien. Ese es el desafío. Hay gente que ha tomado sus centros de datos y entornos y los han subido a la Nube en VMs (virtual machines)... y eso no es lo que estamos intentando hacer nosotros. Es un desafío... y poniéndome algo técnico...

Jared Huckaby: ¡Demasiado tarde! (risas)

Ahmed: (Risas) Pero si quieres utilizar una nueva herramienta en la Nube podrías hacerla en un lenguaje moderno y dependiendo de tu caso de utilización podrías encontrar ejemplos similares en cinco minutos, y te habrás ahorrado un montón de tiempo y moverse a partir de ahí. Pero usando C++ es muy diferente, algo muy distinto.

Jared Huckaby: Has hablado de desafíos. Tenemos unos planes en marcha para ocuparnos de estos desafíos, de algunos de ellos todavía no estamos preparados para revelar porque algunas de estas cosas se las queremos dejar a Chris Roberts cuando llegue el momento, pero a grandes rasgos y de una manera en que no nos meta en problemas, (risas) ¿Qué nos podéis decir sobre cómo os estáis enfrentando a esos desafíos?

Ahmed: Si. La manera en la que vemos esto es que queremos implementar lo que nosotros llamamos el EDDC (Event Driven Data Center, Centro de Datos Controlado por Eventos).

Cuantos más recursos fluidos puedo proporcionar los juegos pueden moverse o lanzarse en menos tiempo... esto es lo que llamamos en este sector de DevOps con palabras de marketing como "time to market" (tiempo hasta su venta), cuanto tiempo me llevaría escalar el servicio para ti, cómo de fácil me sería obtener los recursos que necesitas, cómo puedo reutilizar estos recursos... porque la Nube es principalmente computación de utilidades: pagas por lo que usas. Y esa es una manera completamente distinta de hacer las cosas a tener tu propio Centro de Datos, con cosas que tienes que utilizar a veces si y a veces no...

Así que volviendo al EDDC de manera que cada pieza de software que es utilizada durante un evento importante y que la infraestructura debería conocer correría finalmente a través una amplia cantidad de buses de información que tiene reactores reaccionando sobre ellos. Esa es la vista general de esto. Y podemos orquestar esto de la manera que queramos, porque la orquestación es la palabra clave, es lo que necesitas saber: tienes que tomar toda la lógica que Jason y Tom y los chicos de la jugabilidad están escribiendo y hacer que indique lo que necesita y que mi infra-estructura de servidores reaccione a ella, sea expandiéndose, sea contrayéndose, eliminando clusters que no le convienen etc.. Ese es el plan.

El tema es que pasar a eso no es tan sencillo como sentarse en una habitación, conseguir este increíble informe blanco sobre lo que necesitas y controlarlo todo. Es imposible. Inevitablemente crearás malos diseños. Así que tenemos que llegar a un MVP (Minimal Viable Product, Producto Viable Mínimo) y escalarlo para los jugadores, ponerlo en el juego y observarlo en acción. Es el mismo concepto que el que usan muchas compañías emergentes, estilo a lo que pensaba inicialmente Facebook, en las que tienes que moverte rápido y romper cosas y el mercado te ayudará a corregirlas. Eso es lo que está pasando en el comienzo de nuestra Persistencia. Si pusiésemos la Persistencia antes de ver el juego en si y de que estuviese en marcha, sólo estaríamos haciendo muros y luego moviéndonos en torno a ellos. Ahora mismo estamos en un estado más maduro y podemos empezar a comprender que este es el aspecto del juego: los diseñadores del juego tuvieron su tiempo para discutir algunas ideas, debatirlas durante un tiempo... La implementación siempre es más sencilla cuando tienes algo con la que probarla.

Jason: En una época no teníamos ni un diseñó de los datos del juegos: nadie sabía lo que debía persistir, por ejemplo. Tuvimos que hacer varias reuniones para saber qué es lo que iba a ser persistente para ver lo que íbamos a hacer.

Jared Huckaby: Recuerdo esas reuniones. (risas) "Supongo que los jugadores tienen esto y esto y eso está con Turbulent y debe quedarse allí y esto otro debe quedarse en el Universo."

Jason: Oh, si, hubo mucha transición entre naves y comunicación de esos datos. Eso todavía está evolucionando hoy en día.

Jared Huckaby: Completamente. Todavía hay sistemas del juego que tienen que ponerse en marcha y que deben integrarse en la Persistencia sobre la marcha. Quería hacer una última pregunta sobre la escala del juego y como la escala de Star Citizen es mucho mayor que la de otros juegos en los que trabajasteis en el pasado.

Jason: Podemos empezar por la Itemización. En un personaje de World of Wacraft puedes tener cientos de objetos en tu personaje y eso parece un montón de cosas y objetos que controlar sea almacenados en tu inventario o en tu banco o lo que sea. En Star Citizen... simplemente en las naves y cosas que compras en la web ahora ya estás dentro de los miles de objetos y predecimos que un sólo personaje de un jugador tendrá asociados a si mismo en torno a los 50.000 objetos. Ahh... esa es una escala a la que nunca tuve que enfrentarme en el pasado, pero es algo en lo que hemos pensado mucho y descubierto cómo es la mejor manera de hacer... y aún así va a tener que evolucionar porque en algún momento tendremos un millón de jugadores online al mismo tiempo y 50.000 objetos por personaje son un montón de datos que mover.

Tom: Antes de la llegada de la Persistencia nuestra arquitectura era muy similar a la de un FPS. Viniendo de Sony el cluster de servidores inicial de juego se parecía bastante a lo que teníamos allí, en los que teníamos 250.000 jugadores simultáneos en los simuladores. Sabemos cómo escalar horizontalmente, y qué hacer si pasamos de 250.000 a 1.000.000 de jugadores simultáneos etc Tomar estas principios de Sony y aplicándolos a CIG podemos alcanzar fácilmente esos mismos números, pero una vez que añades Persistencia entonces tenemos que volver a la mesa de diseño y ver dónde aparecerán los problemas, que servicios necesitan más iteraciones horizontalmente etc

Jason: Estamos escribiendo todos nuestros servidores en C++ sólo por el rendimiento que obtenemos con este lenguaje, y cualquiera de los servidores puede manejar una gran cantidad de jugadores y de datos pasando por ellos. Una de las maneras en las que vamos a escalar horizontalmente es que tenemos que considerar dos cosas: equilibrio de carga (load balancing) y disponibilidad (avaliability). Tenemos que asegurarnos de que si un servidor se cae hay otro listo para recoger el testigo: que el servicio siempre esté disponible pase lo que pase. Tendremos múltiples instancias del mismo servidores online al mismo tiempo y si uno se cae habrá otro disponible. El equilibrio de carga se ocupará de repartir la carga apropiadamente (ndt: aquí hay un corte del stream de 3 -4 segundos) a lo largo de múltiples instancias en diferentes servidores.

Tom: Claramente queremos seguir aquí la metodología de los Mega-Servidores, con una conexión única que te permite jugar con cualquier persona del mundo, en vez de fragmentar la base de jugadores en diferentes servidores en el que estás encerrado y sólo puedes interactuar con los que haya en ese servidor. Estamos intentando diseñar eso por adelantado teniendo en cuenta la arquitectura de los MegaServidores tanto para la Persistencia como para el match-making (emparejamiento de jugadores) dentro del Universo Persistente.

Jason: Y los sistemas del servidor en si, ahora mismo, ya tienen una localización dentro del sistema (jugadores y objetos). Ya estamos creándolos como una localización dentro del universo y hay otros temas técnicos de los que ocuparse con los servidores con la interacción entre ellos para que los jugadores sientan que están juntos dentro del mismo gran y único universo. Ya hemos estado luchando esa batalla en el backend.

Jared Huckaby: ¿Qué es un Mega-Servidor? Estoy seguro de que esa es una de las palabras pegadizas de las que la comunidad querrá saber más...

Jason: Es un gigantesco mundo. Es esencialmente una colección de servidores y servicios trabajando juntos para crear la percepción de que son un único mundo y servidor.

Tom: En vez de ser como World of Warcraft, que tiene unoa lista de unos 250 servidores y una vez que te unes a uno de ellos estás atado a él.

Jason: Y este es un desafío muy interesante porque no sólo tenemos que ocuparnos de los jugadores estadounidenses, si no que tener en cuenta a la gente en Europa, Asia, Sudamérica...

Jared Huckaby: Y Australia. No dejéis a los australianos fuera de la lista, por favor, escribirán hilos sobre eso.

Jason: Y Australia, si. (risas) Es un Mega-Servidor Global. Tenemos que asegurarnos de que los jugadores se sienten allí y que pueden jugar con sus amigos Europeos o Americanos como si estuviesen en la casa de al lado, sin tener que transicionar a otro mundo.

(preguntas de los suscriptores)

Jared Huckaby: ¿Alguna vez habéis hecho que un error de un sólo carácter lo rompa todo?

Ahmed: (ndt: resumo porque...) Normalmente este tipo de cosas no suceden porque seguimos las normas de la industria al respecto y tenemos un servidor azul y uno verde de pruebas antes de hacer un lanzamiento, sea interno, PTU o público. Pero hubo una ocasión en que rompimos nuestras propias normas porque teníamos prisas y si, una vez sucedió algo así creo que durante el parche 2.2 porque había un espacio con la URL interna del sistema de parcheo y los de Control de Calidad estaban intentando entrar y no podían invitar a la gente. Y llevó un tiempo descubrirlo.

Jared Huckaby: ¿Utilizáis un framework común en el backend, como springs o struts?

Tom: Si lo recuerdo bien, los springs y struts son algo del framework de Java, pero nuestro cluster del universo está escrito principalmente en C++ con algunas librerías de terceros que personalizamos. La plataforma web si que utiliza muchas de esas tecnologías estilo web, si.

Jared Huckaby: ¿Qué herramientas de administración y configuración utilizáis para controlar los servidores que están en la Nube? ¿Qué herramientas de administración utilizáis para los análisis de registro?

Ahmed: No soy un fan de las marcas, pero tenemos que usar Chef, Graphene, StackDriver y también usamos toda una serie de herramientas hechas en casa para ocuparnos de esto; pero podemos poneros un gráfico que explicará mucho mejor que yo a lo que me dedico con la Nube. Nuestro sistema de versiones se está haciendo con un sistema que se llama BuildBot que es altamente unificado y personalizable para nuestras necesidades, y esto es lo que hace todos los bundles necesarios para crear nuestras versiones de los clientes o de los servidores o servicios u otros archivos. Lo demás puede ser observado en el gráfico:



(Ndt: describe lo que hay en este gráfico, así que en vez de escribir un montón de párrafos he preferido traducir/explicar lo que este "monstruo" ha soltado sobre el propio dibujo.)

Cada uno de estas cajas azules que he dibujo en el gráfico representa una VM (Máquina Virtual) y cada entorno de un juego de CIG en la Nube usa tres de ellas: uno para el Hub, otro para los Servicios y otro para el Servidor de Juego. Esto no es para nada el diseño final que tendrá, es lo que tenemos ahora mismo para que las cosas funcionen y ver cómo queremos escalar y cambiar las cosas las cosas. Ahora mismo estamos trabajando en otro lanzamiento para que sea más fácil escalar y que resista frente a altas cargas.

Jared Huckaby: ¿Cómo va el desarrollo de un parcheador que sólo descargue los incrementos o cambios en los archivos del juego?

Ahmed: Este proyecto funciona a base de mucha cafeína y uno de los mayores que tenemos entre manos, implicando gente de DevOps, IT, Motor Gráfico, etc para tener nuestro propio Bather y Launching System. Esto no sólo afectaría a nuestros jugadores si no que nos afectaría internamente con nuestras versiones internas. Así que si, veo todos los cambios en el log interno del proyecto, lo que entra y lo que sale, está sucediendo, de vez en cuando tenemos reuniones para asegurarnos de que todos los departamentos tienen claro las características necesarias para este lanzador. Va a ser fantástico.

De verdad que nos sentimos mal cuando lanzamos tres versiones del juego en un sólo día y no podéis probar más que la tercera porque la primera se os tardó tanto en descargar. Queremos daros esta descarga sencilla y rápida e incremental, como alguien de DevOps mi trabajo es daros el contenido tan bien y tan rápido como sea posible, así que tener batches más pequeños es algo esencial para todos nosotros.

Jared Huckaby: Este es uno de los problemas de tener un desarrollo abierto y jugable tan temprano: muchos de estos sistemas estarían hechos internamente antes de sacar la primera alpha. Igual que la Persistencia. ¿Mike Pickett es el que está trabajando en este aspecto?

Ahmed: Si, Mike fue uno de los primeros que habló de este problema, tuvo un diseño inicial sobre él... pero se extiende para su uso por un montón de gente así que estábamos mirando de hacer que este sistema fuese automatizado para todas las partes que deben usarlo. La escala es esencial en esto, tienes que hacerlo bien, porque sabemos cómo de grande es nuestra comunidad y los cimientos de esto debe funcionar bien, porque el lanzador debe ser tan exitoso como nuestro juego.

Jared Huckaby: Quería mencionarlo porque nunca me he encontrado ni hablado con Mike pero sabía que estaba trabajando en eso. Este es un juego enorme y sólo tenemos el equipo de Vídeo de la Comunidad en LA (ahora en Austin) y por lo tanto sólo podemos presentaros a unas selectas caras de vez en cuando, pero hay mucha gente trabajando en este juego duramente que nunca veis. Y Mike es uno de ellos, así que quería saludarlo.

Ahmed: Mike es cojonudo.

Jared Huckaby: ¿Cual es tu color de cable de red más odiado?

Ahmed: Si, en los viejos tiempos tenías que hacer tú el cableado y yo odiaba también algunos colores o decisiones, pero esa es la belleza de lo que tenemos hoy en día con la Nube: pides que haga algo y lo hace. Hace unos años pensaríamos que estabas de broma diciendo que una sola persona podría administrar 1500 núcleos. Hubo mucha conversación divertida cuando fuimos los dos a hablar con nuestro proveedor de la Nube (Google) porque eran fans de Star Citizen y fue increíble poder decir que no tenemos que ocuparnos nosotros de espacio de alquiler, racks y cables y que una-dos personas se ocupan de ellos.

Jared Huckaby: Una pregunta muy habitual que nos hacen es "¿Qué medidas vais a tener para impedir que los ejércitos de bots farmeadores estropeen la economía del juego?" Nos gustaría poder responderla y contar nuestros planes, pero el problema es que se enterarían los "chicos malos". Esta es una situación "Catch 22", cuanto más información esté fuera peor es para nosotros.

Tom: Jason tiene un montón de ases en la manga al respecto, por su experiencia.

Jason: Lo mejor que puedes hacer en estos casos es no responder a la pregunta pero dejarles claro que estamos vigilantes y eso les hará lo suficientemente paranoicos. ¡Os cogeremos!

Jared Huckaby: Hemos oído hablar mucho de las tasas de fotogramas del servidor y las tasas de fotogramas del cliente. ¿Podéis explicar cómo afecta la tasa del servidor a la del cliente?

Ahmed: No es mi área de trabajo en el proyecto; pero no creo que tengamos algo que "fije" la tasa del servidor a la del cliente.

Jason: La tasa de fotogramas del cliente es normalmente la velocidad a la que refrescas las imágenes por segundo. En el lado del servidor está la velocidad de la simulación, pero no tienen por qué estar relacionadas ni lo están.

Ahmed: Sé que los jugadores están preocupados por los FPS. Antes de decir nada, quiero agradecer a los Evocati y usuarios del PTU que han estado ayudándonos, conectándose o jugando cuando se lo pedimos donde necesitamos ayuda. Son increíbles. Cuando hace un par de meses pregunté cómo hacíamos las pruebas y me dijeron que eran con gente no me lo creía, pero me dijeron "ya verás, pídeles que prueben algo y en un minutos te lo estarán haciendo. Nuestros jugadores son geniales." Alucinante.

Así que... todo lo que intentamos hacer en el PTU es encontrar cosas que deben ser solucionadas y la optimización es la "madriguera del conejo" (ndt: esta es una referencia muy anglosajona respecto a "Alicia en el País de las Maravillas": meterse por la conejera y meterse en una aventura para ellos se refiere un poco a caminar en círculos, a perseguir una quimera o tener una experiencia psicodélica. Aquí claramente se refiere a que es una aventura larga que les hará perder el tiempo.), no hay que preocuparse por hacer mucha optimización prematuramente. Pero al mismo tiempo tenemos un producto que vosotros estáis probando, así que hay que hacerlo jugable y divertido si es posible. Así que lo que yo y mi equipo, y los chicos de Frankfurt y Reino Unido y en América sabemos que si pasamos algo de tiempo en un problema podemos aliviarlo pero no estamos ni de cerca a lo que queremos entregar, ¿así que por qué deberíamos perder el tiempo así? Tenemos tantas cosas que tenemos que hacer antes que sabemos que no es el momento apropiado de mejorarlo. Así que podemos mejorarlo un poquito, un 5% un 7% o un 11%, a veces, pero no va a durar mucho porque tenemos que modificarlo. Y a veces lo empeoramos porque queremos probar una nueva lógica y código para ver cómo de "caro" es su rendimiento... así que muchas gracias a vosotros por probarlo, nos estáis ayudando un montón. Es increíble que hacéis en el PTU.

Tom: Si, la gente tiene en su radar cuales son las cosas que pesan más sobre el rendimiento de los servidores, pero tenemos que añadir tantas características al juego todavía que la optimización que estamos haciendo es claramente prematura. Una vez que comencemos a optimizar el código va a tener un aspecto muy distinto que lo que tiene ahora.

Jason: Y hay una amplia cantidad de cosas que podemos optimizar, desde el lado del cliente (cómo se renderizan las cosas, lo que se simula en el cliente...) y también tendrás la latencia de tu red, y en el backend hay que simular las físicas y el resto de cosas que suceden allí. Y también hay cosas externas, por que los servidores del juego confían en las respuestas de los propios servicios, por lo que es una amplia cantidad de optmizaciones posibles. Pero no queremos optimizar mucho ahora, pero cuando lo hacemos intentamos coger "los frutos más bajos" (ndt: las cosas más fáciles de optimizar en tiempo y recursos); pero como hay tantos distintos departamentos trabajando en sus distintas áreas tenemos que centrarnos en ellas más adelante.

Jared Huckaby: Hay pocas cosas más importantes que la adecuada prioridad de tareas en el desarrollo de un videojuego. Tenemos mucha gente, pero hay una cantidad finita de recursos y cosas en las que pueden trabajar a la vez, por lo que cuando sabes que algo es temporal y que está ahí mientras hacemos tiempo hasta implementar la siguiente cosa que sabes que vas a poner en un parche más adelante, no quieres pasar mucho tiempo optimizando algo que sabes que será temporal y vas a sustituir. Es una constante lucha.

¿La página web estará en los mismos servidores que en los que usa el backend del juego o accederán a la misma base de datos del backend?

Jason: El Backend de la web y los servicios del juego van a tener una relación muy cercana. Antes de que esto suceda siempre han estado por separado, nosotros con el juego y luego aparte la Plataforma (ndt: controlada por Turbulent), pero ahora nos estamos uniendo. Los servicios verán la web como un servicio más y como parte de su propio sistema, así que estamos llegando allí, nos estamos acercando... nos estamos casando.

(risas)

Tom: Estamos usando toda una serie de APIs que funciona para el internet, pero estamos cerrando el código ahora para tener canales dedicados para las comunicaciones bi-direccionales entre la plataforma y el backend.

Jason: Tendremos una serie de servicios de alta velocidad que servirán de mecanismos de comunicación con la plataforma y hemos estado trabajando para hacer que la arquitectura permite tener el mejor tiempo de respuesta posible. Ahora mismo cuando compras una nave en la plataforma web no hay ninguna manera de que esta nos diga que la tienes, por lo que nos conectamos, cogemos tu paquete que contiene todas las cosas que tienes y con él podemos crear todos los objetos dentro del juego y hacer que persistan. Pero con este nuevo sistema de alta velocidad para comunicarse, en el momento en que compres una nave esto hará que inmediatamente se nos notifique y aparezca la nave al momento en que tu conectes al juego.

Tom: Cuando se trata de estadísticas de la comunidad, logros y cosas de esas, muchos de esos se pueden implementar con una tecnología web, así que si tenemos una línea de comunicación podemos activarlos con sencillez.

Jason: Si, será capaz de llamar funciones a que actúen directamente como un servicio más, y la API que les hemos proporcionado les permitirá hacer cosas como pedirnos cualquier dato que deseen. Y nosotros podemos generar eventos hacia la web.

Jared Huckaby: Es una de las cosas que molan de trabajar con un socio como Turbulent.

Todos: Si, si, son fantásticos. (risas)

Tom: Es la primera vez en un proyecto en que la página web está terminada antes que el propio juego.

Jared Huckaby: (risas) Si.

Jason: Pensamos cómo resolver los problemas de una manera muy similar, así que somos muy compatibles entre nosotros.

Jared Huckaby: Si, mucha de la funcionalidad existe sólo en la web, como la posesión de naves y objetos, y ahora está bajando al juego. Es genial tener semejante conexión con un socio porque siempre que trabajas con un tercero no sabes qué tipo de compromiso tendrán contigo y esto pasa en cualquier proyecto, no sólo en los videojuegos. Nos sentimos continuamente afortunados por tener como compañeros a Turbulent. Benouit... te quiero. (risas)

¿Qué hiper-visor usais en la Nube y que tipo de sistema operativo principal usáis para hacer correr el juego?

Ahmed: En estos momentos en el grupo GCE, así que el hipervisor que usan es un motor personalizado KBM. No creo que el hipervisor que usemos utilice una forma abstracta de manejar las instrucciones de las CPUS distinta del entorno a las máquinas virtuales, por lo que no creo que tuviésemos problemas utilizando Sand, KBM o cualquier otra cosa. Eso no va a ser un problema.

(ndt: tuvieron un crash de PC de stream, así que regresan para despedirse).

Jared Huckaby: ¿Algo que queráis decir antes de iros?

Ahmed: Estamos muy agradecidos por el tiempo que invertís en ayudarnos en el PTU, tendremos un stress test a las 3 PM así que será genial ver si está en un estado sólido esta versión para entonces...yyy Os agradecimos mucho por que nos ayudéis tanto a probar las cosas.

Jason: Estamos contentos por estar aquí haciendo algo increíble para poder daros una gran experiencia de juego.

Jared Huckaby: ¿Algo que añadir, Tom?

Tom: Yo sólo espero que el PTU vaya bien para que pueda dormir bien esta noche.

(Risas)

Will: Empezamos en 3 minutos, chicos.

Jared Huckaby: Vale, pues a probar el 2.4.1 en el PTU. Gracias chicos por responder a nuestras preguntas.