mutgos / mutgos_server

MUTGOS, a modern MUD MUCK MUSH MOO MU* text game engine

mutgos_server

MUTGOS (Multi User Text Game Operating System) is an attempt to provide a more modern, flexible, extensible server for text-based gaming (MUCK, MUD, MOO, MUSH, MU*, etc). The basic idea is to bring text-based gaming into the modern world, so more can discover, understand easily, create, and enjoy it.

Some of the features MUTGOS plans to offer (or already does) includes, in no particular order:

• Abstraction in major components, to allow for switching out communication mechanisms, commandline interpreters, database backends, in-game softcode languages, security, etc. In turn, this should lead to better maintainability, with code that's easier to fix or modify.
• Better support for handling poor internet connections (cell, public wifi, etc).
• Rich client support (via JSON, for web clients or yet-to-be-written client applications), to support features such as building areas graphically, a graphical debugger, mouseover descriptions, click-to-move, separate tabs for private messages and running programs, sidebars with details about the current room, simple UI elements for programs, etc.
• An in-game language that is more comparable to modern languages and has modern features (AngelScript).
• A security subsystem that has consistent rules while also allowing more flexibility in sharing administrative tasks, but without giving people or programs more privileges (called 'capabilities') than they need.
• Multi-tenant support, to allow multiple worlds (sites) to reside in the same server instance. This could allow a web-based system to get people started on creating a new site easily, without requiring them to set up and administer their own server.
• Nearly every command programmed in softcode to make them easier to implement and modify, and to provide a new installation with plenty of features built-in, rather than having to hunt down and install programs elsewhere or code everything manually.
• A 'global' site where said programs can reside, allowing them to be utilized in every site without making copies.
• Federating different installations (or even different game server types) to allow sending messages, etc.
• Better UTF8 and multi-language support.
• Richer datatypes for object properties beyond the usual number and text string.
• Multi-threaded to allow better handling of load.
• A more extensive commandline interpreter to allow features such as redirection of input/output.
• Version control, to allow backing out of a change to an object.
• 'instances' of an object, to allow for something like a temporary dungeon instance.
• Your idea here!

Currently, a working, but extremely basic (not complete enough to run an actual game) prototype exists and much of the framework has been laid out. There are many unique challenges still ahead, but it's also an opportunity to do lots of learning and create something amazing! Still reading and want to contribute? Join us!

Building and Running The Prototype

Refer to the 'docs' directory for information on how to do build and run mutgos locally. Currently this is best suited for semi-experienced C++ developers with Linux experience, but this will get much easier as time goes on.

A Dockerfile for mutgos also exists. To build and run it:

docker build -t mutgos .
docker run -it -p 7072:7072 --name mutgos mutgos

Expect the build command to take some time to complete as it needs to download and compile boost.

mutgos_server's Issues

Need config file for system/global parameters

A configuration file is needed for system / global parameters (DB file location, how many threads to launch, certain internal limits, etc). Code needs to be written to use the BOOST library for reading this config file, making the parameters accessible to the areas that currently have hardcoded values, and those hardcoded values need to be changed to use config settings.

Searching for TODO should reveal most of the areas that need config-driven values.

Site names / descriptions need to be shown on the main login screen

Currently, at the main login screen, the site name shows as 'not implemented'. The database backend, schema, DB import code, and comminterface need to be modified to store a name (and description?) and display it upon login.

Improve build process to use relative paths and have an install

The build system should use relative paths for access to non-system dependencies, and provide an 'install' option so you aren't running it out of the source tree. There may be other worthwhile improvements to consider as well (perhaps building all the dependencies automatically?).

Socket SSL support needs to be added

Currently, the socket driver supports plaintext (unencrypted) only. SSL support needs to be added. The classes were designed knowing this would eventually happen, so it should be relatively easy to integrate it using BOOST.

Report AngelScript bugs (and praise) to developer

While integrating AngelScript with MUTGOS, some bugs (or potential bugs) were found. These should be reported to the developer and/or better understood:

• scriptarray (from add_ons), has an area in Precache() where it doesn't check for an out of memory condition. I fixed it for inclusion into MUTGOS but it needs to be reported.
• asUnprepareMultithread() causes crash when shutting down MUTGOS; find out if we're just using it wrong.
• Research/report/understand potential Valgrind memory leaks: AngelScript is not garbage collecting all objects when expected (in particular, the main() arguments - an AString, and arrays - a cscriptarray).

Also, let the developer know how great AngelScript is and that it is a core piece to MUTGOS.

Figure out how ActionEntity linking permissions work

Right now there is no design for how permissions for linking an ActionEntity to an Entity work. The design needs to be hashed out and implemented.

AngelScript interface: Improve error output when compiling (show line that has error)

Currently, if there is an error compiling the code, it spits out the AngelScript raw error (line number, column number, and the error itself). This needs to be better formatted AND also show you the line that failed, along with a column marker.

String and Document size limits

Related to #6, global limits on string and Document property sizes should be established, with a policy on how to deal with strings that exceed the length specified and implemented. I don't currently have a preference for the best way to do this. Should it be in dbtypes? In the primitives? Somewhere else?

Plain (or SSL) Socket connections should allow full UTF8

Currently, UTF8 is not fully supported on socket-based connections, to remain compatible with older style clients. The system should support being able to fully enable UTF8 on socket connections (as a per-user toggle) so those who have good clients can take advantage.

Handle bad `server.pem` failure cleanly

If the socket driver encounters an error while loading its SSL key or certificate chain it should fail in such a way that shuts down the system but permits other components to cleanly exit and not core dump.

Design Installation Logic

Decide how mutgos should be installed/deployed in production and design and test a suitable build target.

FuzzBall installed itself in /usr/games and several other locations. I always found this awkward but perhaps it's familiar.

Another way is to make a dockerfile deployment the defacto installation style. This is fairly modern but will require some thought around how to store/backup the database - keeping it inside the container itself is too risky as those are usually assumed to be ephemeral.

One thing to be aware of here is dependencies here. mutgos uses a lot of shared libraries including the third_party software.

Documentation for creating `server.pem`

Should include instructions on how to make it with openssl as well as certbot, where to put it, and caution the user on the importance of protecting it.

How to store external software dependencies?

Some of our dependencies (AngelScript, etc) are hosted on smaller web sites; constantly downloading them from the source is not fair for the owner's bandwidth. Also, should an older version be harder to download or disappear, we want to continue building with it anyway.

How should these dependencies be stored here? A new repo/project? Integrated into this project? I honestly don't know how to handle this yet; suggestions are welcome.

mutgos.conf should have comments sshd config style

In the config files for sshd most lines are commented out and show the default values. This is a good way to tell the user what the default values are and help them keep track of what they've modified.

Need a database 'fsck' type support (or preventing corruption in the first place)

Currently, if the system crashes while Entities are waiting to be written to disk, those updates are lost. While sqlite won't let the file get corrupted, it may cause the references to be all messed up. To solve this, either 'fsck' type code needs to be written that re-generates all the references, or database updates need to be committed as a unit to prevent it from happening in the first place. Or maybe there's some other better way?

AngelScript Scripts needed to support a basic chatroom with rooms and basic descriptions

Once #19 has been completed, this issue can be worked to design, write new issues, etc to write the AngelScript scripts that make use of the new API. When these scripts are complete, a basic MUCK-style chatroom with basic administration and building features will be in place. A big accomplishment! This is of course not the final goal of MUTGOS, but will be a great start and moves us well along on the path.

Some examples of what needs to be done include:

• Improved say, pose, page
• Whisper
• Enhance Entity create command to support all the needed DB types
• New scripts to properly support editing security settings
• A way to link Actions to Entities
• A real 'examine'
• Able to create players, change passwords, and such.
• Enhanced 'who'

Convert .txt docs to .md

The advantage of .md files is they will be rendered easily by github while still being perfectly readable as plaintext. Some of the docs are practically already in this format anyway. See for example security.txt

Add a STYLE_GUIDE.md

It should go in the project top level. May just point to another existing style guide with caveats/deltas e.g. https://google.github.io/styleguide/cppguide.html

If covering C++ style in terms of coding style is premature, a guide covering just code formatting is a fine start for this. Getting something in place where we can document decisions later as we make them is more important than answering every side case now. See https://github.com/Weasyl/weasyl/blob/master/STYLE_GUIDE.md for an example of a simple one I wrote for Weasyl.

Once done, add a new issue about finding a linter (e.g. http://clang.llvm.org/extra/clang-tidy/ looks promising but it may be a poor match for the project's infrastructure)

dump file format should support importing Documents as separate files, to separate out scripts

The dump file format should support #including external files in place of a Document property. This is primarily useful to put scripts in their own files and will cut down on the chaos of merging and maintaining one giant file. It could also temporarily support the shared library concept until it is actually implemented.

Bad SSL handshake should close client connection

This is one for me. Testing by connecting to Fuzzball without ssl on the ssl port and typing garbage will close the socket on the user's side. Presently mutgos does not. This issue is to fix this to be sure my code is not leaking sockets.

Add info and files for how to compile and run the demo database

Information on how to compile the software, import the demo database, run the server, and how to login to the game are needed.

Determine if any static error detection tools should be used (linters, etc) during build

This issue is for someone to determine if any particular linters or other static code analysis tools might be helpful to run on MUTGOS during the compilation process, to make a recommendation, and then to implement it if approved.

UTF8 support

Before the code gets too large, algorithms and policies for processing UTF8 should be established, implemented, integrated, and made available to scripts. I don't know the best policies or algorithms for doing this, so help would be appreciated even if it's just conceptual. #

Finish implementation and testing of web client (demo quality)

The websocket (enhanced client) needs to be finished up and demoed. Primarily, this involves updating the UserAgent to support the enhanced client messaging, writing the web-side code, adding some sanity checks on prototcol window limits, confirming a client that won't or can't send back ACKs will eventually result in a disconnection, etc.

While the result of this is not expected to be perfectly production ready, it would be close and provide a guide to further integration.

Player passwords need to be encrypted

Currently, Player passwords are unencrypted and stored in the database plaintext. This needs to be fixed, preferably without adding new dependencies (using common system dependencies is fine).

Enhance performance of finding command to execute

It seems the more commands that are added, the slower the system gets finding what command is to be executed. I believe this to be mostly because of two factors:

• Security checks are done on all commands, even ones that have no chance of matching.
• The command alias matching code should be changed to match against a giant string rather than many small strings.

Enhancing the search routines to only check security when absolutely necessary should result in a performance boost from what I've superficially profiled, but if not more profiling will need to be done (perhaps it's in the AngelScript subsystem?)

AngelScript interface: Upgrade to latest version to correct potential bad crashes

We need to upgrade to the latest version of AngelScript. It's fixed some serious crashes and of course adds nice new features like basic exception handling in the scripts themselves. This issue is just to try testing all the existing scripts with the new version, and updating the requirements (and any code, if needed) stating it works.

DESIGN: AngelScript API to support a basic chatroom with rooms and basic descriptions

The AngelScript API (what is used by the scripts) needs to be significantly overhauled since it is currently just a prototype. The idea suggested to me was to make the system usable as a basic chat room, except with rooms, descriptions, etc, and being able to manipulate those at a basic level along with basic administration like creating new players. This is of course not the final goal, but a good starting point for a first release.

This issue is to discuss the design needed to do this, using the wiki as needed. Once it is designed, the issue can be closed and new issue(s) written to do the implementation.

The API needs to have stuff like this:

• dbtypes initial representation
  • players
  • exits
  • rooms
  • things
  • commands?
  • programs?
  • Groups/Capabilities?
• Security representation (so it can be viewed nicely and edited)
• Add/remove from groups and capabilities (to give people extra permissions, primarily)
• New system functions required (create player, better 'who is online' functionality, etc)?
• Simple non-interactive tool to edit documents
• Find Entities by name and type
• Fix Document so it can have long lengths for programs, but not for normal use (or allow constructor to specify size).
• Something else I'm missing?

AngelScript script shared library support

AngelScript has many cool features, and one of them is the ability to create libraries of scripts and link them together, like with Linux .so files. Since we're starting development of scripts that are not longer demo quality, common code will come in really handy.

This implementation here would be very basic and manual (using the dump file); a future enhancement (no issue written yet) is to make use of preprocessors and regnames to dynamically find the libraries. It could be even simpler right now and auto-include a library.

AngelScript interface: Improve error output when 'crash' (show line that crashed).

When an AngelScript script 'crashes' (security failure, coding error, etc), the error usually indicates why, but it does not say what line number it happened at. The output needs to be enhanced to show this information, along with the line itself for easier debugging.

ssl support in dockerfile

The Dockerfile should generate a .pem file contianing a self-signed key and a certificate.

Add a Code of Conduct

Low priority until the project has a community around it, but generally best practice for open source projects these days.

https://www.contributor-covenant.org/ is usually a good candidate and the website contains an explanation for why 'golden rule' style CoCs are generally insufficient.

Fix reference updating code to update references immediately rather than on separate thread

Currently, when an Entity changes what room it is in, this updates the references attribute on the room it has left and entered. This is normal, however currently the updating is done on the DB update thread which only polls every 3 seconds. This can cause situations like entering a room but no one can look at you for several seconds, or dropping/getting something and not seeing it for a few seconds.

The solution should be as simple as refactoring the reference updating code to execute immediately, in the same thread of control as the Entity being updated, rather than pulling the request later off a queue.

Site splash screens do not exist

Most text games have a splash screen, giving the name of the game (or 'site' in our case), perhaps some ASCII-art, etc. MUTGOS currently has none of this. A solution for setting and displaying the splash screen needs to be designed and implemented.