Demo 8.1The SimpleMUD Baseline: The Core, Players, and Items

[ LiB ]

Finally! At long last, you have reached (almost!) the end of this chapter. An incredible amount of code was put into everything you've seen so far, so let me tell you something that will make you feel a lot better.

The code for the Demo 8.1 main module is incredibly simple. Seriously. I've designed the rest of the game and the entire framework leading up to it to make the code for actually running the game incredibly simple.

You can find the code for the main module within the Demo08-01.cpp file in the /Demos/ Chapter08/Demo08-01/ directory on the CD.

Here goes nothing:

 using namespace SocketLib; using namespace SimpleMUD; int main() {     try {     ItemDatabase::Load();     PlayerDatabase::Load();     ListeningManager<Telnet, Logon> lm;     ConnectionManager<Telnet, Logon> cm( 128, 60, 65536 );     lm.SetConnectionManager( &cm );     lm.AddPort( 5100 );     Game::GetTimer().Reset();     Game::Running() = true;     while( Game::Running() ) {         lm.Listen();         cm.Manage();         ThreadLib::YieldThread();     }  // end while     }  // end try 

The item and the player databases are loaded, and both a logon manager and a connection manager are created. The two managers are told to use the Logon class as their default handlers, and the connection manager is set up to allow a flood limit of 128 bytes per second, a sending timeout limit of 60 seconds, and a sending buffer limit of 65,536 bytes, or 64 kilobytes.

Once those have been created, the listening manager is told about the connection manager, the listening manager is told to listen on port 5100, the game timer is reset, and the game's running Boolean is set to true .

After that, the loop starts, and it runs while the Game::Running Boolean continues to return true . Inside the loop, the listening manager is told to listen for new connections, the connection manager is told to manage its sending and receiving tasks , and the thread library yields the thread so that the application doesn't suck up your entire CPU power.

That's it for the actual game logic.

Now, the entire thing is enclosed within a try block, so whenever an exception is thrown, you can catch it:

 catch( SocketLib::Exception& e ) {   // catch socket exceptions         ERRORLOG.Log( "Fatal Socket Error: " + e.PrintError() );     }     catch( ThreadLib::Exception& ) {     // catch thread exceptions         ERRORLOG.Log( "Fatal Thread Error" );     }     catch( std::exception& e ) {         // catch standard exceptions         ERRORLOG.Log( "Standard Error: " + std::string( e.what() ) );     }     catch( ... ) {                       // catch other exceptions         ERRORLOG.Log( "Unspecified Error" );     }     SimpleMUD::PlayerDatabase::Save();   // save the player database } 

Four types of exceptions can be thrown: socket, thread, standard, and miscellaneous. Technically, miscellaneous exceptions should never be thrown, but when developing software on top of libraries, you should be prepared for the unexpected. If a simple line of code or two can prevent that, you want to prevent a random crash from wiping out minutes of changes to the database.

Each error type logs a message within the error log, so if the game crashes, you can get an idea of what caused the crash, and then the player database is saved back out to disk.

That's all folks. Seriously.

Now that you've got a very basic "talker" server up and running, which is barely a MUD, it's a good time to briefly discuss the overall design.

What you've got is a basic reactionary server. It doesn't do anything except listen for connections and act on new commands from the existing connections. Figure 8.12 shows an example of what happens when the listening manager is told to listen and a new connection logs on.

Figure 8.12. When a new connection joins the game, the SocketLib library handles almost all the action.

Once a connection is logged on, whenever the connection sends data, the connection manager picks up the data whenever its Manage command is invoked and follows a process somewhat like that shown in Figure 8.13. Again, as you can see from the figure, almost all the messy low-level networking stuff is handled by the SocketLib, so the SimpleMUD only really cares about actual game logic, which is the way things should be. I can't tell you how many MUDs I've seen with the game logic inextricably and directly entwined within the Sockets API, and those always end up as huge messes in the end.

Figure 8.13. Notice the route the process takes as it sends data from a connection to the game and when the server responds.

And now for some screenshots! Once you've got the MUD up and running, just find your favorite Telnet client, and telnet into your IP address on port 5100.

Figure 8.14 shows a screenshot of a sample stats printout, inventory listing, and experience printout.

Figure 8.14. Three status-printing functions.

Figure 8.15 shows a few inventory commands.

Figure 8.15. A person playing around with his inventory of items.

And finally, Figure 8.16 shows some speaking commands.

Figure 8.16. Various user -interaction commands in use.

[ LiB ]