Lo que un servidor de Metin2 me enseñó sobre sistemas distribuidos.

Antes de escuchar la frase 'sistema distribuido', corría uno. De chico hosteaba un servidor PvP de un MMO llamado Metin2 — uno de los juegos dentro de los que viví creciendo. En mi cabeza corría un juego. Mirando atrás, corría mi primer sistema de producción real: un mundo persistente, una economía viva, unos cientos de usuarios concurrentes, una superficie de abuso, y una expectativa de uptime. Aprendí más ingeniería de ese servidor, sobre todo rompiéndolo, que de cualquier curso que tomé después. Esto es lo que me enseñó — porque cada lección volvió, años después, en sistemas multi-agente en GOGOGO LLC.

Lección 1 — Los usuarios son un test de carga adversarial

Lo primero que te enseña una base de jugadores es que no podés imaginar cómo se va a usar tu sistema. Ajustaba una configuración del servidor, sintiéndome astuto, y a los minutos un jugador había encontrado la combinación de acciones que convertía mi astuta configuración en un exploit de duplicación o un crasheo. No un jugador — la población. Unos cientos de personas, todas hurgando tu sistema a la vez, van a encontrar cada borde que dejaste, rápido.

Eso dejó de sentirse como un ataque y empezó a sentirse como un servicio. Los jugadores eran una suite de tests gratis, implacable y adversarial. Aprendí a diseñar asumiendo que la peor entrada iba a llegar, porque en un servidor vivo siempre llegaba, de inmediato. Cuando construyo sistemas multi-agente ahora, asumo lo mismo: la entrada que no se me ocurrió ya está en camino, y el harness de evaluación existe para ser el adversario antes de que lo sea el cliente.

Lección 2 — Una economía viva es un loop de feedback que podés romper

El servidor de Metin2 tenía una economía: tasas de drop, moneda, valores de ítems, comercio entre jugadores. Yo trataba esos números como configuraciones. No eran configuraciones — eran un loop de feedback. Subí un poco una tasa de drop y la moneda del juego se infla, los precios se distorsionan, y una semana después toda la economía está rota de una forma de la que ningún cambio individual parece responsable.

Ese fue mi primer encuentro real con un sistema que reacciona a tus cambios — donde no podés razonar sobre una variable aislada porque todo está acoplado a través del comportamiento de los jugadores. Un sistema multi-agente es exactamente esto. Cambiá el prompt de un agente y los agentes aguas abajo se comportan distinto, y el efecto aparece tres pasos más allá. No podés ajustar un agente aislado más de lo que yo podía ajustar una tasa de drop aislada. Lo cambiás, mirás toda la economía, medís.

Lección 3 — La corrupción de estado es el enemigo real

Un crasheo en el servidor de Metin2 era molesto pero honesto — se caía, lo reiniciaba, los jugadores refunfuñaban, la vida seguía. Lo que de verdad dolía era la corrupción de estado: un bug que no crasheaba nada pero en silencio dejaba el inventario de un jugador, o la economía, en un estado imposible. Para cuando lo notabas, el mal estado se había esparcido por los intercambios, y no había un punto limpio al cual volver.

Eso me enseñó a temerle a la corrupción silenciosa mucho más que al fallo ruidoso. Es exactamente por eso que hoy soy fanático de la observabilidad y de las corridas reproducibles. Un sistema multi-agente que falla a los gritos está bien — lo ves, lo arreglás. Un sistema multi-agente que en silencio escribe un hecho equivocado en la memoria y sigue es el bug de inventario corrupto de Metin2, ya crecido. El fallo ruidoso es una molestia. El mal estado silencioso es lo que te mata.

Lección 4 — Siempre estás de guardia

Un servidor de juego no se preocupa por tu horario. Los jugadores estaban online cuando yo estaba en la escuela, dormido, cenando. El servidor tenía que aguantar sin mí. Yo no podía ser la cosa que lo mantenía corriendo — el sistema tenía que mantenerlo corriendo, y mi trabajo era construirlo para que no me necesitara a las 3am.

Eso reencuadró la ingeniería para mí de forma permanente. La meta nunca fue 'un sistema que yo pueda correr'. Era 'un sistema que corre sin mí'. Cada lección de fundador y cada decisión de arquitectura desde entonces tuvo esa forma — incluido por qué un equipo chico como el nuestro puede correr cuatro productos sobre un runtime. No escalás trabajando más horas. Escalás construyendo la cosa que no necesita tus horas.

“Creí que pasé mi infancia jugando un juego. En realidad estaba sacando una década de ventaja en ingeniería de producción — carga adversarial, economías acopladas, corrupción de estado silenciosa, y uptime sin mí. El servidor era el programa de estudios. Solo que no sabía que ya tenía nombre.”

Por qué cuento esta historia

No por nostalgia. La cuento porque la educación de ingeniería más útil que recibí no parecía educación — parecía un chico intentando mantener vivo un servidor de juego para sus amigos. Las lecciones eran reales porque lo que estaba en juego era real: si el servidor se caía, gente de verdad perdía su noche. Eso es mejor maestro que cualquier trabajo práctico con una nota.

Si sos joven y estás corriendo algo precario y vivo — un servidor, un bot, un sitio chico que la gente de verdad usa — no estás 'solo jugando'. Estás recibiendo exactamente la educación que recibí yo. Tomalo en serio, anotá lo que se rompe, y notá que la forma de la lección sobrevive a la tecnología por décadas. Más del arco largo en atakanozalan.com, o ezagor por el handle que llevo desde aquellos años.