Skip to content


Repository files navigation


Build Status Code Climate Issue Count Discord Channel Go Report Card

DragonMUD is a dream of mine, building a new MUD engine for experience and fun before building my own game on top of it. The engine will be a firm foundation for any kind of text based adventure (for now just Telnet, but eventually web and websocket versions as well). It will feature a plugin system allowing the core of the game to be moldable from the ground up into what you truly desire for your game.

Why should I use this?

That's really up to you. This project is for me, but I believe in sharing. I also feel yet another new MUD engine may inspire some new games to be created in the genre, which would be amazing. I'm a huge fan of MUDs and feel that new entries have kind of become almost non-existent. Perhaps a new game and an accessible low-setup server framework would make it easier for new games to be quickly created.

What exactly is it?

DragonMUD started life as an engine designed specifically for the MUD that I wanted to build, but before long it pivoted to being a base for text based multi-user games. Leverage the power of Lua running on top of Go, DragonMUD aims to provide a quick entry into the genre. Once you generate a new game you can immediately start adding plugins that the community has put together to piece your game together. Want classic rooms? Grab a plugin, what geographically organized rooms? Grab a plugin, want a mapping system? Grab a plugin -- if you can't find one, the build your own and share it with the community!

DragonMUD provides the foundation and the glue code to allow many different plugins to come together and form a cohesive bond, allowing you to build the text based game of your dreams (or non-game, if that's your thing).

What exactly is it not?

DragonMUD is engineered specifically for text based games running over TELNET. It doens't have to be games though, but it does need to function over TELNET. There are plans to provide an HTTP server with websocket support in the future but for the time being you should probably find another engine if you're looking to do anything that isn't text-based.

Why Go?

I love C and C++ but they're older and slightly more complex languages to set up and maintain. Go strives to be a "modern" C and was therefore a good choice in my opinion. It also supports concurrency out of the box in a very easy to use and understand way. It's also relatively low level enough for the purpose of a running a game server.

Why Lua?

I wanted to write my own language, and for a Ruby attempt at this project I actually did. You can find it here but it was a lot of work, has a lot of holes and is relatively unfamiliar to anyone who may or may not be used to scripting games. On the other hand, Lua has been around. It's been tested and it has a slew of core features that would be great to leverage. It's also very common among games as a scripting layer and became a prime choice to replace a custom built engine.


I have grandiose plans. At the moment, they're not divided into versions but as this project matures I will clean up and define these details more and more.

  • TravisCI integration to easily demonstrate stable builds
  • Code climate monitoring GPA of code, maintaining an A - B grade for overall project
  • Test suite to validate working state of features, capturing as many differing/edge cases as possible
  • Neo4j backed database features
    • Neo4j database connection library available to Lua (in development)
    • ActiveRecord-esque Entity framework for the scripts to leverage
  • Script engine for loading and executing Lua files.
  • Plugin system to allow for creation of whatever game one desires
  • Plugin manager (like go get but for DragonMUD plugins)
  • Telnet Server


  • Web layer for defining and building any kind of web server on top of the chosen application


Please reference for details on becoming a contributor and/or collaborator.

Building From Source

To manage this project and ensure reproducible builds I chose to use the glide dependency manage for Go. What this means is that you'll need Glide to ensure you get the same build that I do. Please do not update any dependency without explicit reasoning to defend the upgrade. If required to install new dependencies you can simply do glide get. This will add the dependency to vendor/ which should not be committed.

So the process to set up for contributions is to fork it, and then go get your project:

go get
cd $GOPATH/src/
make get-glide
make get-deps

To build your project:

make install

And if make is not available**, then install with the following command:

glide install
go get
go get
go-bindata -pkg assets -o assets/assets.go -prefix assets/raw assets/raw/...
go install

** But keep in mind, make is used to engineer standard multi-step processes for building/installing so it's highly advantageous to get a version for your OS up and running to use in place of trying to do everything manually.


Brandon Buck, @bbuck,


Copyright 2016-2017 Brandon buck

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.