Document first stages of development

README.md

@@ -6,6 +6,17 @@ Facet MUD Project.
 Documents in this repository utilize the keywords for requirement levels lined
 out in [RFC 2119]: `MUST`, `MUST NOT`, `SHOULD`, `SHOULD NOT`, `MAY`.
 
+## Development Stages
+
+These define the various stages of development for the implementations of the
+Facet MUD project. This will help us measure and advertise the level of support
+offered by them. They also help to ensure feature parity across all
+implementations, as long as these are throughly defined and maintained.
+
+* [Stage 0](./stages/stage0.md) - Skeleton repository
+* [Stage 1](./stages/stage1.md) - Basic chat server
+* Stage 2 - TBD
+
 ## Data Specifications
 
 * [Player save files](./data/players.md)

data/rooms.md

@@ -0,0 +1,21 @@
+# Room Definition Failes
+Room definition files MUST be stored in the [TOML] format and contain the following variables:
+
+| Key | Data type | Optional | Notes |
+| --- | --------- | -------- | ----- |
+| room_id | integer | No | |
+| short_desc | string | No | |
+| long_desc | string | No | |
+| sights | map<string, string> | Yes | |
+| sounds | map<string, string> | Yes | |
+| smells | map<string, string> | Yes | |
+| exits | map<string, integer> | Yes | |
+
+## Variable Description
+room_id: a unique integer used to identify the room within the game system
+short_desc: a short descriptor used as a title in verbose mode and as the description of the room in compact mode.
+log_desc: an indepth description of the room used in verbose mode.
+sights: a list of things that the players can look at, along with their associated descriptions.
+sounds: a list of things that the players can listen to, along with their associated descriptions.
+smells: a list of things that that players can smell, along with their associated descriptions.
+exits: a list of exits from this room by their exit commands, along with the room they are attached to.

features/telnet.md

@@ -0,0 +1,52 @@
+# Telnet
+
+The telnet protocol and a telnet server are at the heart of MUDs, as they are
+how a user communications with the game, and vice versa. As such, as we need
+specific pieces of the protocol implemented in order to make the game function.
+
+A developer implementing the telnet protocol for a particular Facet
+implementation SHOULD use a pre-existing external library. This not only helps
+avoid too much [yak shaving], but abstracts the complexities of the protocol out
+of the game engine. If a pre-existing library is not available, or if none of
+the available options can be modified to suit our purposes, then a developer MAY
+create a new library for the purpose. This library MUST be external to the game
+implementation itself, but MAY be hosted in the FacetMUD organization.
+
+Below are the most essential parts of the protocol and when they MUST be
+implemented in the development of a game engine.
+
+## Stage 1 - Basic Chat Server
+
+For the beginning implementation of a game engine, a developer must include
+support for the following:
+
+* [RFC 854] - Telnet Protocol Specification<br>
+
+  This is the core telnet protocol, and thus the entire protocol MUST be
+  supported in order to build upon for the future stages.
+* [RFC 857] - Telnet Echo Option
+
+  This allows the server to either echo, or stop echoing, input back to the
+  client. This option is key for when a user is entering their password. By
+  using this option, said password is not echoed back to the user when entered.
+
+## References
+
+* [RFC 854] - Telnet Protocol Specification
+* [RFC 855] - Telnet Option Specifications
+* [RFC 856] - Telnet Binary Transmission
+* [RFC 857] - Telnet Echo Option
+* [RFC 858] - Telnet Suppress Go Ahead Option
+* [RFC 859] - Telnet Status Option
+* [RFC 860] - Telnet Timing Mark Option
+* [RFC 861] - Telnet Extended Options: List Option
+
+[RFC 854]: https://datatracker.ietf.org/doc/html/rfc854
+[RFC 855]: https://datatracker.ietf.org/doc/html/rfc855
+[RFC 856]: https://datatracker.ietf.org/doc/html/rfc856
+[RFC 857]: https://datatracker.ietf.org/doc/html/rfc857
+[RFC 858]: https://datatracker.ietf.org/doc/html/rfc858
+[RFC 859]: https://datatracker.ietf.org/doc/html/rfc859
+[RFC 860]: https://datatracker.ietf.org/doc/html/rfc860
+[RFC 861]: https://datatracker.ietf.org/doc/html/rfc861
+[yak shaving]: http://joi.ito.com/weblog/2005/03/05/yak-shaving.html

stages/stage0.md

@@ -0,0 +1,41 @@
+# Stage 0 - Skeleton Repository
+
+This is the very beginning of an implementation, before any actual development
+work happens. The goal here is to get the repository set up with all of the
+basic pieces needed to ensure a successful project.
+
+## Required Files
+
+A stage 0 repository MUST have all of the following files:
+
+* `.editorconfig`
+* `.gitignore` - SHOULD be created from a GitHub template
+* `CODE_OF_CONDUCT.md` - Contributor Covenant >=v1.4
+* `LICENSE` - The MIT license
+* `README.md` - At this stage, no required content in this file
+
+## Optional Files
+
+A stage 0 repository SHOULD have the following files:
+
+* Issue templates
+* Pull request templates
+* `.pre-commit-config.yaml` - Set up pre-commit to run appropriate checks
+  before git commits.
+
+## Required Config
+
+A stage 0 repository MUST have the following configuration set up:
+
+* Branch protection rules for the default branch including at least 1 required
+  reviewer.
+* Merge commits MUST NOT be allowed
+* "Automatically delete head branches" SHOULD be enabled
+
+## Recommended Setup
+
+A stage 0 repository SHOULD use a package manager appropriate for the language,
+when possible. When multiple are available, every effort should be made to find
+the option which will work best for our scenario, and has the largest body of community support available.
+
+Build tools and build configuration are also setup at this stage and a minimalist "hello world" should be created to test the build tools.

stages/stage1.md

@@ -0,0 +1,7 @@
+# Stage 1 - Echo Server
+
+This is first stage of development and acts as a test for whatever networking library is used for this version of the MUD. 
+
+## Required Features
+
+The echo server needs to have a listening socket that can be connected to via either a mud or telnet client. It will then accept connections on said listening socket and wait for a user to connect. It will then create a new connection/player object for that user to send and receive data on. Until the user closes their connection any data sent to the listening socket will be outputed on the listening sockets side as well as being echoed back to the sending connection.

stages/stage2.md

@@ -0,0 +1,44 @@
+# Stage 2 - Basic chat server
+
+This is the second stage of development, standing up a basic chat server. Users
+are able to create accounts, which are saved to disk; log in to existing
+accounts; and send chat messages which are broadcast to all connected users.
+
+## Required Features
+
+The following set of features MUST be implemented fully in order for the Facet
+implementation to be considered complete for Stage 1.
+
+### Required Commands
+
+Other than what is required to log into an account the only other input that needs to be handled to meet this Stage are these commands.
+
+* `say`or `chat` \<message to be sent> - sends a message to all other connected accounts as well as the sender. Formats as follows:
+
+> self: You say/chat: <message>
+
+> others: self.name says/chats: <message>
+
+* `quit` - quits the mud causing the player's account to be saved to disk, all remaining output to be sent be written to the player's connection, and then the closing of the player's connection. Optionally 
+
+### Telnet Server
+
+The implementation MUST provide a way to start a telnet server which remains
+open at a specified port number. This telnet server MUST support the parts of
+the telnet protocol specified in [Telnet - Stage 1].
+
+### Login
+
+On login a user should be greated with some kind of welcome message, be it an ascii banner or just a simple line of text. They will then be asked if they would like to log into an exisiting account or a make a new account. 
+
+If they want to log into an existing account, they will be asked for the account username and then the account password. The MUD will then try to find an account by that username. If the account does not exist the player will be informed that the password did not match and be disconnected. Otherwise they will be logged into the MUD.
+
+### Account Creation
+
+If the previously mentioned user wanted to make a new account, they will be asked what username they would like to use, this username will be checked against existing accounts. If the name is already in use the player will be informed that the name is not available and please try another. If after another two tries they have still not been able to secure an unused account username they will receive a message of condolence and be disconnected. 
+
+They will then be asked to confirm if this username is the one they want and if not they will start over the previous process of choosing a username. 
+
+Otherwise they will then be asked to choose a password that is at least 8-12 characters in length and then asked to confirm that password. If the confirmation matches, an account will be made using that username and password combination and logged into the MUD just as if they already had an account and succesfully logged in. Otherwise they will receive a condolence message and be disconnected.
+
+[Telnet - Stage 1]: ../features/telnet.md