[Python-Dev] RE: Python and Temple of Elemental Evil (original) (raw)

Delaney, Timothy C (Timothy) tdelaney at avaya.com
Thu Dec 11 18:13:53 EST 2003

From: Steve Moret [mailto:smoret at troikagames.com]

Hey Tim,

Hi Steve. I held off pestering you since you said you were going to do further work on ToEE over the Christmas break ;) But since you've obviously got so much time, there's that slight matter of an article about how Python was used in ToEE ... :)

I'm forwarding this to python-dev as it deals with potential modifications to the python code base (including offer of a patch :) Guido has the final say anyway ...

I'll also put some comments inline - it could be that the documentation needs to be improved rather than any code changes. In particular, I think the first two cases are simply resolved, but possibly not obvious.

BTW, I've really enjoyed ToEE (I'm currently running a 3-character party ;) but I do agree that as a game it suffered from being too close to the module (something Huy - I think - said in the wrap-up on IGN). It didn't have the Troika goodness from Fallout or Arcanum ... It's a pity that game publishers don't seem to realise that the majority of people who buy games are adults ...

Steve Moret here, from Troika Games, now that I've had a few minutes to step away from work (after Temple of Elemental Evil shipped) I've been itching to give back some of the work we did on Python to the community.

One major thing (that us game developers use a lot) that the Python/C interface is missing (or that I just couldn't find) is a way of replacing Python's IO with a set that will work for the game (or other custom project). Two things that I've now done twice to python (and need to do a third time in a more generic sense so I can release it to the community, unless its already in there and I just don't know how to do it) is 1) replacing Python's IO (specifically stdout/stderr and stdin) so that it can read/write to the game's libraries (traditionally this goes to a console or debug file),

Probably the easiest way to do this is to simply replace sys.stdin, etc. For example:

import sys

def main():
    pass

if __name__ = '__main__':

    try:
        ferr = file(stderr_file, 'w')

        try:
            fout = file(stdout_file, 'w')

            try:
                fin = file(stdin_file, 'r')

                try:
                    sys.stdin, sys.stdout, sys.stderr = fin, fout, ferr
                    main()
                finally:
                    fin.close()

            finally:
                fout.close()

        finally:
            ferr.close()
    
    finally:
        sys.stdin, sys.stdout, sys.stderr = sys.__stdin__, sys.__stdout__, sys.__stderr__

(you'll note that I've done stderr as the outermost so that errors with the others will go to the error file).

stdin, stdout, stderr are in the Python 2.3 .chm index and the documentation it links to is (IMO) sufficient. Would you have been affected by the fact that changing these bindings does not affect stdin, etc as used by os.system, popen, etc?

and 2) replacing Python's fopen/stat/fread calls that do reading of .py and .pyc files (so that they can be placed in a game's .dat file or other proprietary filesystem).

The normal way to do this is with an import hook. This has been greatly improved in Python 2.3 (PEP 302).

A third step can be taken (which replaces the Python fileobject's calls to fopen/etc with the game ones, but I think it's a better idea for the developer to write a python module that encapsulates this on their own anyway.

Not quite sure what you mean here. What are the semantics of the file object calls that are different to what you needed?

Traditionally we (here at Troika) have done all of the above with a structure/array of function pointers and initialize it to the defaults. Just wanted to know if I were to provide a diff/patch would you guys want to include it. Also if I do, what version should I make the patch for, 2.3.2 or CVS or? Otherwise I'll just try to get Troika to host the patch on our website incase other developers want to use it.

A patch is definitely welcome, even if not accepted. In general, patches should be made against the latest development branch (2.4) and if appropriate backported to the maintenance branch (2.3.3). However, since your proposals sound like new functionality, they would not be appropriate for a 2.3.x release.

Cheers.

Tim Delaney

More information about the Python-Dev mailing list