[ LiB ]

I'll be explaining the specifics of implementing Python scripts in Chapters 17 and 18. That doesn't prevent me, however, from showing you the basic interfaces that Python objects use throughout the game.

The basic concept behind any piece of removable logic in the BetterMUD is the script . A script is, simply, any object that holds logic (computer code) and can hold internal data.

The basic function of generic script objects is to load and save themselves to disk, however, so that's just what the Script interface defines:

 class Script { public:     virtual void Load( std::istream& p_stream );     virtual void Save( std::ostream& p_stream );     virtual std::string Name() = 0;     virtual ~Script() {}; };  // end class Script 

It should be noted that the Load and Save functions aren't pure virtual , but rather standard virtual . The Script class defines default implementations of these functions.


The Script class has a virtual destructor, which is very important to have due to a little-known quirk in C++. Imagine having a class that returns new Script* objects (such as a script database/factory), and relies on you to delete them. When you delete the script and the language has no virtual destructor, only the destructor of the Script object that is called. If you have a child class that inherited from the Script class, and it needs to delete data in its destructor that Script s don't know about, you've just given yourself a memory leak, because that child class never properly deletes what it needs to delete. It's enough to make you crazy some times, isn't it? Supposedly the next standard of C++ will support automatic virtual destruction, but that may be a few years off. We'll see.

Since all script objects are capable of storing variable amounts of miscellaneous data, it makes sense that the scripts need to know how to write this data to disk. For example, you might give a special command to a player that can be executed only once a week. Obviously, this command's script object needs to store the last time the command was invoked, so that the next time a player tries to use it, it can check, and say, "Hey, it hasn't been a week yet!" In addition, if you had to shut down the MUD and then reload it without saving the data in the scripts, a player could use the command again, even if it hadn't been a week.

Or worse yet, imagine what would happen if a player who was on a week-long quest was just hours away from snapping up the Holy Grail, and all his quest data was wiped out because the script did not save its data to disk. D'oh!

So scripts must save their data to disk. To do so, they use this format:

 scriptname [DATA] ... data goes here ... [/DATA] 

Even if there is no data, the [DATA] and [/DATA] tags must be written to disk. The default implementation of the load and save functions does this for you automatically.

[ LiB ]

MUD Game Programming
MUD Game Programming (Premier Press Game Development)
ISBN: 1592000908
EAN: 2147483647
Year: 2003
Pages: 147
Authors: Ron Penton

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: