I was a little premature on networking though. The simulator process doesn’t need to talk to the process with the 3D rendering GUI (we’ll call that the player for simplicity) from to actually do a simulation, and there is yet another process that will actually be starting both of those (we’ll call that the client), so putting in communication between the simulator and the player without the client would just be throw away work. Anyway, the simulator needs to be able to create a file that the player can use to render the course of the simulation from the perspective of one of the entities in the simulation. What the player shows is like watching a demo for a first person shooter, or if you saw the Robin William’s movie Final Cut it’s like how the Zoe implant recorded everything in a person’s life from their perspective.

At this point I have simple simulator coded up that runs a simulation on a hard coded input of two equally matched combatants duking it out (they tie every time). So the next step is to have the simulator write out one of the combatants perspective to to a file and then have the player playback the contents of the file like a movie.

Thus it is time to delve into Python object serialization and deserialization. In looking at the Twisted docs it has some support for this. I’ve also encountered the term “pickling” regarding Python object serialization, but I don’t yet know if that is part of standard Python or yet another library. Another way to go is to use SQLAlchemy with a SQLite database. SQLite runs in process and now is included standard with Python (at least Win32 installs of Python) so there is no database server product to be installed and no seperate SQL server that has to be configured and the database is contained in just one file, so its nice and simple compared to big iron databases. SQLAlchemy can be used to get Python object mapped into a database, but it also allows for a lot of more control over how this happens if you need unlike most other Object Relation Mappers.

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.

I figured I’d have a look at the Python bindings for OpenGL, PyOpenGL quick to see how they compared. First off there weren’t any samples included with just the basic download, but that’s now big deal. After downloading the samples I found that none of the would run without going and downloading an additional DLL and some additional Python libraries. Still not a big deal and once they were running I didn’t observe any of them disappearing before I closed them. I did run into a few that were using an fairly old library for which there is no pre-built Win32 binary. Didn’t feel like dealing with that, but the code is still useful.

One piece of data that I discovered while working with PyOpenGL and OpenGL was that modern graphics cards now support geometry instancing. As this seems highly likely to beneficial to my games, I decided that whatever 3D rendering library I was going to write code against first needed to support instancing. Although DirectX 9.0c does support instancing DirectPython does not (well it’s the ability to call through the COM methods directly, but there are other ways to that as well, and I believe it would more productive to just write the code in C++ then in Python in that case), so that’s out (I may need to write something against DirectX in C++ in the future and then make Python bindings for that, but that’s basically an optimization that can wait until later). I also checked OGRE and it does not have support for instancing, so that is now definitively out as well. I ran across another open source rendering engine called Irrlicht that all has Python bindings and investigated it enough to determine that is also does not support instancing. Next I checked the PyOpenGL bindings for OpenGL extensions and found that the instancing extension (EXT_draw_instanced) does have bindings.

At present I’m also more inclined to go with OpenGL then DirectX from the standpoint of future proofing. All versions of DirectX up through 9.0c have been available for developers to freely redistribute with their games; however, DX10+ is currently only available on Vista and Microsoft has indicated that it has no intention of making it available separately from Vista. Unless Microsoft changes its tune in the future, this means XP users–that is to say most users–are running on an OS for which there will be no version of DirectX beyond 9.0c made available to take advantage of the new capabilities of graphics cards. On the other hand graphics cards manufactures (NVidia in particular seems to be really committed to its OpenGL drivers) make available their newest hardware capabilities via OpenGL extensions. These hardware specific extensions frequently become official ARB OpenGL extensions, and the ARB extensions becomes frequently become part of the next rev of the OpenGL specification. While dealing with hardware specific extensions does suck on a number of levels, its nice to at least have the option to use more advanced features, vs. being forever frozen to what DirectX 9.0c supports.

So at this point if PyOpenGL doesn’t work, screw Python I’m going home to C++ at least the rendering subsystem. Since wxWidgets is written in C++ and I’m just calling through to it via wxPython, the language switch won’t affect any of my current API or library choices.

So first things first I’ve got two monitors so I want to be able to do full screen rendering to both monitors at the same time (and more for folks with more monitors). After a screwing around without for a while I confirmed that out OGRE doesn’t support that yet. Okay, so maybe one monitor gets a full screen window and the other gets regular window that is maximized. Nope, when the focus is switched from the full screen window to the regular window the full screen window minimizes itself. Turns out two maximized regular windows was the best I could do with OGRE at present, but that was okay for my initial plans and I found comments by the OGRE devs that the multi-monintor full screen support was being worked on.

So now that I’ve got two windows (well three actually; I’ve always found it better test with a minimum of three things if you need to support an arbitrary number of things) up capable of rendering 3D scenes, I figure it’s time for a GUI in those windows. Even if I decided to be lame and go purely keyboard driven I’d still need to be able to put up to some text on the screen and if I’m going to both with that I figure may as well have some mouse support as well, since this is common in modern games so not having it would be really lame. I looked into the 4 GUI libraries that Python-OGRE has bindings for and was able to rule out 2 in fairly short order. The next two I spent some time playing around with. One was still only of alpha quality and it just wasn’t ready for use yet. The other was fairly mature and stable after more screwing around I was able to confirm it only supported putting a GUI into 1 3D viewport (a window can have multiple viewports). More importantly the stock GUI widgets it offered didn’t supply everything I’d need for a GUI for doing unit/character design, so no only would it limit me to a single viewport (and thus single window) I’d still have go write some complex GUI widgets.

So I said screw it. I’ll use a regular a regular Windows GUI and simply host some 3D rendering windows in the regular GUI. I new there was a mature library called wxWidgets that was a cross platform (it works on Max and *nix as well as Windows) GUI/windowing library that had Python bindings in the form of wxPython.

So I got that going without much difficulty and figured it was time to get something 3D rendering in my 3D window. I’m planning to go with programmatically generated visuals as I’m not skilled as a texture artist or a 3D modeler so I wanted to get a sphere up on the screen. Before trying to generate a mesh for a geodesic sphere I wanted to display a particle at each vertex on the geodesic sphere to make sure I had the algorithm correct. A particle is a (usually) small square that is perpendicular to the direction of the camera (i.e. it always faces the camera however the camera moves) and I knew OGRE had a particle system so I tried to determine how to get one particle onto the screen and I really got a dose of how static data driven OGRE is. OGRE can load a number of different kinds of files and turn them into visuals on the screen with just a little code from you to specify where this thing will be or what animation it is currently running through. That’s great if you have a bunch of artists producing loads of content; however, if your content is produced dynamically on the fly this isn’t useful. That would be a problem in and of itself, except that the OGRE tutorials all use static content in files, and the OGRE API docs are pretty light. I ended having to download the OGRE source code in order to look through it to try to figure out the steps for just getting a damn particle on the screen. I got one up eventually but I ran into a problem where the Python bindings had an error in them so one particular method wasn’t callable. I found another method I could call that would in turn call that one; however, calling it at that time caused other problems.

On top of that while I was looking through the particle system render code I had noticed that it was fairly inefficient. Particles are supposed to be really light weight. OGRE is very and extensible so I could write my own my particle system, but I had already determined I would need to write my own scene manager as well. Since I wouldn’t be taking advantage of OGRE’s static data driven aspects (including all of the tools for creating this data), so now I have began to question if OGRE was really what I should be using. I could just use it’s lower level classes that abstract over OpenGL and DirectX but figuring out how to do that is going to mean a lot of time looking at the code so I’d probably need to get setup to build OGRE and Python-OGRE so I’d have binaries I could debug to aid in figuring out how the code all fits together.

Having support for both OpenGL and DirectX isn’t critical. Numerous games only support one or the other. Another option is to just write to OpenGL or DirectX directly. There are Python bindings for both. There are also a number of Python libraries or libraries with Python bindings that work on top of PyOpenGL. I’ve just downloaded a number of these libraries so I can spend some time evaluating them.