mattgibney/openmud

telnet openmud.moppler.co.uk 3200

OpenMud

OpenMud is a freely available and fully open source text-based MMO game. It's a passion project of mine and something that I intend to do to keep me entertained in my spare time. I have some pretty grand ideas for how I'd like to develop this game, but at first I will be starting small. During development, I will do my best to keep a development blog outlining what my plans are and how I approach problems.

Development

Getting Started

Running the application:

1. Clone Repo
2. Install deps npm i
3. run nx serve game-server

Running tests:

npn test to run once. npm run watch:test to run the tests on save.

Deployment

Build Script

Deployments are always done from GIT tags. Once done, you will have a new tarball for the version of your application that you are deploying.

1. Ensure your GIT working directory is clean
2. Ensure that the version number in your package.json matches the tag you wish to deploy.
3. Run the build command ./dev-bin/build.sh 0.0.1 replacing the version number with the one you want to deploy

Deploy Script

Deployment assumes that your target server is set up correctly. Details not provided as everyone manages their server differently. You can see the script for guidance on how it's done in this project, but you will need to re-implement to fit your own needs.

1. Ensure your GIT working directory is clean
2. Run the deploy command ./dev-bin/deploy.sh 0.0.1 USERNAME@SERVERIP. Please note that the second argument is an SSH connection string.

Branches

The main branch for the repository is develop. All branches for feature work are to be created from develop and merged back to develop. the main branch is to represent the production environment.

Comments in code

There are somme pretty strong opinions on either side of the fence when it comes to comments in codebases. In my opinion, they are incredibly important. Comments exist to provide context to code where it otherwise doesn't exist or isn't clear. Comments should always be added wherever it is importnat to explain why a piece of code works in a particular way, they should not describe what the code is doing.

As a general rule of thumb, you should always assume that whoever is reading your code (including yourself in 6 months when you've forgotten all about it) knows how to code and understands what the code is doing. Your comments should explain why it's done in that particular way.

The main exception to this rule is when adding comments to abstractions, such as functions or classes. Comments in these situations acts like documentation to your code. It describes to another programmer what your function does and how to use it.

World Building

I am not a writer, nor am I a world builder. It's very likely that the world I build for this game will be un-inspired and a littel cliché. That being said, i'll always do my best; hopefully along the way i'll get the attention of some passionate world-builders who want to help me out in my endeavour.

openmud's Issues

Application serves a website

Add a web server to the application allowing it to serve HTML content. This can initially be used as a way of serving basic game information. At a later date, it can be expanded to include game features that can be used outside of the actual game, including sending messages to other players etc.

Acceptance Criteria

• Server is accessible to browsers on standard ports.
• Provides incredibly simple homepage with basic information about the project.

Create a mechanism for chaining commands

There is occasionally need to trigger cascading behaviour when running commands. For example, once a player has moved between rooms, we want to immediately use the look command in the new room.

Telnet connection support

User Story

As a player, I would like to connect to this MUD in the same way I connect to all other MUDs that I play or have played in the past, using a client over a telnet connection. The experience should feel familiar to me and work over a bare telnet connection, or through a client such as Mudlet.

Acceptance Criteria

• After connecting to the server, the player should see a message informing them of a successful connection
• Before the server closes, a message should be sent to all active connections
• Code is written in a way that would allow for alternate concurrent connection methods in the future.

Application Config

The application should have a configuration file, this will make it much easier to manage application config and change things based on the environment that the application is running in.

System Logging

User Story

As an administrator, I would like there to be extensive logging within the application that records everything that happens while the server is running. These logs can be used to help track down issues, they can also be used to deal with complaints by players.

Acceptance Criteria

• Logs are in a machine-readable formal ndjson
• The application has different logging levels. When the logging level is turned down, only more severe messages are actually recorded.

Persistent storage layer

Implement a persistent storage layer for the game data. It does not have to be anything fancy as the game is never going to reach any sort of scale where performance will be much of a factor. If that ever does happen, the DAO layer should help to reduce the headache.

Acceptance Criteria

• Data is stored in a persistent location and survives server restarts.

Rooms

'Room' might not be the most appropriate name for what this is but it's a pretty standard term used across the entire MUD community. A room represents any single location that the player (or players) can be at any one time. A room might be a space inside of a building or it could be a vast open field or a desert.

Acceptance Criteria

• Has a title and a description
• Multiple players can exist in the same room at the same time
• Players see the title and description of their current room when using the look command

Add help command

https://github.com/Moppler/OpenMud/blob/22d5c1e1ace48547ce7cba6c1172c7f20c39d0ef/src/commandFactory.ts#L28-L28

User Story

As a player, I would like there to he a help command. When used, this command will provide a list of possible commands. I would also like the option to provide the name of a command as an argument to get help text specific to that particular command.

Acceptance Criteria

• Using the command help returns a list of possible commands
• Using a command such as help look will provide help text for that particular command
• If the provided help argument does not match with a command, an error is returned to the user

Player accounts

User Story

As a player, I would like a persistent account that belongs to me. When I return to the game, I would like to provide my username and password to authenticate. After that, all actions I perform are as my account.

Acceptance Criteria

• Players MUST be authenticated before they can navigate around the world
• Players authenticate by first providing a username, then a password
• Passwords are not directly stored, only a hash of the password

Establish Development Environment

In order to ensure that development is easy and consistent. A solid development environment must be established before any real work can begin. This includes linting and prettier tooling, an environment for running tests, IntelliSense, and a set of clear instructions that allows anyone else to get this project up and running on their own machine.

• Linting
• Prettier
• IntelliSense
• Testing framework
• Clear instructions

Bug: CodeQL config broken

A recent change to the CodeQL config broken the action. At the time, the results were interpreted as no found issues, rather than there being a problem.

Deployed to a production environment

This project is supposed to be an iterative process. It's important that whenever I reach a milestone, It's up and playable. Even if no one connects to the server.

The server can be hosted wherever I like, but it must be accessible via a sub-domain of moppler.co.uk.

Command Parser

User Story

As a player, I would like to be able to provide instructions (commands) to the game by entering simple strings of text to represent what I want. For example, In order to move north, I would enter the command north.

Acceptance Criteria

• All user inputs are parsed as commands. If a matching command is found, its corresponding action is executed.
• Commands are always a single word, any text that appears after the first word is discarded.
• Commands can be camelCase.
• The implemented command lists the current number of active connections. playerCount.

Player navigation

Players can navigate in pseudo-three-dimensional space using the following commands up, down, north, east, south, west. Rooms have a list of possible exists, a room can have multiple exits but only one of each possible direction for a maximum of six.

Acceptance Criteria

• The look command lists possible exits
• Players can navigate between connected rooms using the navigation commands
• If a player attempts to move in a direction that is not possible, they get a message informing them that "they cannot go that way".
• There are enough rooms to simulate the navigation experience, possibly by creating a set of rooms to represent my own house.

Welcome Screen after establishing a connection

User Story

As a player, After establishing a connection to the server, I would like a welcome screen to appear. This should help me to be confident that the connection is correct and provide some basic information about the game.

Acceptance Criteria

• Immediately after connecting to the game server, the player gets a special welcome message
• The welcome message can contain ascii art
• The message tells the player how many other players are online