Rev. Jon Harford <dubious at jonjh.freeserve.co.uk> wrote: > How suitable would Python be for games that move faster than Solitaire? I've done some thinking about this, though I have little practical experience. It depends on what kind of game you're talking about, to start with. A whole lot depends on that. Python probably isn't fast enough to do a vast amount of 3d calculations, but it's fast enough to *drive* these calculations. This is the general principle -- Python can still perform quite well as a higher level controlling system (which can include a lot -- GUI, loading/saving, scripting of in-game objects and events, etc), even when it's not fast enough to do low level graphics manipulation. You use a C or C++ library for that, but you can wrap those with Python. For object scripting, there are some interesting developments. Python does not have 'simulated threads' by default. These are non-OS threads where the Python interpreter itself does the switching, first executing for instance 100 bytecodes of 1 thread, then 100 of another, and so on. But, Will Ware has released MicroThreads which does accomplish this. So look into this if you're interested in driving a lot of objects in your game with Python scripts. Microthreads seem to be better suited for this purpose than the usual threads, which usually don't assume that large an amount of threads. Microthreads can be found at: http://world.std.com/~wware/uthread.html There was talk about integrating MicroThreads into Christian Tismer's 'stackless Python', and there is also talk about integrating *that* with Python proper, but that's of course a lot of assumptions. :) So I'd recommend Python for game scripting, and for the code that structures and drives lower level speedy code. For the lower level code Python isn't very suited though. Regards, Martijn
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4