Mudlet: a MUD client where the script is the product

The client is a scripting host first

Mudlet is a quality MUD client, described as a modern breed of client on the gaming scene, with an intuitive user interface, a specially designed scripting framework and a very fast text display. The README asks you to play immersive, multiplayer, pure-text RPGs on Mudlet.

The audience is therefore narrow and specific: people who play multi-user dungeons, and who want to do more than type commands. Mudlet is not a game, it is a client for text worlds, and the feature list reads like the vocabulary of that world: triggers, aliases, a mapper with autowalk, GMCP, packages.

The key feature list item for understanding the project is the powerful trigger engine. A trigger is a pattern that watches the incoming text stream and fires a script when it matches, which is how a MUD client converts a wall of unformatted text into something a player can act on. Combined with a Lua API and an excellent script editor, that is the whole product: a text stream in, scripts that decide what happens next.

The rest of the feature list supports that. Discord integration lets a player relay or coordinate through a chat platform they already use. Themability covers the interface. Cross-platform capability covers Windows, macOS and Linux, with the claim of full compatibility, running the same scripts on any of them.

Lua rather than a bespoke scripting language

The scripting framework uses Lua, and the README is explicit about why: this allows Mudlet to leverage the existing community and large ecosystem of existing packages for Lua without the many drawbacks of creating a Mudlet specific scripting language.

That decision shapes everything else about the project. Because the scripting language is Lua, the packages a player can install are ordinary LuaRocks packages, and the credits list them: luarocks, lua-http, lua-zip, lua-yajl, LuaFileSystem, LuaSQL, luautf8, argparse, Busted and pugixml among others.

It also means the API is shared across the interface. The README says the Lua API is integrated in Mudlet and shared by all aliases, triggers, scripts, keybindings, buttons and other Mudlet components. That is a specific architectural decision: a script written once behaves the same whether it is bound to a key, attached to a trigger, or placed behind a button. In a client where the same logic often needs to be reachable from several places, a shared API avoids the pattern where every component grows its own variant of the same function.

The trade-off is that a player inherits Lua's semantics. Loose typing, one-based tables and a small standard library are part of the bargain, and the existing package ecosystem is a Lua ecosystem rather than a MUD ecosystem, so some packages do nothing useful in a terminal.

Triggers, GMCP, the mapper and the rest

The feature list is short enough to read straight through: simple to use, very very fast, active development, a big thriving community, a powerful trigger engine, rich Lua-based coding functionality, an excellent script editor, a 2D and 3D mapper with autowalk, powerful and simple to use GMCP, Discord integration, completely themable, open-source and free, cross platform, and full compatibility so the same scripts run on any of them.

Two of those deserve unpacking because they are the ones that separate Mudlet from a plain telnet client.

GMCP is the protocol that modern MUD servers use to send structured game data to the client instead of relying on the player to parse text. The README calls the support powerful and simple to use. The practical effect is that a Mudlet client with GMCP can build a proper interface, with windows and gauges driven by real values from the server, rather than scraping numbers out of a damage message.

The mapper with autowalk is the other. It records the rooms you move through and can then walk you back along the route, which turns a text world into something you can navigate hands-free.

Performance is a stated design goal rather than an accident. The README says the scripting engine is designed to scale to large systems without bogging down, and that the text display is designed to handle thousands of lines in under a second.

Connecting a profile to a game

The README keeps the getting started procedure to a handful of steps, because there is nothing to install beyond the application itself.

1. Download and double-click on Mudlet to run
1. Pick an existing game and hit `Connect`

If you would rather play a game of your choosing, the steps are: click New, enter the Server address and the Port of your game as found on the game's website, for example mygame.com and 2003, pick a Profile name, and hit Connect.

The profile concept is the part that matters afterwards. A profile is a named configuration holding your triggers, aliases, scripts, mapper data and settings for one game, which is how a single client instance serves several games with different automation each. It is also what makes the cross-platform claim practical: the profile is the portable artefact, not the application.

Binaries are downloaded free from mudlet.org, and the README points to the wiki for instructions on compiling Mudlet yourself rather than downloading it.

The 5.0 line and what a public test build means

The release record shows two kinds of artefact. There is Mudlet 5.0.1 from 2026-09-02, and there are Public Test Builds, Mudlet-5.0.0-ptb-2026-10-18-1d019ea and Mudlet-5.0.0-ptb-2026-10-19-b4d2a9f, dated the day before and the day of the last push on 2026-10-19.

The pattern shows a major version in pre-release across the community while the last stable point release sits behind it. The default branch is development, which is where a project in that state does its work, and the roadmap is published on the site under a Mudlet 5 roadmap focused on the first time player experience.

That last detail is a useful signal about the project's priorities. Mudlet's own stated vision is to build the best text gaming experience possible to nurture and grow this niche scene, and a 5.0 effort centred on the first time player experience says the focus is on bringing new players in rather than on adding new technical capability.

For an evaluator, the practical consequence is that a Public Test Build is not a release. The README does not describe a stability guarantee for them, and the naming carries a commit hash so you can tell exactly which tree you are running. Testing a ptb against a live game is how you find out whether the 5.0 changes are tolerable for your profile.

The repository also shows the engineering side: CMakeLists.txt with CMakePresets.json, a .clang-format and a .clang-tidy configuration, CPPLINT.cfg, a docker/ directory, CI/, a .devcontainer/, translation files with a .crowdin.yml, a SECURITY.md and a UI-design-philosophy.md document.

The licence is stated two ways

The licence field on the repository says GPL-3.0. The README, in its own License section, says GPL2+. The COPYING file at the root of the tree is where the actual terms live.

For an end user installing a binary, the difference is mostly academic, since either version of the GPL lets you run the program for any purpose. For anyone redistributing, modifying or shipping a build, the two statements are not equivalent. GPL2+ means the GPL version 2 or any later version, so a distributor may choose the version; GPL-3.0 names one version. That is a real difference for a packager, and it is exactly the kind of detail that should be read off the COPYING file rather than inferred from a badge.

The rest of the licensing surface is the dependency list, and it is long. Qt, Lua, PCRE, edbee, DBLSQD, argparse, the Boost Graph Library, Busted, Ccache, Communi, Hunspell, lua-http, lua-yajl, lua-zip, LuaFileSystem, Luarocks, LuaSQL, luautf8, pugixml, SQLite and yajl are all credited in the README as open source packages the software would not have been possible without. Each carries its own terms, and those travel with any distribution of a build.

One practical note about Windows binaries: the README says Windows code signing is provided by SignPath.io with a certificate from the SignPath Foundation. That is a distribution detail for the project rather than for users, but it is a reminder that a signed Mudlet binary on Windows is produced through a third-party signing service rather than by the project itself.

Editorial conclusion

Mudlet suits a text RPG player who wants to automate the parts of a MUD that a MUD was never designed to automate, and who is comfortable writing Lua that reacts to incoming text. It does not suit someone who wants a graphical RPG, and it does not suit a team that needs the licence to be unambiguous without asking. Before adopting, download a public test build and a released build and compare them on the same game, read the COPYING file at the root of the repository to settle which licence terms apply, and check whether the packages your community relies on, which the README credits as LuaRocks packages, are still maintained.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Mudlet/Mudlet on GitHub
3. Project website
4. README
5. Releases