Lo que los juegos me enseñaron sobre memoria, lógica y sistemas

Durante una época llegaba del colegio y lo primero que hacía era encender el Spectrum.

Si alguien me hubiera preguntado entonces, habría dicho que simplemente estaba jugando. Y habría sido verdad. Lo que quería era pasar pantallas, descubrir juegos nuevos, llegar más lejos que el día anterior y disfrutar de aquel pequeño ordenador que, sin saberlo, iba a marcar muchas cosas después.

Pero hubo un momento en el que algo cambió.

Empecé a fijarme menos en el juego y más en cómo estaba construido. Ya no me bastaba con ganar una partida. Quería entender por qué ocurría lo que veía en pantalla.

Cómo guardaba las vidas. Cómo calculaba la puntuación. Cómo sabía que habías perdido. Cómo cambiaba de pantalla. Cómo respondía al teclado. Cómo recordaba en qué punto estabas.

Sin darme cuenta, dejó de bastarme con jugar. Empecé a preguntarme por qué ocurría lo que veía en pantalla y qué reglas hacían posible que todo aquello funcionara.

Y creo que ahí empezó una forma de aprender que todavía me acompaña hoy. Sin saberlo, también empecé a mirar los juegos como sistemas.

Un juego pequeño también tiene lógica

Recuerdo pasar tardes enteras intentando que un juego tan sencillo como el ahorcado hiciera exactamente lo que yo quería. También programé pequeñas versiones de Mastermind y otros juegos muy simples, pero para mí eran mucho más que un entretenimiento.

Cada pequeño cambio era una oportunidad para descubrir cómo pensaba realmente un programa.

No eran juegos complejos. No tenían gráficos espectaculares, ni sonido elaborado, ni pantallas llenas de movimiento. Pero obligaban a pensar.

Un ahorcado tenía palabras, intentos, aciertos, fallos y una condición final. Mastermind tenía combinaciones, comparaciones, posiciones, colores o números, intentos y pistas.

Visto ahora parece muy básico, pero ahí ya estaban muchas piezas importantes:

variables,
bucles,
condiciones,
entrada por teclado,
validación,
mensajes al usuario,
reglas,
estado de partida,
y una condición de finalización.

Hoy todo eso parece normal. En aquel momento era la forma de descubrir cómo se construía algo interactivo desde cero.

No había motor de juego. No había framework. No había una librería que resolviera media aplicación. Si querías que el programa preguntara algo, lo programabas. Si querías que comprobara una respuesta, lo programabas. Si querías que terminara al acertar o al fallar demasiadas veces, también lo programabas.

Eso te enseñaba una idea sencilla, pero muy importante: un juego no es solo lo que aparece en pantalla. Es una lógica que mantiene un estado y toma decisiones.

El estado de una partida

Una de las primeras cosas que aprendías programando juegos sencillos era que todo dependía del estado.

Cuántas vidas quedan. Qué palabra se está adivinando. Qué letras se han probado. Cuántos intentos llevas. Qué puntuación tienes. En qué pantalla estás. Si la partida sigue o si ya ha terminado.

Entonces yo no lo llamaba “estado”. Para mí eran variables, contadores, condiciones y valores que iban cambiando mientras jugabas.

Pero eso era exactamente lo importante.

El juego no se limitaba a mostrar cosas. Recordaba cosas.

Recordaba lo que habías hecho antes y decidía qué tenía que pasar después.

Cuando algo fallaba, no bastaba con mirar la última línea escrita. Había que pensar qué valor tenía cada cosa antes de llegar ahí. Qué variable había cambiado. Qué condición se había cumplido. Qué bucle seguía ejecutándose. Qué dato había llegado mal.

Esa forma de pensar se queda.

Muchos años después, cuando revisas por qué un proceso no llega donde debería, por qué una automatización se queda en un punto intermedio o por qué un servicio responde de forma rara, la pregunta de fondo sigue siendo parecida:

¿En qué estado estaba el sistema cuando pasó esto?

La pantalla no era el programa

Otra lección importante fue entender que la pantalla no era el programa.

La pantalla era solo el resultado visible.

Cuando un enemigo se movía, había coordenadas. Cuando perdías una vida, había una resta. Cuando aumentaba la puntuación, había un contador. Cuando cambiabas de pantalla, había una rutina. Cuando una tecla respondía, había una lectura de entrada. Cuando terminaba la partida, había una condición.

Todo lo que parecía magia tenía una lógica.

Y si tenía lógica, se podía estudiar.

Creo que esa fue una de las ideas que más me marcó: no quedarme solo con lo que veía delante.

La pantalla enseñaba el efecto. La lógica explicaba la causa.

Vidas, puntuación y memoria

Después venía la parte más curiosa: los juegos comerciales.

En aquella época era bastante habitual encontrar trucos, POKE y pequeñas modificaciones para conseguir vidas infinitas, energía, munición o saltarse alguna limitación.

Visto con ojos de niño, la gracia era evidente: hacer que el juego fuera más fácil.

Pero con el tiempo entendías que lo interesante no era solo la trampa. Lo interesante era lo que esa trampa demostraba.

Una vida no era una idea abstracta. Era un valor. Una puntuación era un valor. Una posición era un valor. Una condición de colisión acababa dependiendo de instrucciones, datos y memoria.

Si encontrabas dónde estaba algo, podías cambiar el comportamiento del juego.

Ahí aparecían direcciones, valores, decimal, hexadecimal y esa sensación de estar tocando algo que normalmente quedaba oculto.

Modificar un valor a 255, o verlo representado como FF en hexadecimal, ayudaba a entender que muchos límites visibles dependían de números guardados en memoria.

Aquello me fascinaba. Descubrir que detrás de algo que parecía casi mágico solo había números cambiando de sitio hizo que empezara a mirar cualquier programa de otra manera. Dejé de ver únicamente lo que aparecía en pantalla y empecé a preguntarme qué estaba ocurriendo por debajo. Esa curiosidad me llevaría después a explorar herramientas más formales, como cuento en De BASIC al reversing.

No hacía falta entender todavía toda la arquitectura interna para captar la idea fundamental: lo que ocurre en pantalla depende de datos que están por debajo.

PEEK, POKE y la relación entre dato y comportamiento

Con el tiempo, conceptos como PEEK y POKE empezaban a tener sentido.

PEEK permitía leer un valor de una dirección de memoria. POKE permitía escribir un valor en una dirección de memoria.

Dicho así parece frío, pero en aquella época era una puerta enorme.

Te permitía relacionar tres cosas:

lo que veías en pantalla,
el valor que había en memoria,
y el comportamiento que cambiaba al tocarlo.

Eso cambiaba mucho la forma de mirar un juego.

Dejabas de verlo como una caja cerrada y empezabas a verlo como un sistema con piezas internas.

No era solo “pongo este truco y tengo más vidas”. Era algo más interesante: “si cambio este valor, cambia este comportamiento”. Ahí entendí la diferencia entre consumir tecnología y aprender cómo funciona realmente.

Creo que ahí nació una costumbre que todavía conservo. Cuando una tecnología me interesa, no me conformo con utilizarla. Necesito entender qué ocurre por debajo. Esa forma de aprender me ha acompañado desde aquellos juegos del Spectrum hasta los contenedores, la inteligencia artificial o cualquier tecnología nueva que aparezca en los próximos años. Cambiarán las herramientas. Llegarán tecnologías que hoy ni siquiera imaginamos. Lo que espero que no cambie nunca es esa necesidad de entender qué ocurre por debajo antes de decidir si merece la pena utilizarlas.

Reglas, límites y condiciones

Los juegos también enseñaban algo muy importante: los sistemas tienen reglas.

Una partida no termina porque sí. Termina porque se cumple una condición. Te quedas sin vidas. Se acaba el tiempo. Llegas a una puntuación. Fallas demasiadas veces. Chocas con algo. Sales de una zona permitida. Pulsas una tecla concreta.

Detrás de cada una de esas situaciones había una regla.

Y una regla mal planteada podía cambiarlo todo.

Si la condición estaba mal escrita, el juego no terminaba nunca. Si el contador no bajaba bien, las vidas no se restaban. Si el bucle no salía cuando tocaba, el programa se quedaba atrapado. Si una variable tenía un valor que no esperabas, el resultado dejaba de tener sentido.

Eso me enseñó que programar no era solo escribir instrucciones.

Era diseñar comportamientos.

Y diseñar comportamientos exige entender bien las reglas, los límites y las consecuencias.

Curiosidad, no destrucción

Con el tiempo he descubierto que esa curiosidad sigue siendo exactamente la misma. Lo único que ha cambiado es el tamaño de los sistemas que intento comprender.

Me gusta aclarar esto porque la palabra “hacker” se ha usado de muchas formas y no siempre bien.

Para mí, aquella curiosidad no iba de destruir nada. Iba de entender.

Abrir, mirar, cambiar, observar, aprender. Ver qué pasaba si tocabas un valor. Entender por qué algo dejaba de funcionar. Volver atrás. Probar otra cosa.

Ese enfoque, llevado con responsabilidad, sigue siendo muy valioso.

No se trata de tocar por tocar.

Se trata de entender lo suficiente como para no trabajar a ciegas.

Y eso, para mí, separa la curiosidad técnica del simple trasteo sin criterio.

La semilla de mirar debajo

Visto con perspectiva, aquello tenía algo de análisis inverso muy primitivo.

No en un sentido profesional ni formal. No había metodología, ni herramientas avanzadas, ni análisis serio de binarios. Había curiosidad, revistas, trucos, pruebas, errores y muchas ganas de entender.

Pero la idea estaba ahí.

Observar un comportamiento. Cambiar un dato. Comparar el resultado. Intentar deducir qué estaba pasando internamente.

Eso no te convertía en experto en nada.

Pero te enseñaba a hacer preguntas mejores.

Y muchas veces la diferencia está precisamente ahí.

No en tener todas las respuestas, sino en saber mirar el sistema con la pregunta adecuada.

Lo que me dejaron aquellos juegos

Los juegos me enseñaron lógica, memoria y paciencia.

Me enseñaron que un sistema tiene estado. Que los valores importan. Que una condición mal planteada cambia el resultado. Que una pequeña modificación puede tener un efecto enorme.

También me enseñaron algo que sigo aplicando hoy: cuando quieres entender un sistema, no basta con usarlo.

Hay que observarlo.

Ver cómo cambia. Qué recuerda. Qué condición dispara una acción. Qué dato modifica el resultado. Qué parte visible es solo consecuencia de algo que ocurre por debajo.

Eso eran los juegos entonces: un entorno pequeño, limitado y manejable donde podías observar reglas, cambiar valores y aprender cómo reaccionaba el sistema.

Del juego al criterio técnico

Con el tiempo he entendido que muchas de aquellas horas jugando, probando trucos o cambiando valores no eran tiempo perdido.

Me estaban enseñando a mirar la tecnología de otra manera.

A no creer que algo funciona por magia. A buscar el dato. A entender la condición. A pensar en el estado. A diferenciar lo que se ve de lo que ocurre realmente.

Ese criterio sigue siendo útil hoy.

Sirve cuando revisas un log, depuras una automatización, buscas por qué un proceso no llega al estado esperado o intentas entender por qué un sistema responde de una forma que no encaja con lo que tú creías que habías configurado.

Las herramientas han cambiado muchísimo.

Pero la forma de acercarme a ellas sigue siendo muy parecida.

Hoy sigo haciendo exactamente lo mismo que hacía delante de aquel Spectrum. Solo han cambiado las herramientas.

Sigo mirando un sistema, intentando entender cómo funciona por dentro y preguntándome por qué hace lo que hace antes de decidir si merece la pena utilizarlo.

Al final, el criterio no nace cuando una tecnología se pone de moda. Empieza mucho antes, el día que dejas de limitarte a usar un sistema y empiezas a preguntarte por qué funciona.

Mirándolo con perspectiva, creo que aquellos juegos hicieron mucho más que despertar mi interés por la informática. Sin darme cuenta, empezaron a construir una forma de aprender que todavía hoy me acompaña.

Fuentes y contexto histórico

¿Quieres seguir explorando?

Puedes descubrir más artículos, seguir mis publicaciones en LinkedIn o escribirme.

Ver todos los artículos Seguirme en LinkedIn Contactar