TES Arena, la Ilusion golpeada con la Realidad

Advertencia: El siguiente contenido es mas largo de lo que normalmente subo y uso lenguaje tecnico 

Aqui la version simplificada (LINK de version simplificada)

Con los conocimientos que había adquirido recientemente, quise ponerme a prueba con un nuevo desafío. Me pregunté qué ocurriría si intentaba llevar *The Elder Scrolls: Arena* directamente al navegador. En principio, no parecía una tarea tan complicada. Además, mis amigos podrían jugarlo sin tener que instalar programas ni enfrentarse a configuraciones difíciles.

Mi intención no era presumir de nostalgia, sino permitirles experimentar la atmósfera de los videojuegos de los años noventa: los gráficos pixelados, la interfaz sencilla y esa sensación de encontrarse frente a un mundo enorme que no explica todo desde el primer momento.

Sin embargo, cuando intenté preparar el juego para mostrárselo, descubrí el primer obstáculo. Para ejecutarlo correctamente era necesario instalar DOSBox, configurar los ciclos del procesador, montar unidades virtuales y trabajar con archivos `.bat`. Todo esto puede parecer normal para quienes están acostumbrados a los videojuegos antiguos, pero para alguien que creció utilizando Steam y dispositivos táctiles, el proceso no representa una invitación a jugar, sino una barrera de entrada.

Fue entonces cuando surgió la pregunta que terminaría guiando todo el proyecto:

•  ¿Era posible compartir esta experiencia sin obligar a nadie a atravesar un laberinto de emuladores y configuraciones?
•  ¿Podía construir algo que funcionara directamente en el navegador, se abriera con un clic y pudiera mantener por mi cuenta?

No quería crear un clon exacto de *Arena* ni obtener beneficios económicos con el proyecto. Solo buscaba una respuesta práctica y, al mismo tiempo, quería poner a prueba mis propios límites. Me interesaba descubrir hasta dónde podía llegar un desarrollador con conocimientos intermedios, apoyándose en herramientas de inteligencia artificial como DeepSeek y Google AI Studio, pero sin depender de un agente autónomo que realizara todo el trabajo por mí.

Mi objetivo era construir un motor ligero utilizando únicamente JavaScript. Quería que funcionara en cualquier navegador, incluso en la pantalla de un teléfono móvil. No pretendía utilizar bibliotecas externas ni exigir instalaciones complicadas. La idea era sencilla: abrir un archivo y comenzar a jugar.

Construir el motor fue como aprender a leer de nuevo un mapa que creía conocer. Trabajar con ImageData en un lienzo de 320 × 200 y realizar cálculos directamente sobre la memoria gráfica no era algo sencillo. Un pequeño error podía provocar que las paredes desaparecieran, que las texturas se deformaran o que la pantalla quedara completamente negra.

Mi nivel de JavaScript es intermedio. Sé desenvolverme, pero todavía hay muchos lugares en los que no estoy seguro de dónde pisar. En ese proceso, la inteligencia artificial se convirtió en una especie de copiloto. No la utilicé como un oráculo capaz de resolverlo todo, sino como una herramienta para comprender mejor los problemas.

Por ejemplo, le pedía que me explicara paso a paso el algoritmo DDA, utilizado en los sistemas de raycasting. También necesitaba entender por qué el cálculo de la distancia perpendicular evitaba el conocido efecto de ojo de pez, o cómo proyectar las texturas para que no parecieran un collage mal pegado.

Recuerdo la emoción de ver las primeras líneas dibujadas sobre aquel lienzo negro. En ese momento solo aparecían unas paredes sencillas, pero ya había algo importante: el motor estaba funcionando.

Después llegaron problemas más complejos. Tuve que trabajar con diferentes alturas, niveles de agua y superficies que se encontraban por debajo del jugador. También añadí una mecánica para salir del agua manteniendo presionada la tecla W durante aproximadamente un segundo y medio. Más adelante intenté implementar puertas con bisagras en tres dimensiones y corregí un molesto efecto de rayos X que permitía ver a través de ellas cuando el jugador se encontraba bajo el agua.

Cada corrección representaba una pequeña victoria. Cuando conseguí que los enemigos patrullaran y que el audio se generara mediante procedimientos en tiempo real, empecé a sentir que aquello ya no era solamente una prueba técnica. Era un motor pequeño, pero funcional.

La inteligencia artificial me ayudó a comprender que un programador intermedio puede construir sistemas que, en un principio, parecen reservados para equipos completos. Sin embargo, también aprendí que la IA no sustituye el conocimiento ni el tiempo. Puede explicar, proponer soluciones y generar código, pero alguien debe probarlo, corregirlo y entender qué está ocurriendo cuando algo falla. El motor era solo el vehículo. Todavía faltaba lo más importante: el mundo.

El problema de los datos originales

Para que el proyecto fuera realmente reconocible como Arena y no una demostración técnica con paredes genéricas, necesitaba los datos originales: las mazmorras, los edificios y, sobre todo, las 65 ciudades del juego.

En ese punto conocí OpenTESArena, un proyecto que merece mucho respeto. Durante años, su creador y sus colaboradores han trabajado para analizar los archivos originales de 1994 y trasladar su funcionamiento a un motor moderno. Comprender aquellos archivos, estudiar cómo estaban organizados y reconstruirlos en un entorno actual es una tarea de ingeniería inversa considerable.

Sin embargo, al revisar el proyecto me encontré con una limitación personal: mis conocimientos de C++ son básicos. La arquitectura utiliza herramientas y dependencias modernas que requieren una experiencia que todavía no tengo.

Intenté compilarlo en mi entorno Linux con la intención de crear un exportador que transformara los mapas en archivos JSON. Pero los problemas comenzaron a acumularse: cabeceras de Vulkan, incompatibilidades con GCC, errores del enlazador y configuraciones de CMake que no terminaba de comprender.

Compilar OpenTESArena no es imposible. Es un reto que se puede resolver con estudio y paciencia. El problema es que requiere tiempo para entender el ecosistema, revisar las dependencias y aprender a depurar una arquitectura mucho más compleja. En este momento de mi vida, ese tiempo es precisamente lo que no tengo.

Al no poder extraer los datos automáticamente, me enfrenté a la alternativa manual. La tarea consistía en abrir el juego original en DOSBox, recorrer cada ciudad, tomar capturas, unirlas en GIMP y redibujar cada calle. También tendría que entrar en cada taberna, palacio, gremio y herrería para registrar sus coordenadas, sus nombres, sus tipos de edificio y sus diálogos.

Las 65 ciudades no eran únicamente una cantidad de mapas. Representaban una tarea enorme para una sola persona que también tiene responsabilidades y una vida alejada del teclado. El proyecto comenzó a detenerse poco a poco.

No lo abandoné. Simplemente tuve que reconocer que, en ese momento, no podía abarcarlo todo por mi cuenta.

Lo que la inteligencia artificial podía y no podía hacer

Llegado a ese punto, mi pregunta inicial cambió. Ya no se trataba solamente de saber si podía construir el motor, sino de descubrir hasta dónde podía ayudarme la inteligencia artificial.

No buscaba un agente que navegara por DOSBox o realizara todo el trabajo de forma automática. Quería utilizar la IA como una herramienta para analizar los formatos .MIF e .INF, crear scripts de extracción en Python y encontrar alternativas para compilar OpenTESArena sin depender de una configuración demasiado complicada.

La conclusión fue clara: sí era posible avanzar con ayuda de la IA, pero con ciertos límites.

Las herramientas actuales son muy útiles para descomponer problemas, explicar algoritmos, generar código inicial y proponer soluciones. Gracias a ellas pude avanzar mucho en la construcción del raycaster y en la implementación de varias mecánicas.

Sin embargo, el problema principal no era únicamente lógico. También era contextual y práctico. La IA podía sugerirme posibles soluciones, pero no podía resolver por sí sola todas las dependencias del proyecto ni sustituir mi falta de experiencia en C++. Yo debía compilar, probar, interpretar los errores y decidir qué camino seguir.

En ese momento entendí que el límite no siempre está en la capacidad del modelo. A veces está en el tiempo disponible, en el conocimiento necesario o en la energía para continuar después de varios intentos fallidos.

Un proyecto detenido, pero no abandonado

Este experimento me dejó una conclusión importante: el motor funciona y la extracción de los datos es posible. Lo que todavía falta es encontrar una forma viable de conectar ambas partes.

Para alguien con conocimientos sólidos de C++, experiencia en ingeniería inversa o suficiente tiempo para estudiar el problema, el proyecto sería completamente realizable. Incluso sería posible apoyarse en la inteligencia artificial para acelerar muchas etapas del proceso.

En mi caso, el balance es más sencillo:

• Tengo un motor ligero, funcional y jugable.
• Tengo una idea clara del proceso de extracción, aunque todavía no he podido automatizarlo.
• Tengo conocimientos pendientes de adquirir en C++, pero no puedo obtenerlos en una semana.

Por ahora, el proyecto está detenido, no abandonado. Todavía existen dos caminos posibles. El primero consiste en automatizar la extracción mediante un script que procese directamente los archivos originales. El segundo consiste en utilizar el motor para crear un mundo completamente nuevo, con mis propios mapas, personajes, historia y mecánicas.

La segunda opción también resulta interesante. Significaría dejar de intentar reconstruir los datos de Arena y aprovechar todo lo aprendido para desarrollar un juego propio. En ese caso, no tendría que enfrentarme a los archivos originales ni depender de la estructura de un proyecto antiguo.

La experiencia fue valiosa porque no solo me permitió acercarme a un clásico. También me obligó a entender cómo funcionan los motores gráficos, cómo se construyen los sistemas de navegación y cuáles son los límites reales de las herramientas de inteligencia artificial.

El proyecto descansa, pero no está muerto. En algún momento, con más tiempo o con el equipo adecuado, esas 65 ciudades podrían dejar de ser un muro y convertirse en el mapa de un mundo que cualquiera pueda explorar desde su navegador.

Si has llegado hasta el final de este artículo, quiero agradecerte sinceramente por haber dedicado tu tiempo a leerlo. No siempre es fácil acompañar todo el proceso de un proyecto, especialmente cuando incluye errores, problemas técnicos y decisiones que no siempre conducen al resultado esperado.

Si llegaste hasta aquí, déjame un comentario para saberlo. Me gustaría conocer tu opinión sobre el proyecto, saber si alguna parte te resultó interesante o simplemente confirmar que hubo alguien acompañando esta aventura hasta el final.

Gracias por leer.

Att: Franklin La Cruz

Este articulo fue redactado con ayuda de IA pero bajo mi supervision y aprobacion. 
Recomiento evitar hacerlo asi ya que perdi mas tiempo corrigiendo que escribiendolo