WoW 2.0 - La paradoja del barco de Teseo en el desarrollo del motor de WoW

Comunidad General
1

A menudo me doy de bruces con comentarios de gente que pide un WoW 2.0 o que dicen que el motor gráfico del juego es muy antiguo. Sin embargo, lo que muchos no consideran es que World of Warcraft ya ha alcanzado la versión 11.0, tras múltiples expansiones, revisiones y mejoras continuas.

Esta constante evolución del juego ha sido un proceso meticuloso y extenso, con el objetivo de mantenerlo actualizado y atractivo para nosotros los jugadores. A través de la paradoja del barco de Teseo, se puede entender mejor cómo un software tan complejo y antiguo como el motor de World of Warcraft ha sido transformado repetidamente sin perder su esencia original y sin ser el mismo que en el año de lanzamiento.

Según la paradoja, si cada parte del barco de Teseo se reemplaza gradualmente, ¿sigue siendo el mismo barco? Del mismo modo, en el desarrollo de software, si se realizan revisiones y re-escrituras constantes del código, ¿sigue siendo el mismo software?

Desde su lanzamiento, el motor de World of Warcraft ha experimentado múltiples revisiones y re-escrituras para adaptarse a nuevas funcionalidades, mejoras de rendimiento y cambios en la tecnología. Este proceso es esencial para mantener el software actualizado y relevante. Sin embargo, hay un desafío significativo que surge con el tiempo: la antigüedad del código no solo afecta tanto a su rendimiento potencial, sino más al conocimiento y la comprensión del código por parte de los desarrolladores.

Cuando nuevos desarrolladores se incorporan al equipo, se enfrentan a un código que ha sido modificado y extendido durante años. Es improbable que lean y comprendan todo el código existente, ya que puede ser extenso y complejo. Esta falta de familiaridad con el código puede llevar a varios problemas:

  1. Desconocimiento de la Base del Código: Los desarrolladores nuevos pueden desconocer la lógica y las decisiones de diseño originales, lo que dificulta identificar dónde y cómo hacer cambios o mejoras. Cada módulo o función podría tener dependencias y particularidades que no son evidentes a primera vista.
  2. Incremento del Riesgo de Errores: Hacer cambios en un código desconocido aumenta el riesgo de introducir errores o afectar funcionalidades existentes. La falta de una comprensión completa del sistema puede llevar a decisiones de diseño subóptimas.
  3. Curva de Aprendizaje Pronunciada: Los nuevos desarrolladores deben invertir tiempo considerable en aprender el código existente, lo que puede retrasar el progreso del proyecto y disminuir la eficiencia del equipo.
  4. Pérdida de Conocimiento Histórico: Con el tiempo, los desarrolladores que participaron en la creación y evolución del código original pueden dejar la empresa, llevándose consigo el conocimiento histórico y contextual del sistema. Esta pérdida de conocimiento complica aún más el mantenimiento y la evolución del software.

A estos problemas son los que se refiere Blizzard cuando hablar de que su motor es muy antiguo. No tiene tanto que ver ni con rendimiento ni con capacidades, sino con comprensión del código de su equipo de desarrollo.

Este ciclo es perpetuo en proyectos con soporte a largo plazo. Cada vez que un desarrollador nuevo entra al equipo, se enfrenta a los mismos desafíos, independientemente de cuántas veces se haya revisado o reescrito el código. Por lo tanto, el problema no reside tanto en la antigüedad del código, sino en la continuidad del conocimiento del equipo de desarrollo.

Ese es el problema que afrenta Blizzard. Y poco o nada tiene que ver con el “motor va mal”.

Edito para corregir mi dislexia, gracias a Steinn :sweat_smile:

Un saludote ^_ ^

11 «Me gusta»
2

No quiero ser “ese tío”, pero es el barco de Teseo* xD
Aún así creo que es interesante, no se me había ocurrido que esa paradoja pudiera aplicar al desarrollo de software

3

Pero Anzoris, no pretendas que todos entiendan estas cosas por mucho que lo expliques de maravilla. Algunos o muchos vienen a un juego a jugar que para eso lo pagan, no para encontrarse un juego repleto de fallos y errores (que si que luego los corrigen, pero a medida que avanza la expansión y no en le ptr que es donde se deben de arreglar, es como si no jugasen a su propio juego).

Esta gente no está para pensar en este tipo de cosas. Como dije, ya suficiente hay en nuestras vidas tanto a nivel familiar, economico, trabajo, social como para tambien entender estas cosas de un videojuego.

Que repito, de 10 explicado. Pero no pretendas que todos entendamos tanto de un pasatiempo.

8 «Me gusta»
4

Gracias, la dislexia es fuerte en mi y esto me pasa por escribir de memorias. Y aunque no lo parezca, los dislexicos somos persianas y el que tiene poca se equipoca :sweat_smile: :rofl:

Un saludote ^_ ^

5

La cosa es documentar bien el proyecto justo para cuando entra gente nueva, he trabajado en varios proyectos y siempre ha sido obligatorio la documentación perfecta de lo que estas haciendo, precisamente para mitigar estos problemas, a nivel de notas en el codigo y en manuales de uso interno.

2 «Me gusta»
6

Veo que de verdad te gusto mi ejemplo y no lo dijiste por decir.

Realmente el mejor ejemplo lo tenemos en los Windows.

Porque cada X años se lanza uno nuevo y se deja el anterior?

Acaso no se podría actualizar el existe a las nuevas capacidades? Osease Windows 10 no se podría actualizar en si mismo para que hiciese lo de W11?

Si claro, pero empezaría a pasar lo que dices, con la tasa actual de cambios de personal en los equipos de desarrollo (de Blizzard, de Micro y las empresas grande) llevaría a lo que tu dices, que los nuevos tuviesen que aprender tanto “reformado” que es inviable.

Aun así, como dice Nhail, creo que intentar convencer a la gente que no tiene un mínimo de xp programando porque ni te van a entender, ni van querer hacerlo.

Eso ahora quizás se haga, antes, en Blizz, no.

Y los ejemplos los tenemos por ejemplo en que habian perdido el codigo fuente del wow vanilla y tubieron que adquirirlo de un server pirata…

O que perdieron el código original del StarCraft y si no llega a ser porque un pavo encontró en un mercadillo un Cd con el codigo de la edición gold (osea cuando acaba el desarrollo) y lo intento subastar online y blizz se lo “intercepto” con una nota de abogados, seguiría sin el.

1 «Me gusta»
7

Sobre la documentación, en un proyecto grande al final, sigue pasando lo mismo, es una cantidad ingente de documentos que requiere una gran inversión de tiempo para “leerlo todo” y al final se va buscando a medida que se va necesitando.

Y muchas veces, conseguir la visión entera de todo requiere bastante tiempo para el aprendizaje. Y esa es la cuestión.

Pues esto es lo que más pena me da, porque encima me escupen en la cara que no tengo ni idea de lo que hablo. Pero en fin, conque haya una persona que le despierte la curiosidad y quiera aprender un poco más, me doy por satisfecho.

Y si, me gustó mucho tu ejemplo, porque no lo había visto nunca aplicado al desarrollo y ya te dije que lo iba a usar :slight_smile:

Un abrazote ^_ ^

1 «Me gusta»
8

Juraría que no hay ningún mmo que se vea mejor q el wow.

Es decir, hay algunos con mejores gráficos, pero no se ven igual de bonitos.

Dejando de lado la optimización hacen un gran trabajo.

1 «Me gusta»
9

Me encanta tu teoría y explicación Anzoris

El problema aquí siempre será el mismo, comparar el WoW con cualquier triple A de la consola de turno.

Mientras el WoW no se vea como el Ragnarok o el Horizon FW la gente se seguira quejando

10

Hace tiempo leí que la documentación es como el sexo. Si es buena, es muy buena. Si es mala, es mejor que nada.

De todas formas, en todos los años que he trabajado como desarrollador, creo que puedo contar con los dedos de una mano los proyectos que me he encontrado bien documentados.

¿Y sabes qué? Pues que da lo mismo. Si te dan bastante tiempo, abres el código, coges un cuaderno (o lo que quieras usar) y empiezas a documentar. Nombres de ficheros, clases más importantes, información de entrada, de salida, modelo de datos, etc etc etc (y muchos etc más) Empiezas desde arriba, y vas aumentando el detalle.

El problema no está en el código, el problema está en el “si te dan tiempo”. Al menos por mi experiencia, es muy frecuente tener jefes de proyecto que no han tirado una línea de código en su vida, pero por algún motivo saben estimar plazos de entrega mejor que todos los desarrolladores del mundo juntos. Si te piden las cosas para ayer y encima no tienes documentación, ahí si la llevas clara.

En fin, no quiero irme por las ramas. Anzoris, muy interesante tu mensaje.

2 «Me gusta»
11

Quieres borrar a los jugadores que aun juegan con ordenadores patata de 10 años?, la idea es que actualicen sus equipos aprovechando las ofertas de las muchas paginas para comprarte un ordenador, pero la vida no es asi, y estas personas tendrán acceso al juego mientras la división Activision Blizard de Microsoft lo decida, esto no es como el nuevo call of duty que necesita buenos requisitos para funcionar.

12

¿Quién quiere qué?

Me encanta esa frase. Al final el problema de la documentación es que puede llegar a ser enorme. En proyectos europeos en los que he trabajado, con varios equipos, al final se terminan generando miles de páginas de documentación, de actas de reuniones, de aspectos de diseño… que son inabordables.

Al final el código es como una biblioteca enorme, donde además todos los libros son libros de “Vive tu propia aventura” que te mandan a otros libros distintos.

Y como dice Yugos, al final si quieres dominar la biblioteca te toca “deambular” por ella, pero claro, deambular no produce beneficios y por eso este tipo de proyecto a largo plazo suelen ser tan complicados en proyectos de código privativo, pero en cambio en proyectos de software libre se hacen mucho más asumibles. Sencillamente porque puedes dedicar el tiempo que quieras a vagar por la biblioteca y entenderla.

Un saludote ^_ ^

1 «Me gusta»
13

Nadie pide eso. De hecho, en un futurible WoW 2 preferiría que mantengan los gráficos cartoon de WoW pero corriendo en un motor que aproveche el multi hilo y sea lo suficientemente potente como para gestionar grandes cantidades de jugadores. Eso, y unos servidores decentes en paralelo y para mí es suficiente.

14

Lotthar, pero es que no se puede añadir más cores al procesamiento, no es como pulsar un botón y a la, a usar 16 cores. La Ley de Amdalh nos marca el límite teórico de la parelización cuando existen lógicas que son inherentemente series y/o tienen dependencias. Y en el caso del WoW el núcleo principal del juego (al igual que en muchos juegos) es totalmente lineal.

Además, incrementar el número de cores, genera un overhead de sincronización y problemas de consistencia en la caché. Si tienes n cores, para sincronizarlos se requieren n(n-1)/2 comunicaciones, es decir, un crecimiento exponencial. Esto quiere decir, que si:

Cores Número de comunicaciones de sincronización
2 1
4 6
6 15
8 28
12 66

Por eso no se puede solamente “dividir el trabajo en más partes”. Como se suele decir, 9 mujeres no engendran un bebé en 1 mes.

Ahora mismo WoW usa 4 núcleos de procesamiento. Pero solo uno para el procesamiento principal de la lógica del juego es decir, el estado del mundo de tu personaje. Cuantas más cosas pasan en el mundo, más cosas tiene que encargarse ese núcleo. Y dado que existe una secuencia y esta es importante, no puede particionarse ese trabajo. Ya que sincronizar ese trabajo secuencial requiere más esfuerzo que sencillamente hacerlo secuencial.

Sobre la cantidad de jugadores, aquí es donde entran en problema cuando se tienen muchos muchos núcleos de procesamiento pero individualmente se tiene un número de operaciones por segundo muy bajo como para poder mantener el ritmo.

Y esto no es problema de motor, ni nada por el estilo. Es una limitación natural del software y las comunicaciones de red. Es como quejarte que en una mesa de madera natural las betas no tienen todas el mismo dibujo.

Por eso, cada vez que alguien anuncia un juego con “muchísimos jugadores simultáneos”, la mayoría al final se termina limitando entre 64-128, porque existe ese máximo teórico, y si, existen experimentos que permiten elevar el número, pero son eso, experimentos y casi siempre usan “trampas” como crear cluster de jugadores/escenarios pero que terminan funcionan regular y generan desincronías. Por eso pensar que WoW pueda gestionar grandes cantidades es pedir algo que actualmente la tecnología, para el tipo de juego que es WoW, pues no puede hacerse. O si lo haces, tienes que ralentizar la acción.

Que por ejemplo, eso es lo que hace el Final Fantasy, usando un GCD de 2.5 segundos, frente al 1.5 segundo que utiliza WoW. Por eso jugar al FF se siente más “lento”. Porque estás dando un 66% más de tiempo entre acciones, con lo cual, tienes más margen para procesarlas, al limitar el número de acciones por personaje.

Volviendo al ejemplo del camarero, si hay 100 clientes y cada cliente pide una cerveza cada 1.5 minutos, tendrás más “agobio” que si lo piden cada 2.5 minutos. Pues eso es lo que ocurre.

Y a mi, me gustaría que la tendencia fuese al contrario, bajar aún más el GCD para hacer el juego aún más rápido.

Y está muy bien soñar y demandar que todo fuese mejor, pero es que cuando reclamáis según que cosa, siempre lo hacéis con el “deje” de que no lo hacen porque son unos inútiles que no quieren hacerlo. Es como si yo digo que porque el tren no hace Madrid Barcelona en 20 minutos y me encierro en banda de “me da igual lo que me digan, es que renfe son unos inútiles”. Me entristece esa manera de afrontar la información…

Un saludote ^_ ^

1 «Me gusta»
15

No creo que sean unos inútiles. Lo que sí creo es que se han acomodado. Ganan dinero con un esfuerzo X cada 2 años y no van a salir de ahí hasta que la mina se acabe, que tiene pinta que no será pronto. A mí el juego me encanta, hoy mismo pillé la Collector y tengo TODAS, pero también reconozco que tras más de 20 años, me encantaría por lo menos saber que en el futuro tendremos una experiencia completamente renovada que vuelva a sentar las bases de un género.