UMU Launcher se ha convertido en una de esas herramientas que, sin hacer mucho ruido, cambian la forma de jugar en Linux. Lejos de ser un «launcher» gráfico al uso, su misión es unificar cómo se ejecutan juegos de Windows con Proton fuera de Steam, para que cualquier cliente o script pueda aprovechar el mismo entorno que usa Valve sin depender del propio Steam.

Para entenderlo rápido: UMU copia el modelo de contenedores de Steam Runtime (el mismo que usan Proton y Steam Linux Runtime) con algunos retoques, de forma que Proton funcione de forma idéntica a como lo haría dentro de Steam, pero desde cualquier lanzador compatible como Lutris, Heroic o Bottles, e incluso desde un simple comando en terminal. Y sí, no necesitas tener Steam instalado para usarlo.

Qué es UMU Launcher y de dónde viene su nombre

UMU es, en esencia, una adaptación del Steam Linux Runtime «sniper» y las Steam Runtime Tools, con su propio punto de entrada y utilidades para que terceros lo integren. El nombre «umu» no es casual: hace referencia a un horno polinesio de piedras volcánicas calentadas, sobre el que se «cocina» lo que pongas encima. La metáfora encaja con la herramienta de contenedores de Valve llamada «pressure-vessel»: UMU sería ese «fogón» sobre el que se coloca el recipiente a presión para preparar el entorno donde Proton «cocina» tus juegos.

Cuando Steam arranca un juego con Proton, lanza una cadena de procesos donde normalmente aparece steam-launch-wrapper (un mero runner que reenvía variables de entorno) y, lo crucial, el SteamLinuxRuntime_sniper con su _v2-entry-point que monta el contenedor y carga Proton. UMU replica esa lógica: el script _v2-entry-point se renombra a umu, se añade umu-run para sustituir a steam-launch-wrapper y se ajustan los detalles necesarios para usar Proton fuera de Steam manteniendo las expectativas de entorno que Proton necesita (variables de entorno incluidas).

Cómo funciona: variables de entorno, contenedor y «umu-run»

La clave está en arrancar el juego dentro del mismo tipo de contenedor que usa Steam, con las variables correctas para Proton. UMU permite invocar umu-run indicando el ejecutable del juego, los argumentos y, opcionalmente, el WINEPREFIX, la versión de Proton y la tienda de la que proviene el juego para aplicar arreglos específicos.

Parámetros y variables principales de umu-run que conviene conocer:

• WINEPREFIX: ruta del prefijo WINE. Si no lo indicas, UMU lo crea por defecto en $HOME/Games/umu/GAMEID. Si no defines GAMEID, el prefijo por defecto será $HOME/Games/umu/umu-default.
• GAMEID: puede ser un valor arbitrario o un ID válido en la umu-database. Si no lo defines, se utiliza umu-default (sin fixes automáticos).
• PROTONPATH: ruta completa a la versión de Proton que quieres usar. También admite el valor «GE-Proton» para descargar automáticamente la última build de GE-Proton. Si no lo indicas, UMU-Proton (una build estable de Valve con compatibilidad UMU) es la opción por defecto.
• STORE: tienda o «storefront» del juego (por ejemplo, egs, gog, etc.). UMU combina STORE + GAMEID para buscar fixes específicos en su base de datos.
• PROTON_VERB: verbo de Proton a utilizar. Si no lo estableces, usa «waitforexitandrun».
• UMU_LOG: activa registros de depuración de UMU. Útil para diagnosticar problemas.
• UMU_ZENITY: si está activo, muestra ventanas emergentes con zenity al descargar ficheros grandes.
• UMU_RUNTIME_UPDATE y UMU_NO_PROTON: opciones adicionales para gestión de runtime o escenarios donde no quieres que UMU gestione Proton.

Además, UMU descarga y usa automáticamente el Steam Runtime necesario para la versión de Proton elegida, y coloca sus archivos en $HOME/.local/share/umu. Con eso, el contenedor del runtime queda listo y el juego se ejecuta como si fuese nativo de Steam, solo que fuera de Steam.

Ventajas: por qué esta unificación importa

El enfoque de UMU facilita que todos los lanzadores hablen el mismo «idioma» a la hora de ejecutar juegos con Proton. Con ello se consiguen varias ventajas claras para usuarios y desarrolladores:

• Sin requisitos de Steam: ya no necesitas el cliente ni binarios de Steam para usar Proton.
• Base de fixes unificada: las correcciones específicas de juegos (protonfixes) son compartidas por toda la comunidad y los distintos lanzadores.
• Paridad con Steam: los juegos arrancan con Proton dentro del mismo tipo de contenedor que usa Steam, replicando su entorno.
• Mantenimiento centralizado: si algo cambia, se actualiza en Proton GE y/o en protonfixes o en una build unificada de Proton, afectando positivamente a todos.

Hoy protonfixes empaqueta una carpeta local de «gamefixes», pero el propio proyecto sugiere que podría evolucionar a descarga en línea para que cualquier herramienta que use umu-run obtenga de forma centralizada los fixes que necesite.

protonfixes y la umu-database: cómo se aplican los arreglos

UMU plantea un flujo simple para que un lanzador identifique el juego, su tienda y el fix que corresponde, y lo aplique automáticamente antes de ejecutarlo con Proton. El proceso, tal y como lo describen, consta de estos pasos:

1. Crear una base de datos con títulos de juegos, sus IDs en distintas tiendas y el umu-ID correlacionado.
2. El lanzador busca en la base los datos del juego y recupera el umu-ID, que pasa a umu-run junto con STORE, Proton, WINEPREFIX, ejecutable y argumentos.
3. Al arrancar el juego con umu-run, protonfixes detecta STORE + umu-ID, encuentra el script de fix adecuado y lo aplica antes de la ejecución.
4. protonfixes organiza los scripts en carpetas por tienda. Un mismo juego mantiene el mismo umu-ID en varias stores; puede tener scripts específicos por tienda o enlazarse a un fix existente si comparte necesidades.

Un ejemplo que ponen es Borderlands 3 en la tienda de Epic (EGS). EGS usa «codenames» como «Catnip». El lanzador detecta que la store es egs y el codename es Catnip, consulta la base, lo asocia a «Borderlands 3» y al umu-ID correspondiente (por ejemplo, umu-12345), y ese ID se pasa a umu-run. Así se garantizan los fixes correctos incluso cuando la tienda no usa el nombre comercial del juego.

Referencias de uso: opciones y ejemplos

UMU incluye documentación tipo man page para umu-run, con formas de uso como umu-run , umu-run ] o umu-run winetricks , además de --config <FILE> y --help. Entre sus ejemplos proponen casos prácticos como:

• Ejecutar un juego de forma directa.
• Ejecutar un juego con un protonfix específico.
• Usar un archivo de configuración para parametrizar la ejecución.
• Crear un WINEPREFIX UMU y lanzarlo con Proton.
• Seleccionar Proton automáticamente (y crear el prefijo si hace falta).
• Definir un verbo válido de Proton explícitamente.
• Activar logs de depuración para diagnosticar fallos.
• Forzar una versión concreta de Proton por nombre.
• Usar la última build de GE-Proton de forma automática.
• Ejecutar verbos de winetricks desde umu-run.
• Desactivar la aplicación de protonfixes si lo necesitas.

Como utilidades relacionadas, la documentación referencia winetricks, zenity, el propio umu(5) y documentación del container runtime de Steam. También enlaza repos de Proton, umu-protonfixes y la umu-database, para quien quiera profundizar o contribuir.

Construcción e instalación: desde make hasta nixpkgs

Para quienes prefieren compilar o empaquetar, UMU documenta que la build requiere bash, make, scdoc y herramientas de Python (build, hatchling, installer, pip). Además, piden cargo con MSRV mínimo igual a la versión estable más reciente de sus dependencias directas.

El flujo recomendado es: descargar el código, entrar en el directorio, ejecutar configure.sh --prefix para ajustar el prefijo de instalación (por ejemplo /usr/local o /app si vas a empaquetar en Flatpak), correr make y, si todo va bien, tendrás los artefactos en ./builddir. Luego puedes ejecutar make install para instalar.

Para instalación de usuario, UMU coloca el ejecutable en $HOME/.local/bin. Asegúrate de añadir ese directorio a tu PATH (por ejemplo, exportándolo en $HOME/.bash_profile) si quieres invocarlo sin ruta completa.

Alternativamente, proponen usar uv para crear un entorno virtual y configurar UMU rápidamente. La guía sugiere generar un script en el directorio del proyecto, crear el virtualenv con uv, instalar las dependencias y ejecutar el script a través de uv.

En NixOS/nixpkgs, UMU está disponible como pkgs.umu-launcher desde 25.05 (rama inestable en el momento indicado). También detallan cómo usar flakes si necesitas una snapshot más reciente que la del canal, e incluso proporcionan ejemplos para NixOS y home-manager. Si trabajas con canales más viejos (como nixos-24.11), sugieren combinar múltiples canales o tirar de su flake.

Parámetros de empaquetado que puedes sobrescribir en nixpkgs:

• extraPkgs: añadir paquetes extra al entorno FHS (por defecto pkgs: []).
• extraLibraries: añadir bibliotecas extra al entorno FHS (por defecto pkgs: []).
• withMultiArch: incluir bibliotecas de 32 bits en el entorno FHS (por defecto true).

Si usas su flake, puedes configurar dependencias opcionales como:

• withTruststore: habilita el uso del trust store del sistema (por defecto true).
• withDeltaUpdates: activa dependencias para «delta updates» de Proton (por defecto true).

También muestran formas de aplicar el overlay vía specialArgs o directamente dentro de flake.nix, además de un ejemplo de «override» de los argumentos del paquete.

Runtime de Steam, registros y depuración

UMU se apoya en el Steam Runtime basado en contenedor (el mismo que usan juegos nativos de Linux y Proton 8.0+). Para diagnosticar problemas en ese entorno, el propio runtime soporta variables de entorno útiles cuando se lanza con el cliente de Steam, que también te sirven como referencia al trabajar con el contenedor:

• STEAM_LINUX_RUNTIME_LOG=1: habilita logs que aparecen en SteamLinuxRuntime_sniper/var/slr-*.log (con el AppID en el nombre). slr-latest.log es un symlink al último generado.
• STEAM_LINUX_RUNTIME_VERBOSE=1: más verbosidad en la salida (a ficheros si hay LOG=1 o al mismo sitio que el output de steam si no).
• PRESSURE_VESSEL_SHELL=instead: en lugar de iniciar el juego, abre una shell interactiva dentro del contenedor para inspección.

Valve documenta supuestos sobre distribuciones soportadas, consejos de depuración, y mantiene notas de versión y problemas conocidos del runtime. Si desarrollas juegos y te interesa apuntar a ese entorno, revisa su SDK y la información técnica para desarrolladores. Todo el runtime integra software de terceros con sus licencias abiertas y el código fuente está disponible en directorios versionados (consulta VERSIONS.txt para ver las correspondencias).

Novedades y hotfix recientes

En un cambio reciente, los mantenedores publicaron un HOTFIX que revierte cambios del «reaper» porque rompían UMU dentro de sesiones gamescope en Flatpak. El listado indica:

• Reversión de «umu_run: complete the implementation of reaper in umu».
• Reversión de «umu_run: run steammode workaround on the main process».
• Reversión de «umu_run: use hardcoded display values for now».
• Actualización de las notas de la versión (bump release notes).

Este tipo de hotfix muestra que el proyecto reacciona rápido ante regresiones en entornos específicos como Flatpak + gamescope, algo clave para usuarios de Steam Deck o escritorios que usen ese stack.

Estado del proyecto: primera versión oficial y objetivo real

Se ha destacado la versión 1.1.1 como primer lanzamiento oficial del Unified Linux Wine Game Launcher de Thomas «GloriousEggroll» Crider y la comunidad de Open Wine Components. Subrayan que no es un lanzador gráfico como Steam/Heroic/Lutris, sino una capa común que esos lanzadores pueden usar para ejecutar juegos con Proton fuera de Steam con la misma fidelidad que dentro de Steam.

Indican que debería funcionar dentro de Flatpak y Snap, y proporcionan instrucciones de empaquetado para ambos formatos en su repositorio. La meta es que cualquier app pueda lanzar títulos de tiendas como Epic, GOG o Amazon con la misma calidad que en Steam, beneficiándose de protonfixes y la base de datos unificada para una compatibilidad cada vez mejor.

Enlaces y documentación recomendada

Para profundizar, la documentación enlaza recursos como Steam Runtime Sniper release notes, issues conocidos del runtime y cómo reportar bugs, además del documento sobre container-runtime. También conviene revisar:

• Winetricks: https://github.com/Winetricks/winetricks
• Proton: https://github.com/ValveSoftware/Proton
• umu-protonfixes: https://github.com/Open-Wine-Components/umu-protonfixes
• umu-database: https://github.com/Open-Wine-Components/umu-database
• Container runtime: documentación oficial

El proyecto está mantenido por Open Wine Components con ayuda de más contribuyentes. Si quieres colaborar, recomiendan instalar ruff desde tu distribución y habilitar ruff server en tu editor para mantener un estilo consistente en el código.

UMU se sitúa como pegamento técnico entre Proton y los lanzadores, con un runtime estandarizado y una base de fixes compartida; con ello, la comunidad puede avanzar más rápido y con menos fricción, y los usuarios ganan en estabilidad y simplicidad al ejecutar sus juegos fuera de Steam con la misma calidad.