Players logging on and issuing commands is the life blood of any mud. In this chapter, WindowMud is enhanced to allow players to log on and chat with each other. In the process of adding the chat command, the foundation is laid upon which all command processing is built.
The Player class tracks player specific information. For the chat command, only Name and Password are needed. The Sex variable will be needed for any messages sent to other players which require a pronoun like his or her, so to complete the logon code, a prompt for sex is included. Most of the new code is in the Communication class in the Logon functions and the Command functions. The Dnode class has some new PlayerState variables used in the logon process. The Log class is modified to use Utility::Blowup to terminate.
The Player class uses player files to save and retrieve player information that is preserved across game restarts. The player files are stored in \WindowMud\Running\Players as plain text files which are named playername.txt
A call to LogonGreeting has been added just before the "Create a new character Y-N?" prompt. LogonGreeting reads text file \WindowMud\Library\Greeting.txt and appends the contents to PlayerOut.
SockRecv has a new block of code that detects when a player hits enter, logs the input, and calls CommandParse. Logging player input enhances the mud administrator's ability to check the logs should questions arise concerning player behavior and interaction. If "Admin Name Goes Here" is changed to a player's name (intended to be the mud admin), then their commands are not logged. Of course, with slight modification, mud admins could be tracked instead of players.
The Logon functions use the PlayerState variables track a player's progress from the initial SendBanner state to the Playing state. While the player is in the LoggingOn state, any input is handled via DoLogon. When the player has negotiate the logon prompts, PlayerStateLoggingOn is set to false and PlayerStatePlaying is set to true.
The logon process is responsible for validating the name chosen by the player. IsNameValid in the player class reads a text file of valid names and returns true if the name is valid. IsNameValid can be easily changed to return false if the name is found in the valid names file, thereby changing its behavior from accepting valid names to rejecting invalid names. If IsNameValid is changed to check for invalid names, then partial name checking should also be added, so that if a four letter word or the like occurs anywhere in the name, the name is rejected. The valid names file is located at \WindowMud\Library\ValidNames.txtCommandLoadArray loads a CStringArray called ValidCmds from \WindowMud\Library\ValidCommands.txt. ValidCmds is used in CommandCheck to validate each command. For now there is only one command, Chat, so this is overkill at this point, but it lays the groundwork for enhancements in the next chapter.
WindowMud's command structure is <commnad> <parameters> <return or newline>. It is possible for PlayerInp to contain multiple commands, so CommandParse parses the first command into CmdStr leaving any other commands in PlayerInp for processing the next time that connection is serviced by SockRecv. CmdStr is further parsed to get the MudCmd which is used to determine which Do function to call. For now the only Do function is DoChat.
DoChat creates a message for the player issuing the chat command and a separate message for all other players and then calls SendToAll which adds the message to each player's PlayerOut variable. To accomplish this, SendToAll must looping through all the connections. But SockRecv, when it initiates this chain of events, is also looping through all the connections. So, when SendToAll is done, it calls RepositionDnodeCursor which causes pDnodeCursor to again point to the connection being processed by SockRecv.
PlayerName and PlayerPassword hold the player's name and password while they are navigating the logon prompts. Once a player has successfully logged on, pPlayer is used to reference all player variables. There are a number of new PlayerState variables that track a player's progress through the logon prompts. The PlayerStateWait variables control progression from one prompt to the next via Communication::DoLogon. For example, Communication::SockRecv sets PlayerStateSendBanner = false, PlayerStateLoggingOn = true, and PlayerStateWaitNewCharacter = true. PlayerStateLoggingOn causes Communication::Logon to be called to process any player input. PlayerStateWaitNewCharacter is set to false by Communication::Logon and Communication::LogonWaitNewCharacter is called. If the player does not enter a 'y' or an 'n', then PlayerStateWaitNewCharacter is set back to to true causing the prompt to be repeated until the player enters either a 'y' or an 'n' and PlayerStateWaitName is set to true which activates the next prompt sequence.
\WindowMud \WindowMud\Debug \WindowMud\Library \WindowMud\res \WindowMud\Running \WindowMud\Running\Control \WindowMud\Running\Log \WindowMud\Running\Players \WindowMud\Source \WindowMud\Source\Server \WindowMud\Source\WinApp
In this chapter, WindowMud was enhanced to allow Players to logon and chat with each other.
After downloading and unzipping the project, ensure that it is in the C:\WindowMud directory or change the HomeDir variable assignment to match the chosen directory.
Download the WindowMud project