Over the last week and half wxPython and PyOpenGL haven’t made me wish I was working in C++ except in one instance today where call through wxPython into wxWidgets wasn’t returning so long as the window was being moved or resized but it isn’t really that big of a deal since windows don’t actually get moved and resized a lot.
At this point I have enough of a GUI in place to be able to render what I need for the first, minimalist stage of the road map for my game development, so it’s time to stop screwing around with 3D rendering (it suckers you in with nearly endless tweakability) and get on to interprocess communication and then finally the actual game simulator. The simulator has to wait on interprocess communication as it will be running in a different process from the GUI.
Python’s interpreter has a single process level lock that prevents two threads from executing python code at the same time, so in order to take advantage of today’s multi-core processors in Python it is necessary to distribute an application across multiple processes. While multi-processing is generally less efficient then multi-threading, the distribution has benefits of its own. One is that it isn’t that big of a step from running multiple processes on one machine to running multiple processes on different machines and it won’t cost you that much to just build support for that from beginning. Besides the obvious benefit of such distribution allowing multiple players on different computers to play the same game together, such distribution can also allow a single player to utilize multiple computers to be able to simulate a larger and/or more complex (such as giving advanced AI its own machine to run on) game world.
While looking for other Python related things I’ve read a number of references to a Python networking library called Twisted so I’m give it ago for my networking code.
Josh Heitzman on Codecrafting 