[Python-Dev] RE: Python and Temple of Elemental Evil

[Delaney, Timothy C (Timothy)]

> 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