
**¿Has perdido tus aventuras favoritas? No, solo estaban escondidas en un emulador.**

Vivimos en un mundo sin estanterías. Ya no hay cajas de cartón polvorientas, ni etiquetas escritas con rotulador sobre disquetes de 3½. En una época donde todo es nube, *streaming* y suscripción, corremos el riesgo de perder nuestra memoria digital colectiva: aquellos juegos que nos marcaron, que moldearon nuestro gusto por la aventura, la estrategia o la acción. Emular videojuegos antiguos no es solo nostalgia: es arqueología digital, es memoria autobiográfica en píxeles.

Portales como [CPC-Power](https://www.cpc-power.com/index.php?page=detail&num=298) son templos de la [retroinformática](https://es.wikipedia.org/wiki/Retroinform%C3%A1tica). Preservan juegos que, sin la comunidad, se habrían evaporado como tantos disquetes deteriorados. La retroinformática no es una moda friki: es una forma de resistencia cultural ante la obsolescencia programada y el progreso amnésico. Es el recuerdo de una época en la que cada juego llevaba el sello de su creador y cada carga de cinta era un ritual.

Hoy no guardamos las carátulas en la estantería. Pero podemos guardar su esencia. Igual que la [Wayback Machine](https://ca.wikipedia.org/wiki/Wayback_Machine) captura webs desaparecidas, los emuladores permiten revivir experiencias que de otro modo se perderían para siempre. Y eso tiene una dimensión profundamente humana. Tal como describe la psicología de la memoria, nuestros recuerdos emocionales son fundamentales para entender quiénes somos. Cuando emulamos *La Abadía del Crimen* o *Rick Dangerous*, no solo jugamos: nos reencontramos con una versión más joven de nosotros mismos.

No es solo “recordar cuando”, es **sentirlo**. Emular videojuegos antiguos es mantener viva una parte de nosotros, una biblioteca de Alejandría digital que, si no preservamos, puede desaparecer.


Emular videojuegos antiguos no es solo nostalgia: es preservar la memoria digital colectiva y revivir una parte de nosotros mismos.

La memoria digital: cuando emular videojuegos es revivir el pasado


Cuando el concursante elige una puerta, el presentador abre otra... y el universo de la probabilidad se tambalea. Hablamos del **problema de Monty Hall**, un rompecabezas matemático que desafía la intuición y revela lo poco que realmente entendemos de estadística.

## ¿Qué es el problema?

Basado en el programa estadounidense *Let's Make a Deal*, el experimento funciona así:

- Hay tres puertas.
- Detrás de una hay un coche. Las otras dos esconden cabras.
- Tú eliges una puerta (por ejemplo, la 1).
- El presentador, que **sabe** dónde está el premio, abre otra puerta (digamos la 3) y muestra una cabra.
- Entonces te pregunta: *"¿Quieres cambiar a la puerta 2?"*

La intuición nos dice que es 50-50. Pero no lo es.

## La respuesta correcta que (casi) nadie acepta

La probabilidad de que el coche esté detrás de la puerta elegida inicialmente es de **1/3**. Y de que esté en una de las otras dos es de **2/3**. Cuando Monty abre una puerta con una cabra, toda la probabilidad de 2/3 se transfiere a **la otra puerta no elegida**. Cambiar **duplica** tus posibilidades de ganar.

Este resultado es tan contraintuitivo que incluso **matemáticos profesionales** han argumentado erróneamente que no hay diferencia. Marilyn vos Savant, considerada una de las personas más inteligentes del mundo, lo explicó correctamente en *Parade Magazine*... y recibió miles de cartas diciéndole que estaba equivocada.

## ¿Por qué nos cuesta tanto?

El cerebro humano **no entiende la probabilidad condicional** de forma natural. Pensamos en porcentajes como si fueran fijos, olvidando cómo la nueva evidencia cambia las reglas del juego. Es el mismo motivo por el que nos equivocamos con pruebas médicas, predicciones y decisiones de riesgo.

## Un experimento real

En un estudio, cuando se hizo el experimento con estudiantes, solo un **10% eligió cambiar** su elección. Después de explicarles el funcionamiento, ese porcentaje se multiplicó. Pero hace falta **verlo repetido** para empezar a creerlo.

## Lo que el problema revela

Monty Hall no es solo un juego. Es un espejo. Refleja cómo **preferimos la intuición a la lógica**, y cómo la educación matemática a menudo falla al enseñar el *porqué* de las cosas, no solo el *cómo*.

---

**Referencias**:

- [Blog mutiitu sobre Monty Hall](https://blog.mutiitu.com/articles/5)
- [Wikipedia: Problema de Monty Hall](https://ca.wikipedia.org/wiki/Problema_de_Monty_Hall)
- [ScienceDirect: A psychological analysis of the Monty Hall dilemma](https://www.sciencedirect.com/science/article/pii/S2351978915009087)


El problema de Monty Hall pone a prueba nuestra intuición sobre probabilidad. ¡Cambiar de puerta duplica las posibilidades de ganar!

¡No abras la puerta número 1! El misterio estadístico que desconcierta al mundo


En un mundo hiperconectado, donde la tecnología marca el ritmo de nuestra vida diaria, parece imposible pensar que todo empezó con una web tan sencilla como revolucionaria. Pero la primera web —una simple página del CERN creada por Tim Berners-Lee— no solo transformó la manera en que compartimos el conocimiento, sino que también nos recuerda la fuerza del trabajo en equipo. Y es que, igual que en el fútbol, ningún genio solitario puede llegar lejos sin un equipo que cree el espacio para que brille.

En el fútbol moderno, este principio se hace evidente con nombres como Lamine Yamal, la estrella adolescente del Barça. Su talento es indiscutible, pero lo que le permite desplegarlo es la red de compañeros que le liberan espacio, el entrenador que confía en él y un sistema táctico que lo impulsa hacia la gloria. Así como en la primera web la conexión entre documentos hizo posible la navegación, en un partido de fútbol es la conexión entre jugadores la que transforma un movimiento en gol.

Este paralelismo se refuerza con actividades de teambuilding como el reto de los espaguetis: equipos que, en 18 minutos, deben construir una estructura con recursos limitados. Los grupos que cooperan, escuchan y se coordinan terminan superando con creces a aquellos que tienen un líder brillante pero aislado. En el fútbol, como en la web y en estos retos, la suma supera al brillo individual.

Así como la Biblioteca de Alejandría guardaba el saber antiguo, internet hoy nos conecta con todo el conocimiento del mundo. Pero, como en el fútbol, hace falta equipo, confianza y juego colectivo para que un solo jugador o una sola idea lleguen realmente lejos.

---

**Referencias**  
1. [El FC Barcelona empata explorando límites](https://www.elperiodico.com/es/deportes/20250430/barcelona-explora-limites-cordura-empata-116923837)  
2. [Reto de los espaguetis](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Historia del fútbol - Wikipedia](https://es.wikipedia.org/wiki/Historia_del_f%C3%BAtbol)  
4. [Lamine Yamal - Wikipedia](https://ca.wikipedia.org/wiki/Lamine_Yamal_Nasraoui_Ebana)


La primera web y el fútbol moderno comparten una lección clave: la conexión y el trabajo en equipo son la clave para brillar individualmente.

La primera web jamás creada… y cómo el fútbol nos lo recuerda cada domingo


El 26 de abril de 2025, España se apagó. Literalmente. Un apagón eléctrico masivo dejó a millones de hogares, negocios e infraestructuras a oscuras durante horas. Parecía el preludio del caos: sistemas colapsados, trenes detenidos, hospitales con generadores de emergencia y una población conectada que, de repente, quedaba incomunicada.

Pero lo que podía haber sido una película de terror social se transformó en una demostración de madurez colectiva. Gracias a una sociedad con cultura cívica y una educación que fomenta el respeto y la colaboración, no hubo disturbios ni pánico. Las tiendas mantuvieron la calma, los vecinos compartieron velas e información, y las autoridades pudieron trabajar sin obstáculos para recuperar el servicio.

El comportamiento de la ciudadanía recordó al clásico ejercicio de construir estructuras con espaguetis: cuando los grupos cooperan y escuchan, el resultado es sólido y estable. Y así fue. El personal técnico actuó como una orquesta bien coordinada, con protocolos de respuesta rápida y comunicación eficiente.

Según Red Eléctrica Española, el sistema de gestión de la demanda y el trabajo conjunto con las comunidades autónomas permitieron restablecer el servicio en tiempo récord. Además, el conocimiento adquirido sobre eficiencia energética y *green computing* jugó un papel clave para evitar un colapso tecnológico total.

Cuando volvió la luz, no solo se encendió la electricidad. También quedó claro que la mejor infraestructura de un país es su gente. Y que, incluso en la oscuridad, una sociedad cohesionada puede ser la luz que evita el caos.

---

**Referencias**  
1. [Apagón eléctrico masivo en España](https://elpais.com/economia/2025-04-28/apagon-electrico-masivo-en-espana.html)  
2. [Construir con espaguetis en 18 minutos](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Gestión de la demanda eléctrica - REE](https://www.esios.ree.es/es/gestion-de-la-demanda)  
4. [Green computing - Wikipedia](https://es.wikipedia.org/wiki/Green_computing)


El apagón de España de 2025 demostró que una sociedad cohesionada puede iluminar incluso la oscuridad más inesperada.

Primera luz encendida: cuando el país se apagó… y no cayó en el caos


# El proyecto  
**Versión 1.0**  
✍️ Asistido con IA: Este artículo ha sido redactado con la ayuda de ChatGPT (OpenAI), a partir de bocetos e ideas originales.

Durante el último mes me he sumergido en un proyecto personal que quería ser juego, experimento, y quizá un poco protesta: **WordGuardian**.

Una web para jugar con definiciones absurdas, reales e inventadas. Pero también una ventana a la riqueza semántica de Wikidata y un baño de agua fría sobre la realidad de crear una web indie en 2025.

## 🧩 Objetivo  
Quería crear un juego en el que los usuarios adivinasen definiciones plausibles, generadas o extraídas de forma automática.  

**Pero el camino no ha sido nada sencillo.**  
He utilizado Astro y Preact para evitar el *FOUC* y hacerlo responsive, y he trabajado con gigantescos *dumps* de Wikidata descomprimiendo con `pbzip2`, `zstd` y scripts en **Rust** paralelos.

## ⚙️ Stack y técnicas  

- **Frontend**: Astro, Preact, Shoelace, Vanilla Extract  
  > *Astro ha sido una joya inesperada.* Permite combinar componentes de distintos frameworks y, sobre todo, hacer **renderizado del lado del servidor (SSR)** de forma muy eficiente. Esto facilita que los buscadores indexen el contenido sin problemas —una diferencia clave si quieres tener opciones reales de SEO en 2025. Además, exponer una pequeña API del servidor (con endpoints tipo `/api/xyz`) es directo y sin complicaciones, sin tener que montar un backend completo.  
- **Backend**: Node.js para scrapings, scripts paralelos en Rust para parsear Wikidata  
- **Procesamiento**: *dumps* de Wikidata con p31, p279, p1629... todo un mundo  
- **NLP**: generación de distractores con Groq, heurísticas con *embeddings*.
- **Otros**: Carga sin *FOUC* (*Flash of Unstyled Content*), es decir, evitar que la página se vea "fea" durante unas milésimas de segundo antes de que se carguen los estilos. También hice una optimización mínima y, como siempre, muchas líneas de consola.

También he utilizado el proyecto [**Wiktextract**](https://github.com/tatuylonen/wiktextract), desarrollado por **Tatu Ylönen**, y la base de datos publicada en [**Kaikki.org**](https://kaikki.org), que ofrece los contenidos de Wiktionary de forma estructurada y usable. Sin esta fuente, habría sido mucho más lento construir una base léxica fiable para el juego.

## 💡 Aprendizajes  

- **Wikidata es un tesoro**, pero navegar por ella sin mapa es una odisea: ítems, propiedades, lexemas, glosas, referencias cruzadas... y consultas **SPARQL** que parecen rituales mágicos.  
- He descubierto herramientas como:
  - [Wikidata Toolkit](https://github.com/Wikidata-Toolkit/Wikidata-Toolkit)  
  - [KGTK Search](https://github.com/usc-isi-i2/kgtk-search)  
  - [Wikibase CLI](https://github.com/maxlath/wikibase-cli/tree/main)  
  - [wikidata-filter](https://github.com/alexkreidler/wikidata-filter)  
  - [SPARQL](https://en.wikipedia.org/wiki/SPARQL)
- Los *dumps* de Wikidata suelen venir en **formato JSONL** (JSON Lines): un fichero donde cada línea es un objeto JSON independiente. Es perfecto para procesamiento en *streaming*, porque no hace falta cargarlo todo en memoria. Pero cuando tienes 90 GB... cualquier estrategia requiere paciencia, mucha.
- **Diferencias de compresión**:  
  - `bz2` es muy común en los *dumps* oficiales, pero *lentísimo* de descomprimir.  
  - `zstd`, en cambio, es **mucho más rápido**, especialmente con múltiples hilos. Con `pzstd -d -p10` puedes acelerar bastante la carga, aunque después el cuello de botella es tu propio código 😅
- Generar distractores plausibles no es trivial. Hacerlo con Groq ha sido divertido, pero no siempre fiable.  
- Generar definiciones falsas pero creíbles no es nada fácil. Con Groq o HuggingFace, afinando los *prompts*, pero hay que hilar muy fino.  
- **Los dumps no son para débiles.** Y menos si pesan 90 GB.
- También aprendí a encapsular pequeños servicios NLP con Docker, exponiendo APIs locales de forma sencilla. Con una imagen ligera basada en `python:3.11-slim` y un `requirements.txt`, pude desplegar rápidamente un servicio para hacer cálculos semánticos o similitudes entre frases. Ideal para hacer pruebas locales sin líos de dependencias.
- También estuve explorando el proyecto [**Common Crawl**](https://commoncrawl.org/) para extraer URLs de la web pública. Aunque finalmente no lo integré, preparé un script para filtrar los enlaces y construir un corpus propio. La idea era utilizarlo para generar preguntas o validar definiciones con contenido real, pero quedó en *stand-by*... por ahora.

## 📉 ¿Monetización? Ay...

Tenía la ilusión de cubrir aunque fuera el *hosting* con anuncios. Pero los datos son claros:

- 462 visitas
- 22 usuarios activos
- 0,00 € de ingresos
- Una media de 7 minutos por usuario... pero nadie clica

> En 2025, si no tienes TikTok, una newsletter o 1 millón de páginas vistas, la publicidad no paga ni el café.  
> Hacer una web no es suficiente. Tienes que ser *showman*, tener dinero, o hacer *marketing* diario.

## 🎯 ¿Y ahora qué?

No lo voy a matar.  
**WordGuardian seguirá vivo** como proyecto experimental y como pequeño homenaje a las palabras y a Wikidata.  

Quizá evolucione hacia una app educativa. Quizá sea la base de un juego nuevo.  
O quizá quede como monumento al tiempo invertido en una idea que aún me hace sonreír.

También me ronda por la cabeza empezar a **investigar cómo usar la ontología de Wikidata para generar preguntas alineadas con campos de conocimiento**: ciencia, historia, cultura popular, etc.  
Aprovechar la jerarquía de subclases (`p279`) e instancias (`p31`) para construir *niveles temáticos* o *quizzes por ámbitos*, y hacer que el juego sea un poco menos "psicodélico" y un poco más navegable.  

👉 Pruébalo: [https://eurekatop.com/wordguardian](https://eurekatop.com/wordguardian/es/game)  
📖 Código abierto (pronto en GitHub)  

Un proyecto de [**mutiitu.com**](https://www.mutiitu.com)

© Francesc López Marió, 2025


Durante el último mes me he sumergido en un proyecto personal que quería ser juego, experimento, y quizá un poco protesta: **WordGuardian**. Una web para jugar con definiciones absurdas, reales e inventadas. Pero también una ventana a la riqueza semántica de Wikidata y un baño de agua fría sobre la realidad de crear una web indie en 2025.

Categoría: general