Cómo las mazmorras multiusuario me enseñaron a programar

“Mamá, ¿qué quieres que escriba? Dímelo y te escribiré un programa ". Ese era yo a las 9, tirando urgentemente de la pernera del pantalón de mi madre.

No recuerdo qué, si acaso, terminé escribiendo en BASIC en nuestra computadora Timex Sinclair, pero sí recuerdo que quería que me tomaran en serio, que quería hacer algo que fuera útil para alguien. Creo que mi padre compró esa computadora por capricho de un catálogo de pedidos por correo, lo cual fue sorprendente ya que no es un gran tipo de gadgets. Lo conectamos a un viejo televisor portátil blanco y negro de 8 "que teníamos. Mi mamá escribió un programa que imprimía mi nombre en la pantalla en un bucle infinito.

La computadora me estaba llamando. Mi hermano y yo escribimos algunas cosas en BASIC en esa computadora, e incluso pudimos cargar y guardar nuestros programas usando un reproductor de casetes conectado al conector de audio de la computadora. Intentamos reproducir el casete del software en un reproductor de cintas normal y sonó como chirriar cigarras.

No fue hasta más tarde, a los 14, que realmente me entusiasmé con la programación. Me volví adicto a un juego de aventuras en línea: una mazmorra multiusuario (MUD) gratuita llamada HexOnyx. Hex era un mundo virtual popular con al menos cien personas jugando en un momento dado. Aunque los MMPORG de hoy albergan millones a la vez, en aquel entonces unos cientos de personas en un espacio virtual parecían mucho. Hice grandes amigos allí, y cada noche luchábamos juntos en las mazmorras y en los bosques oscuros con viciosos huargos gruñones y demonios de la descomposición. El juego estaba completamente basado en texto, por lo que la imaginación era obligatoria. Casi 20 años después, todavía tengo imágenes en mi cabeza de algunos de los viejos terrenos del juego.

Cada día después de la escuela era una nueva aventura en el MUD, hasta que la campana de la cena familiar me devolvía al mundo físico. "¡Estaré ahí!" Gritaba, solo para colarse en el comedor mucho más tarde, a mitad de la comida. Nunca hay un punto de parada fácil cuando te enfrentas a una bestia lamia de cuatro patas que quiere tu cabeza para su próxima comida.

Durante meses, mis amigos en línea y yo luchamos obsesivamente con estas criaturas generadas por computadora. Con el tiempo hice avanzar a mi personaje hasta el punto de la inmortalidad, que es el punto final efectivo del juego. * Los inmortales ya no pueden luchar; su papel era ayudar a los nuevos jugadores, resolver disputas, archivar errores, etc.

Cuando me hice amigo de los administradores y desarrolladores de Hex, comencé a mirar el diseño del MUD, tratando de comprender cómo podía desencadenar una experiencia tan inmersiva y preguntándome cómo podríamos mejorarlo aún más.

Había cientos de MUDS en ese momento, y cada uno trató de diferenciarse. Para diferenciar a Hex, los desarrolladores habían creado un constructor de mundos personalizado en el juego. Mientras que otros MUD tenían que editar un archivo de texto plano con un formato propietario confuso, el creador del juego hizo que escribir mundos fuera divertido y permitió a los jugadores involucrarse fácilmente. Yaz, el cuidador de Hex, dijo lo siguiente:

“El objetivo del juego desde nuestro punto de vista en ese momento era crear un entorno que pudiera mantenerse desde el interior del mundo. es decir, nadie necesitaría ejecutar el juego desde fuera. Nos acercamos al constructor del mundo ".

Con el constructor de mundos, podrías escribir una nueva puerta y una nueva habitación en el juego, luego atravesar la puerta hacia la habitación y ver cómo se siente. Esto desencadenó un auge del desarrollo, con muchos mundos nuevos en construcción, esperando ser terminados y conectados con el mapa principal del juego. Estos mundos inacabados eran lugares espeluznantes accesibles solo para administradores y llenos de monstruos sedientos de sangre que deambulaban solos día y noche.

No tenía ningún interés en construir mundos; incluso con el constructor del mundo, parecía demasiado trabajo. En cambio, quería comprender la mecánica del software y realizar cambios estructurales.

A diferencia de los MMPORG modernos, la mayoría de los MUD, incluido HexOnyx, eran efectivamente de código abierto. Descargué el ancestro CircleMUD de HexOnyx, escrito por Jeremy Elson, y lo ejecuté en la computadora de mi casa. Había programado algunas cosas en BASIC antes, pero CircleMUD estaba escrito en C, un mundo completamente nuevo para mí. Conseguir que se compilara era un proyecto. Pero gradualmente descubrí cómo hacer pequeños cambios, y fue emocionante para makeel MUD y ver el impacto de mis cambios a nivel local.

Por lo general, los conceptos de informática se enseñan en algún escenario de negocios artificial y aburrido: clientes, pedidos, productos, profesores, cursos, etc. Pero CircleMUD era un software real, funcional y bastante complejo que vivía en el contexto de un gran mundo mítico. Estaba aprendiendo los fundamentos de la informática con el ejemplo, ajustando funciones como esta:

/* * Function: find_guard * * Returns the pointer to a guard on duty. * Used by Peter, the Captain of the Royal Guard */struct char_data *find_guard(struct char_data *chAtChar){ struct char_data *ch; for (ch = world[IN_ROOM(chAtChar)].people; ch; ch = ch->next_in_room) if (!FIGHTING(ch) && member_of_royal_guard(ch)) return (ch); return (NULL);}

En una función breve, tenemos bucles, condicionales, punteros, una lista vinculada, una matriz, macros de preprocesador y estructuras. Y tenemos a Peter, el Capitán de la Guardia Real.

Según los estándares actuales, partes del código de Circle se considerarían malolientes y poco elegantes. No tenía pruebas, ya que las pruebas de software orientadas a la prevención aún no se habían puesto de moda. Pero para mí Circle era bastante hermoso. Fue un ejemplo de algo más grande de lo que jamás había escrito o incluso concebido escribir antes. En sí mismo, una bifurcación del proyecto MUD DikuMUD, escrito en 1990 por algunas personas en la Universidad de Copenhague, Circle tenía el atractivo de un gran programa en C: se comprometía íntimamente con las llamadas al sistema del sistema operativo, estaba altamente optimizado y controlado por eventos. , e hizo mucho trabajo pesado que hoy en día está escondido en las bibliotecas. Manejó sus propios sockets TCP y búferes de E / S desde cero, definió sus propios formatos de archivo de juego, etc.

Lo que hoy se consideraría metal desnudo era, en ese entonces, la parte superior de la pila. Los creadores de Circle no lamentaron la falta de mecanografía dinámica u otros lujos de alto nivel; se deleitaron con las comodidades de volar por encima del lenguaje ensamblador y de apoyarse en el sistema operativo para todo tipo de tareas importantes.

Como resultado, Circle es un caballo de batalla y, en producción, Hex podría funcionar sin problemas con más de 200 usuarios simultáneos en menos de 20 MB de RAM en un 486. El juego se ejecuta en un gran bucle de eventos de 100 ms que nunca se bloquea; solo da servicio a todos los usuarios actualmente conectados, da un paso al mundo hacia adelante en un tic y luego duerme por el resto del ciclo. Recuerdo haber hecho algo de larga duración dentro de este bucle y haber aprendido por las malas que detiene el juego para todos. Una lección inicial de optimización.

Después de semanas de estudiar detenidamente el código, y después de muchas pruebas y errores, me complació enviar un pequeño parche que cambió el estilo del símbolo del sistema en el juego. En una solicitud de extracción al estilo de mediados de los 90, envié un correo electrónico a los administradores de Hex con mi parche y esperé ansiosamente una respuesta.

Aceptaron mi parche. Lo aplicaron. Y fue mágico ver mi pequeña moneda incorporada en un juego al que tanta gente jugaba todos los días. Los desarrolladores, en su mayoría estudiantes de Ciencias de la Computación en edad universitaria, me dieron su opinión sobre mi parche, al igual que los jugadores.

Seguí trabajando y envié más parches pequeños. Finalmente, Yaz se cansó de jugar al intermediario y dijo: "¿Por qué no editas directamente nuestro código?" y me creó una cuenta en el servidor.

El estado de implementador en Hex fue, con mucho, la responsabilidad más personal que jamás había sentido. Comencé a lanzar nuevos cambios casi todas las noches, recibiendo comentarios inmediatos de otros jugadores. No solo estaba diseñando y construyendo características que yo, como jugador veterano, quería ver en el juego, lo que es más importante, estaba iterando dentro de un circuito de retroalimentación estrecho con otros usuarios.

El circuito de retroalimentación impulsó mi trabajo. Me mantuvo en marcha, a través de errores que parecían ir solucionables y problemas que parecían intratables. No había un horario, solo pequeños pasos interminables todos los días hacia un mejor juego. Estaba enganchado con la profunda satisfacción de mejorar algo que a la gente le encantaba usar, y había alcanzado un increíble estado de fluidez.

Creo que esta es una excelente manera de aprender a programar: en lugar de decir "Quiero aprender a programar", comience con el deseo de mejorar algo que ya existe. Algo que la gente usa. Espere encontrarse con obstáculos y desafíos, y permita que los comentarios de los usuarios y colaboradores sean su estímulo para perseverar en ellos. Muchos proyectos de código abierto hacen que esta oportunidad esté disponible, pero creo que hay algo especial en el entorno de los juegos.

Over the following months, I learned about data structures and memory allocation. I learned about sane ways to structure procedural software. I learned about sockets, data serialization (before JSON or even XML existed), timers and interrupts. I didn’t know the vocabulary for these things beyond what I was able to read in code’s comments and in manual pages for system calls. But I was hooked. Coding for the MUD was all I thought about at school each day, and all I did at home each night.

I added a host of new features over the next year or two. I expanded the MUDs internal economy, building a housing system (virtual storage lockers, really) and a real estate market for them. I introduced scarcity of goods into the game’s economy, writing an algorithm that limited the rate at which the best equipment would be introduced into the world. I acted as an invisible hand, making the game more fun and challenging for people, and it was a blast.

The fun of being a developer pushed me to learn more and strive to build more things that people wanted. I’m an engineer today because of that experience. I’m grateful that CircleMUD was malleable open source code, and that Yaz took a leap of faith in handing the keys over to me at just 14 years old.

I love a medium where you can approach as a consumer and smoothly transition into a producer. Today, Minecraft allows for some modifications in a simple, constrained environment and could be a good gateway for budding programmers. But the art of programming still has a long ways to go before it can be universally accessible. The most popular multiplayer games of today are largely immutable to players. Because popular games like WoW are not open source, it seems harder to get into the role of core contributor on a real, living, breathing system.

I’d love for the next generation of programmers to have as much fun learning to program as I did. Changing the game is a lot more interesting than playing it.

Originally published on my personal website. Thanks to Siobhán K Cronin for proofreading.

If you made it this far, you should join my mailing list about technology and humanity.