lfeutre / lmud

An Erlang and LFE MUD/MUSH Server.

λMUD

λMUD (pronounded "L-MUD" or "El-MUD") is a rather minimalistic MUD server, written in Erlang and LFE, making use of the excellent OTP libraries.

The aim is to have solid support for exploration, roleplaying, and in-game economies deployed on a highly fault-tolerant environment (which supports hot-code loads) where system crashes or reboots are more of an exotic curiosity than a commonplace thing.

Milestones

• Current: 0.7.x
• All: Open

Background

Erlang/OTP is an excellent match for MUD development, with strong support for concurrency through light-weight processes, hot code upgrades, near- transparent mechanisms for distributed computing, etc.

This project has dual ancestry: originally based on the ErlyMUD code, it derives much of its new MUDness from TinyMUD servers like TinyMUSH, PennMUSH, etc.

Run Immediately

If you just want to check out the lmud server, you can do so with the following:

$ make docker-run

This will use the published docker image with a game-data volume.

Building & Running

1. Download the latest:

   $ git clone https://github.com/lfex/lmud.git

2. Change directory, compile the source, and make a release:

   $ cd lmud
   $ make

   Note that this requires having the following installed:

   • GNU make
   • Erlang
   • rebar3

3. Start up λMUD:

   $ make start

   Additionally, you can start the MUD with the LFE REPL (useful if you're going to be developing or debugging):

   $ rebar3 lfe repl

Connecting a Client

1. From another terminal, connect to the game:

   $ make connect

   This make target uses the rlwrap CLI tool, which provides readline support in telnet. That, in turn, allows you to use a command history like with your system shell (including such things as searching the command history with ^r).

   Once connected, you should see something like this:

   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   
   Welcome to:
   
                                 ....
                               .'   ,:
                             .'      \.___..
                           .'      .-'   _.'
                           '.\  \/...-''`\
                             :.'   /   \  :
                              :    () () /
                              (_ .  '--' ':
                                / |_'-- .'
                                \   \  .'_\
                               .|__  \/_/:
                              /          :\.
                             .' -./      .'{\|))
           __       M"""""`'"""`YM M""MMMMM""M M""""""'YMM
           \ \      M  mm.  mm.  M M  MMMMM  M M  mmmm. `M
            \ \     M  MMM  MMM  M M  MMMMM  M M  MMMMM  M
             > \    M  MMM  MMM  M M  MMMMM  M M  MMMMM  M
            / ^ \   M  MMM  MMM  M M  `MMM'  M M  MMMM' .M
           /_/ \_\  M  MMM  MMM  M Mb       dM M       .MM
                    MMMMMMMMMMMMMM MMMMMMMMMMM MMMMMMMMMMM
   
   An El-MUD Game Server, v0.7.0-dev
   
   ----------------------------------------------------------------
     If you are logging in for the first time, then at the 'Login'
     prompt, type the character name you would like to have (case
     insensitive).
   ----------------------------------------------------------------
   
   Login:
   

2. Create a user.

3. Have fun!

lmud's Issues

Move src + include into apps

Now that it's a modern release-based project.

Don't capitalize user names

(Upon creation)

"HELP" command crashes client connection

But only when run as an OTP release.

The connection does not crash when the game server is run from an LFE REPL.

Organize inconsistent commands into same convention

Tasks:

• Create lmud-cmd-help and move the right code in there
• Does it make sense to put help in a text file?
• Are there any other commands besides help that don't follow the convention?

Improve/upgrade file-based game data

Even though we're going to be moving to a graph database, we're still going to need to do the following:

• Export game data to files for management in git (namely github.com/lmud-games repos)
• Work with db data in-memory

This will be v2 of the current file-based storage, and we'll need to support both (switchable via configuration). As such, this epic's integration into the code base depends upon the following:

• #5
• #34

Tasks:

• #42
• #43
• #68
• #44
• #45
• #46
• #69
• #47

Move lmud-util:print to lmud-io:print

This way it's much more clear what that function is for (stuff for the user to read in-game).

Examine errors from Dialyzer

Fix as many as possible.

Add "connected since" and "member since" to user data

Note: user data, not livings/character data.

Use the same file that stores the password. This will require a bump in the version of the file format.

Tasks:

• Bump file format version
• Update user state
• Update user data model
• Update character state
• Update character data model
• Update login functions to generate these
• Add server functions to extract the data
• Add shell commands to query these

Depends on:

• #54

Part of:

• #34

Tweak login help text

Change all references of "player" to "user"

I think I moved away from user to player at one point, but only got part-way through. The conflation between player and character is too easy; that conflation is harder between user and character.

Related:

• #30

Part of:

• #34

Backend: Select a light-weight graphdb solution

Set up milestones, create a current release

Tasks:

• Create milestone 0.4.0 (add tickets)
• Create milestone 0.5.0 (add tickets)
• Create milestone 0.6.0 (add tickets)
• Create a release for current state before making code changes (0.4.0)

Find a good graph library for Erlang

Goals:

• Be able to perform basic graph theoretic operations: get neighbours, shortest path, reachability
• Be able to generate visuals (probably only for debugging; maybe in-game? dunno ...)
• Support file-based saves/exports
• Support file-based loads/imports

It may be that we have to assemble from multiple bits ...

Add basic NPC support

Features:

• NPC data
  • data modelling
  • characteristics such as friendly, tame, wild/fearful, hostile
• Support animals
• Support sentients (classic NPCs)
• Support monsters
• All animals, sentients, and monsters will use the same underlying NPC code

Harmonize and update existing storage API

Features and tasks:

• #29
• #30
• #35
• #28
  • #53
    • #54
      • #31
      • #8
      • #55

Migrate old file-based game-data to use the graph library

Part of:

• #41

Depends on:

• #68

Tasks:

• #45
• Support serialising graph data
  • now that vertex label data has id in it, all that's needed for the vertex is just the label data
  • for the edge we need "from", "to", and edge label data
  • pretty sure that's all that is needed ...
• Support de-serialising graph data (to Erlang digraph)
• Serialise old game data and write to new files
• Ensure that when game loads, these new files are read

Support d20 play

Sub-epics:

• Support d20 character generation
• Support d20 NPCs
• Support d20 monsters
• Support d20 travel
• Support d20 quests / experience
• Support d20 combat

Quick search showed no Erlang-based d20 code out there, so this might be a case of creating another library for a d20 system in Erlang (or LFE).

Update file paths to work on release build

Currently only works when running lmud from REPL.

• Path to src in REPL (working): apps/lmud/src
• Path to src in release (not working): _build/default/lib/lmud/src

Support running multiple games / worlds simultaneously

Tasks:

• Refactor configuration for mudstore so that lookups/calls to the backend are done by-game
• Refactor game server to spawn children dynamically, for each game the server runs
• Support characters moving between games
• Support "incarnating" as a different character in another game (e.g., dream state being a different character in a different game)

Add a backend for ArrangoDB

(Formerly AvacdoDB)

This might be nice for the intrinsic graph-like nature of connected rooms in a MUD ...

• Project page: https://www.arangodb.com/
• Github: https://github.com/arangodb/arangodb
• Docs: https://www.arangodb.com/docs/stable/
• Erlang driver: https://github.com/ErlGameWorld/eArango

Move all state records into include files

Part of:

• #34

Game state include:

• character
• object
• speller
• room
• user
• game
• spell
• room mgr

System state:

• conn
• acceptor
• listener

Options include:

• telnet opts

Develop a story and world as the default game for lmud

I'm thinking woods, forest ... but in extensive quantities. Maybe planet-covering. Backstory would be a massive set of cataclysms that wrecked the planet, and life is several million years into a reset-phase, after one or two extinction level events.

Time spans/ages:

• 4th Age Decline: near complete ecological collapse and end of 4th age (equivalent of 2400 AD? total length of 4th age ~8,500 years)
• 5th Age: Rapid (geologically speaking) temperature decline (after major spike, destruction by fire; lasts ~10,000 years)
• 6th Age/Lost Aeon: global ice age lasting about 190-220 million years
• 7th Age: from equator to sub-topics, temperate forests; gradual blend to boreal forests and tundra; ice caps are huge (lasts about 30,000 years)
• 8th Age: new civilisation rises

This story would take place in the 7th age.

Resources:

• https://en.wikipedia.org/wiki/Pangaea_Proxima
• https://qph.fs.quoracdn.net/main-qimg-0cd458d6f78f806e7505f1af686ebb5d
• https://www.youtube.com/watch?v=2It3ETk2MGA

Downloadable games / worlds

Tasks:

• Figure out a minimally useful / maintainable set of files for describing worlds and stories
• Devise formats for individual files
• Devise a means of packaging game files
• Provide a means of publishing (and downloading) them

Support any lmud games

Tasks:

• Create game browser
• Create game downloader
• Create game installer
• Create in-game, admin wizard that ties these together
• Add new starting "room" for admins to enter the "new game" wizard
• Support pulling in custom game commands into mudshell

Examine error from xref

Fix as many as possible.

Store login user name in user table

It's actually getting stored in the livings / character table now.

This will require a version bump for the file format.

Depends on:

• #54

Part of:

• #34

Add support for a "NEWS" file

Tasks:

• Have news read for a NEWS file in the game directory
• Every time the news func is called, read the file

Support importing game data

This functionality will essentially only be used once: to upgrade game data to the in-memory graph db (see #46). Still useful, though ...

Tasks:

• Use filestore to load data
• Convert loaded data to maps
• Add support for finding / getting all data of a given type
  • all rooms
  • all objects
  • all characters
• Add utility functions for loading all data into memory
  • add function to get list of games
  • add function to get list of tables
  • use these to create additional arity functions for mg-import:from-fs
• Add utility functions for loading rooms into graphdb
  • add vertices for all rooms
  • add edges based upon room name, exits entry in room, and direction
• Add utility functions for loading objects
  • add vertices for all objects
  • add edges based upon room name, objects entry in room
• Add utility functions for loading characters
  • add vertices for all characters
  • add edge for location
  • add edges for inventory
• Add utility functions for loading games
  • add edges for characters in games
• Add utility functions for loading users
  • add edges for games

Some notes: we did this in ticket #68 ...

Load data from files:

(set `#(ok ,rm1) (mudgraph-v1:load "rooms" "room1"))
(set `#(ok ,rm2) (mudgraph-v1:load "rooms" "room2"))
(set `#(ok ,obj1) (mudgraph-v1:load "objects" "sword"))
(set `#(ok ,obj2) (mudgraph-v1:load "objects" "painting"))
(set `#(ok ,per1) (mudgraph-v1:load "characters" "eve"))

We'll want to be more specific with this, though ... maybe indicating the source format?

Then we convert that data to maps for use as "labels" (arbitrary data storage) on the nodes:

(set rm1 (proplists:to_map rm1))
(set rm2 (proplists:to_map rm2))
(set obj1 (proplists:to_map obj1))
(set obj2 (proplists:to_map obj2))
(set per1 (proplists:to_map per1))

We'll probably just include this in the above functions ...

Transform graphdb data into graph lib data structures

Support multiple storage backends

This will essentially be a configuration change and creating an interface for all storage operations.

The "interface" will then dispatch to the appropriate backend, based upon configuration.

Depends on:

• #34

Blocks:

• #41
• #40
• #6
• #16

Tasks:

• Identify all current game state operations
• Create a version "0" of backend support that's just a pass-through to the data file storage
• Update configuration
• Add configuration logic to dispatch to this one-and-only storage backend
• Configuration needs to be game-level, not lmud-level:
  • which backend to use will be determined by the game
  • games need to follow a specific configuration convention
  • lmud will read that to determine what backend to use

Get lmud running again

So much old code in this project ... it won't actually start right now.

Support connecting via SSH

Resources:

• http://marianoguerra.org/tmp/html/ssh/book.html

Use priv instead of resources

Support downloading new worlds in an lmud session

Depends upon #19

Add simple character creation wizard

Depends upon:

• #55

Tasks:

• Define list of playable species
• Let the user's select on
• Set character level, creation time, etc.

Add backend for dgraph database

This is going to be a little tricky, since there's no Erlang driver. We can start with an HTTP driver for the database.

Depends on:

• lfeutre/dgraph#1
• lfeutre/dgraph#2
• lfeutre/dgraph#3

Resources:

• https://github.com/dgraph-io/dgraph
• https://dgraph.io/docs/clients/raw-http/

This closes:

• #39

Rename 'master' to 'main'

Split TODO

Tasks:

• Create Change log / release history file
• Move actionable items into tickets

Upgrade to the latest Erlang and LFE

In fact, update all deps

Convert stdout messages to log messages

Tasks:

• Select log library
• Review all code and replace message with logs

Move file-based storage to gen_server

Tasks:

• Make file operations as atomic as possible
• Schedule regular saves so data is "never lost" (logins should kick off timed / recurring jobs for each user)

Add CLI support for setting access / permissions levels

This will be how someone is granted wizard / world-building rights.

Tasks:

• Make sure the game data functions can be used without the server running
• Create an lmudtcl LFE script
• Add permissions command
• Add set subcommand
• Add --user flag
• Add --level flag

Convert hard-coded file writes to a data model with serialisation support

Right now, the .dat files are something the original Erlang developer used to store Erlang data, but it's all formatted manually, as assembled strings. It would be better to let Erlang do the formatting (e.g., ~p).

Blocks:

• #54

Part of:

• #34

Tasks:

• Create a mini "serialiser" that writes Erlang data to files using format/~p
• Write some tests for it that reads this back (e.g., file:consult)
• Look for all occurrences of 'lmud-filestore':write and replace with new function calls
• Update the following:
  • character
  • user
  • room
  • object
• Test, test, test

Generate files (exports) of game data

Add backend for postgres/CockroachDB

Change all "livings" to "character"

I can't remember if there's any allowance in lmud for NPCs, but if space has been made for them, this change could be a little tricky.

Related:

• #29

Part of:

• #34

Support running lmud from Docker

Tasks

• Find a good base image
• Build for docker
• Test
• Deploy to Docker Hub
• Add README instructions for downloading / installing from Docker Hub
  • ports
  • mounting volumes

Add character commands

• listing associated characters
• joining a game as a character
• creating a new character (will kick off wizard; see #32)

Empty line crashes the game connection

Define graph models for game data

Part of:

• #68

Tasks:

• Decide about general structure
  • explore queries for users
  • explore queries rooms
  • explore queries for objects
• What to use for IDs
• What additional data to store on "label"
• How to best look up, e.g., name by ID
• How to best look up, e.g., ID by name