El videojuego en el que tú eres el sistema operativo
(plbrault.com)- You’re the OS es un juego en el que el jugador asume el papel de un sistema operativo, administrando núcleos de CPU, procesos, páginas de memoria y espacio de intercambio para evitar que el usuario reinicie el sistema
- El flujo básico consiste en asignar procesos inactivos a la CPU y quitar procesos activos; los procesos que se dejan demasiado tiempo sin atender pasan por una etapa de starvation antes de terminarse
- Con el paso del tiempo aumentan tanto la cantidad de procesos como la presión sobre la memoria, así que también hay que encargarse directamente del intercambio de memoria para devolver páginas del disco a la RAM
- La implementación está hecha con Python/Pygame y usa pygbag para generar una compilación en WebAssembly que también puede ejecutarse en el navegador
- No es una simulación exacta de un sistema operativo, pero si se deja clara esa premisa puede servir para explicar la planificación de procesos y las situaciones de falta de RAM
La idea de un juego en el que eres el sistema operativo
- El juego parte de la idea de que el jugador se convierta en el sistema operativo y administre núcleos de CPU, procesos, páginas de memoria y espacio de intercambio
- El objetivo es asignar tiempo de CPU a los procesos y hacer swapping de páginas de memoria cuando sea necesario, para que el usuario no sienta que el sistema está demasiado lento
- Para ajustarse a un juego 2D simple, se eligió Pygame en lugar de un motor de juego completo
- Otra razón fue que el autor quería volver a usar Python
- Pygame puede compilarse a WebAssembly mediante pygbag, lo que facilita su ejecución en el navegador
- El desarrollo tomó unas cuantas semanas dispersas a lo largo de 8 meses
Planificación de procesos y condiciones de fin de partida
- La mecánica central del juego es la gestión de procesos y CPU
- Al hacer clic en un proceso inactivo, se asigna a una CPU disponible
- Al hacer clic en un proceso activo, se quita de esa CPU
- Los procesos inactivos pasan, con el tiempo, por 6 niveles de starvation, indicados con colores y emojis
- Si permanecen demasiado tiempo en la última etapa, el usuario termina ese proceso
- Cuando se terminan 10 procesos, el usuario reinicia al jugador, que es el sistema operativo, y la partida termina
- Para sobrevivir más tiempo, cada proceso debe recibir suficiente tiempo de CPU antes de pasar por todas las etapas de starvation
I/O e intercambio de memoria
- Los procesos activos pueden entrar en estado blocked mientras esperan eventos de I/O
- Como los procesos blocked desperdician tiempo de CPU, conviene quitarlos de la CPU
- Los eventos de I/O se atienden haciendo clic en botones cuya forma cambia cuando ocurre un evento
- A medida que pasa el tiempo, aparecen más procesos y la dificultad aumenta
- A partir de cierto punto, la memoria usada por todos los procesos supera la RAM y se vuelve necesario el intercambio de páginas entre RAM y disco
- Si un proceso activo intenta acceder a una página que está en disco, tanto el proceso como esa página parpadean
- Esa señal indica que hay que hacer swap de la página necesaria
- Los procesos que esperan una página ubicada en disco permanecen en estado blocked hasta que esa página vuelve a la RAM
- Si el estado blocked se prolonga demasiado, pueden seguir avanzando por las etapas de starvation y terminar cerrándose
Dificultad y configuración personalizada
- El juego tiene varios niveles de dificultad
- La dificultad afecta la cantidad de CPU, la capacidad de RAM, el número de procesos presentes al inicio y la probabilidad de eventos de I/O, entre otros factores
- En el modo personalizado, estas opciones pueden ajustarse de forma independiente
Valor educativo y límites
- Este juego es, ante todo, un juego, y fue diseñado priorizando la jugabilidad por encima del realismo
- Hay aspectos que no representan con exactitud a un sistema operativo real
- No se espera que el jugador reaccione tan rápido como una computadora real
- Los procesos usan muchas menos páginas de memoria que un proceso real típico
- La idea de que el usuario siga ejecutando procesos nuevos de manera infinita es una mecánica de juego para aumentar la dificultad
- No fue creado con fines educativos, pero si se deja claro que no busca una representación exacta, puede tener valor para introducir principios de sistemas operativos
- Puede usarse como ejemplo para explicar la planificación de procesos y el intercambio de memoria
- Puede mostrar qué significa tener más núcleos de CPU y qué ocurre cuando falta RAM
Compilación a WebAssembly y despliegue
- La compilación a WebAssembly fue más sencilla de lo esperado gracias a la documentación de pygame-web
- Los pasos principales fueron instalar pygbag y aplicar los cambios de código indicados en la documentación
- El mayor problema fue que la librería pygame-emojis usada para renderizar emojis no funcionaba junto con pygbag
- Como alternativa, se descargaron archivos SVG desde OpenMoji
- Luego se redimensionaron con GIMP y se exportaron como PNG para usarlos en el juego
- La versión para navegador ajusta su tamaño al viewport del navegador manteniendo, por defecto, la misma proporción que la versión de escritorio
- Si la versión de escritorio usa una ventana más pequeña, la imagen en pantalla puede verse estirada
- Como el juego tiene un estilo retro, la pixelación no se sintió como un problema grave
- El juego puede jugarse en el navegador en itch.io
- El código fuente está publicado en GitHub
1 comentarios
Comentarios de Hacker News
Una idea que podría estar genial: un juego de desfragmentación. Básicamente sería Tetris en una disposición circular, donde ganas más puntos cuanto más mandes los bloques de datos de uso frecuente a las pistas exteriores, y los archivos viejos o de tipo archivo comprimido a las pistas interiores.
Antes me encantaba ver cómo las herramientas gráficas de desfragmentación se movían como por arte de magia, y si saliera un juego de desfragmentación, de verdad querría probarlo.
Es un juego 2D con vista cenital, y estás solo en un gran almacén vacío. A intervalos regulares, un camión deja varios objetos en la parte de atrás, y en el mostrador del frente algunas personas piden objetos específicos. Tu tarea es acomodar las cosas dentro del almacén para poder atender las solicitudes lo más rápido posible. Puedes organizarlas de la forma que te funcione: por color, función, nombre, etc.
A medida que avanza el juego, el camión trae una variedad mayor de objetos, muchos suelen pertenecer a varias categorías, y las solicitudes también se vuelven cada vez más complejas. Al final, te muestra un timelapse de cómo cambió el almacén durante toda la partida, para que puedas ver cómo evolucionó tu estrategia con el tiempo.
Está bastante bien hecho y es simple. De hecho, me enteré de él por uno de sus desarrolladores en un comentario de HN.
https://boardgamegeek.com/boardgame/376284/defrag
https://www.defraggame.com
Recuerdo haber jugado antes algunos juegos viejos que eran imitaciones más directas que estos, pero no sé si alguien más podría encontrarlos.
Como en Ender's Game, sería interesante imaginar que un jugador de élite está asignando, sin saberlo, memoria de infraestructura crítica en algún lugar.
https://xkcd.com/1897/
Leí media oración de este sitio web y me convenció por completo.
Es una de las mejores formas de entender este tipo de problema. “Ahora tú eres el administrador de memoria. Buena suerte”.
La idea es realmente buena. Incluso se podría presentar de forma tierna, como una simulación de gestión de restaurante. Solo que el restaurante es la computadora y los clientes son los recursos.
Human Resource Machine también fue excelente en ese sentido. Recuerdo que en algún momento pensé: “Espera, ¿acabo de hacer una lista enlazada?”.
En realidad, creo que la vida humana se parece a una especie de sistema operativo. Todos los días vivimos manejando tareas, recursos, entrada/salida, almacenamiento, caché y estado.
El dashboard es una herramienta esencial de un sistema operativo, y a escala humana eso serían cosas como el banco, las tareas pendientes, el calendario y la bandeja de entrada. Por eso muchos conceptos de “desarrollo personal” se traducen limpiamente a buenas prácticas de sistemas operativos. Por ejemplo, FIFO o LIFO para la gestión de asignaciones, planificación previa para romper deadlocks, gestión de concurrencia y recolección de basura justo a tiempo.
[0] https://algorithmstoliveby.com/
Por ejemplo, cuando los engranajes eran tecnología de punta, había personas que imaginaban engranajes girando dentro de la cabeza y comparaban el acto de pensar con el movimiento de esos engranajes. Creo que todavía se ve a veces esa expresión en caricaturas y cosas así.
https://en.m.wikipedia.org/wiki/Autonomic_nervous_system
Como referencia, esto se publicó en HN el 30 de septiembre, pero no recibió nada de atención, y quien lo publicó borró su propio comentario.
Ya lo dije entonces, pero es un concepto realmente bueno. Estaría bien agregar niveles. Por ejemplo, dividirlos en un microcontrolador dentro de un producto interesante, un smartphone, un balanceador de carga o un servidor API de una empresa SaaS, para introducir los conceptos uno por uno. Eso terminaría siendo una clase universitaria de sistemas operativos.
Sería bueno agregar algo de programación para automatización y profundizar hasta los algoritmos de caché de sistemas operativos. LRU está bueno. Es una clase que me habría gustado terminar antes de graduarme de la secundaria.
https://news.ycombinator.com/item?id=36938032
Es una idea genial, pero para mí es demasiado difícil. Incluso en modo normal, a los 20 segundos de empezar ya estoy haciendo clic como loco, y aunque voy rotando los procesos bloqueados, se me acumulan los procesos rojos.
Algunos procesos murieron porque el evento de entrada/salida nunca llegó. El modo fácil parece igual o incluso más difícil. Ni siquiera llego al punto en que la memoria se vuelve un problema, y a este ritmo tampoco quisiera llegar.
Puede que sea cosa de la edad, y entiendo que ser un sistema operativo sea estresante, pero mi trabajo ya es estresante. No quiero otro trabajo más.
Si empezara fácil y fuera subiendo gradualmente, pero a un ritmo más generoso que se mantuviera apenas fuera de mi zona de confort, podría ser un juego muy divertido.
Este tipo de juegos tiene mucho futuro.
Los juegos que innovan más allá de lo que pueden ofrecer motores como Unity o Unreal van, por diseño, en una dirección con más posibilidades de éxito que muchas de las cosas que salen hoy.
Si haces un juego ultranerd que queda tan fuera del ámbito que los usuarios de esos motores ni pueden tocarlo, juegas en otra liga. Aunque el juego se vea hecho un desastre, basta con que sea divertido y usable.
Los juegos indie murieron en el sentido que tenían hace 5 años. Ahora esto es el nuevo juego indie. GG. Como referencia, soy un desarrollador indie fracasado que sacó 2 o más títulos comerciales.
Es una lástima que Zachtronics se haya detenido. Siempre estuvieron adelantados.
Y este juego parece algo que también se podría hacer con Unity.
Si significa “convertirse en un éxito inesperado que abre camino y cambia el rumbo de los juegos”, la probabilidad es extremadamente baja en ambos casos, pero un juego fuera del molde puede tener más probabilidades.
Tiene más probabilidades de pegar un jonrón, pero también más probabilidades de quedar fuera, y menos probabilidades de pegar un hit.
En los últimos años también hubo varios juegos para nerds técnicos, pero ninguno que pueda llamarse un hit. Probablemente puedas hacer tu propio juego, pero como el público es inherentemente pequeño, el techo del éxito también es limitado. No creo que esto vaya a cambiar en el futuro.
Más bien, probablemente ocurra lo contrario. Las generaciones más jóvenes parecen volverse menos nerds y alejarse más de los temas de bajo nivel y de la tecnología.
A medida que el juego se vuelve más difícil con alta utilización, debería permitir “comprar” mejoras con tokens obtenidos al alcanzar hitos u objetivos de rendimiento, para automatizar pequeñas tareas repetitivas. Algo al estilo de Universal Paperclips.
Luego te lanza cargas de trabajo patológicas que rompen las automatizaciones simples y obligan al usuario a resolverlas manualmente. Entonces el usuario compra una automatización un poco mejor, pero vuelve a quedar bloqueado por cargas de trabajo un poco más patológicas. Así se completa el bucle de progreso del juego.
¿Pronto el sistema operativo ofrecerá un lenguaje de scripting para poder automatizar tareas?
Ah, ya entendí...
Muy genial. Me recordó a un juego que apareció la semana pasada. ¿Era algo relacionado con Defcon? Era un juego en el que caían cuadrados como bloques de Tetris con códigos de operación, y el usuario tenía que armar una secuencia tipo Rube Goldberg para mezclar el número más grande en el registro de memoria de “puntaje”.
https://news.ycombinator.com/item?id=37083309