Final Fantasy XIV: el MMO que tuvo que destruirse para poder sobrevivir

Serie: Videojuegos que se negaron a morir

Imagina que acabas de lanzar uno de los proyectos más importantes de tu compañía y la conclusión empieza a ser imposible de ignorar: el problema no se arregla añadiendo unas cuantas funciones ni publicando otro parche.

El problema está mucho más abajo.

En los cimientos.

Eso fue lo que Square Enix tuvo que enfrentar con la primera versión de Final Fantasy XIV.

La semana pasada hablamos de videojuegos que encontraron una fórmula diferente. Esta semana estamos descubriendo algo quizá más difícil: qué ocurre cuando una compañía debe reconocer que aquello que construyó necesita cambiar profundamente.

Y pocas historias llevan esa idea tan lejos como la de Final Fantasy XIV.

Hay un momento en cualquier proyecto en el que seguir reparando puede resultar más peligroso que aceptar que necesitas reconstruir.

Cuando el nombre tampoco puede salvarte

Final Fantasy era una de las franquicias más importantes de Square Enix. Precisamente por eso, el lanzamiento original de Final Fantasy XIV en 2010 representaba mucho más que la llegada de otro MMORPG.

Pero el prestigio de una marca no puede compensar indefinidamente una experiencia que no funciona.

La versión original acumuló problemas relacionados con rendimiento, interfaz, diseño y experiencia general. La situación llegó a un punto particularmente incómodo: no solamente había que mejorar el videojuego, también había que proteger la confianza depositada en el nombre Final Fantasy.

Square Enix necesitaba decidir cuánto estaba dispuesto a cambiar.

Entonces llegó una decisión mucho más incómoda

Naoki Yoshida asumió la dirección del proyecto y el problema comenzó a observarse desde otra perspectiva.

Podían continuar corrigiendo la versión existente. Algunas cosas mejorarían. Podían añadir contenido, modificar sistemas y reducir problemas.

Pero existía otra posibilidad mucho más arriesgada:

construir prácticamente un nuevo Final Fantasy XIV.

Eso significaba aceptar públicamente que la solución no estaba simplemente en hacer mejor aquello que ya existía.

Había que replantear tecnología, interfaz, combate, mundo y experiencia del jugador.

Lo sorprendente es que durante un tiempo ambas realidades tuvieron que coexistir. El equipo continuó atendiendo la versión original mientras desarrollaba aquello que terminaría convirtiéndose en A Realm Reborn.

No estaban remodelando una habitación mientras permanecían dentro de la casa.

Estaban construyendo otra casa mientras todavía vivían en la anterior.

El final se convirtió en parte de la historia

Entonces ocurrió algo extraordinariamente apropiado para un videojuego.

En lugar de tratar el cierre de la versión original únicamente como un problema técnico, el equipo lo convirtió también en parte del mundo que los jugadores habían habitado.

Eorzea se encaminó hacia una catástrofe.

El mundo que los jugadores conocían llegó a su final y aquella destrucción terminó proporcionando el punto de partida narrativo para el mundo que vendría después.

El fracaso del producto y la historia del videojuego terminaron conectándose de una manera poco común.

Final Fantasy XIV no fingió simplemente que su primera versión nunca había existido.

Construyó su renacimiento sobre las ruinas de ella.

Y entonces el reino volvió a nacer

En agosto de 2013 llegó Final Fantasy XIV: A Realm Reborn.

El nombre era especialmente adecuado.

No se trataba solamente de una expansión ni de una actualización gigantesca. Había un nuevo motor, una interfaz rediseñada, cambios en combate, nuevas áreas y una experiencia reconstruida alrededor de aquello que el equipo había aprendido.

Pero quizá el cambio más importante no estaba dentro del código.

Estaba en la forma de entender el problema.

Square Enix había dejado de preguntar:

“¿Cómo conseguimos que esta versión funcione?”

para empezar a preguntar:

“¿Cómo debería funcionar realmente Final Fantasy XIV?”

La diferencia entre reparar y reconstruir

Esta historia contiene una lección que va mucho más allá de los videojuegos.

Cuando invertimos meses o años en construir algo, abandonarlo resulta extremadamente difícil. Cada línea de código, cada sistema y cada recurso invertido parece convertirse en una razón para conservarlo.

“Ya hemos trabajado demasiado para empezar otra vez.”

Pero el tiempo que ya invertimos no garantiza que continuar por el mismo camino sea la decisión correcta.

A veces un producto tiene problemas.

Otras veces el producto es el problema.

Distinguir entre ambas situaciones puede ser una de las decisiones más importantes —y más dolorosas— de cualquier proyecto.

Mito o realidad

Mito: reconstruir significa tirar todo el trabajo anterior a la basura.

Realidad: una reconstrucción inteligente también utiliza lo aprendido. Los errores de la primera versión pueden convertirse en información extremadamente valiosa sobre qué necesita cambiar, qué debe conservarse y qué esperan realmente los usuarios.

El primer Final Fantasy XIV no desapareció completamente de la historia. Sus problemas ayudaron a definir aquello que A Realm Reborn necesitaba hacer diferente.

No Man’s Sky reparó; Final Fantasy XIV reconstruyó

Y aquí aparece una diferencia fascinante entre nuestros dos primeros casos de la semana.

Hello Games decidió continuar trabajando sobre No Man’s Sky. Actualización tras actualización, el producto existente fue creciendo hasta transformar progresivamente la percepción de los jugadores.

Square Enix enfrentó una situación diferente. Llegó un momento en el que continuar mejorando la misma base no parecía suficiente.

Los dos proyectos buscaban recuperar confianza.

Pero eligieron caminos distintos.

Uno demuestra hasta dónde puede llegar la mejora continua.

El otro demuestra que también debemos reconocer cuándo la mejora continua ya no basta.

Hoy Final Fantasy XIV puede parecer inevitablemente ligado a su éxito posterior, pero eso hace fácil olvidar lo extraordinaria que fue aquella decisión.

Había una marca importante, una enorme inversión, años de trabajo y un producto que ya estaba en manos de los jugadores.

Continuar reparándolo probablemente habría sido la decisión más cómoda.

Reconstruirlo significaba aceptar primero una realidad mucho más difícil:

habían construido algo que no podían salvar simplemente haciendo más de lo mismo.

A veces salvar un proyecto no significa proteger todo lo que construiste. Significa tener el valor de decidir qué parte debes dejar atrás.

Square Enix cerró una versión de Eorzea.

Después construyó otra.

Y quizá ahí esté la parte más interesante de toda esta historia.

Final Fantasy XIV no sobrevivió porque sus responsables se negaran a abandonar su trabajo.

Sobrevivió porque estuvieron dispuestos a abandonar la forma en que lo habían construido.

Continúa aprendiendo en CodeAndPlay

Si quieres seguir esta serie desde el comienzo, puedes leer No Man’s Sky: cómo un lanzamiento desastroso terminó convirtiéndose en una historia de recuperación, donde vimos una estrategia completamente diferente para recuperar la confianza de los jugadores.