Exposing the BetterMUD to Python | MUD Game Programming (Premier Press Game Development)

[ LiB ]

Now, your Python logic modules, command modules, and condition modules all need to access parts of the BetterMUD. The modules can't do much when they can't access parts of the BetterMUD, so they wouldn't be of much use without this ability.

This is the main reason behind the accessors that I showed you in Chapter 13. The accessor classes are used as an interface between Python and C++.

For example, if you expose accessors to Python, you can do stuff like this:

 import BetterMUD c = BetterMUD.character( 20 ) c.SetName( "Ron" ) c.SetAttribute( "intelligence", 500 )  // look! I'm smart!

Isn't that cool? You're calling C++ code from Python! You're letting your scripts access any information they need to work better.

Game Wrapper

To give you access to the core game module, I've created a wrapper for the Game class that I showed you in Chapter 15. The wrapper itself is stored in the /BetterMUD/accessors/ GameAccessor.h and .cpp files. I'm not going to bother showing you the implementation, since it's just a simple wrapper around the Game class, and you already know what it can do from Chapter 15.

Here, however, is a sample of Python code that would use the class:

 import BetterMUD m = BetterMUD.GameWrap() m.AddActionAbsolute( 0, "announce", 0, 0, 0, 0, "Python Really Rules" )

This code essentially calls the Game module's AddActionAbsolute function, to add an immediate announcement to the game, stating that Python rules, just in case someone forgot that it does.

Taking Another SWIG

All the other wrappers in the game are accessor wrappers. Rather than having my BetterMUD.i SWIG interface file include all the accessor headers, however, I've decided to make your life a little bit more difficult.

I've separated all SWIG- related files into their own directory: /BetterMUD/scripts/python/SWIG.

Within this directory are two files BetterMUD.i, and SWIGHeaders.h. These files exist before you generate any interfaces.

The BetterMUD.i file simply looks like this:

 /* File : BetterMUD.i */ %module BetterMUD %include "std_string.i" /* grab the original header file here */ %include "SWIGHeaders.h"

The SWIGHeaders file, on the other hand, contains mainly code that has been copy-and-pasted from the accessor classes. Here's a sample:

 class character { public:     character( entityid p_id );     ~character();     std::string Name();     entityid ID();     entityid Room();     entityid Region();

I'm going to stop right there, since you've already seen all this stuff before.

The reason I copied and pasted the interfaces into the SWIGHeaders file is that there will be times when you don't want Python accessing some of the features of the accessors. If you don't want Python to access a particular function of an accessor, you need only remove that function from the SWIGHeaders.h file and regenerate it.

Generation Process

To generate the files needed to interface BetterMUD with Python, follow this process:

Open a console window.
Go into /BetterMUD/scripts/python/SWIG.
Type swig -c++ -python BetterMUD.i.
Copy the file BetterMUD_wrap.cxx into this directory: /BetterMUD/scripts/python.
Copy the file BetterMUD.py into the main /BetterMUD directory.

That's almost all you need to do. There's one little quirk, however, which I cover in the next section.

Why the Long Face?

Microsoft's compilers VC6 and VC7.0 don't support the long long datatype (VC7.1 does though), as I showed you in Chapter 4. Instead, you need to use the __int64 type as a replacement.

To prevent confusion, I typedef'ed around it, and created a BasicLib::sint64 type to use instead. Unfortunately, SWIG doesn't know what a BasicLib::sint64 is, and it tries to treat it as a new type that needs its own special Python wrapper. Since it's just a normal 64 bit integer, it doesn't need this.

So, in the SWIGHeaders file, whenever I have a BasicLib::sint64 type, I change it to "long long". For example, this line

 BasicLib::sint64 GetTime();

becomes

 long long GetTime();

Then, SWIG generates the BetterMUD_wrap.cxx file "properly".

You must take one more step, however. When you try compiling the wrapper module in VC6 or 7.0, you'll get compiler errors ( long followed by long is illegal ), so you need to find every place in the BetterMUD_wrap.cxx file that has long long , and replace it with BasicLing::sint64 .

Then you can compile it properly, at last.

[ LiB ]