Thursday, November 11, 2004

Steam-driven gaming

[It's a shame Blogger doesn't do categories. Pretend this entry is in a "Gaming" category, and that you're not seeing it if you're just interested in the Python side of the 'Pipes. In any event, this is reposted from a backup I had from before I move Apipes to blogspot.]

I have a habit of coming up with an idea, writing it down, forgetting about it, and then reading that someone else has had the same idea and developed it into something really cool. It's happened again.

Early this year, I was inspired (by reading The Victorian Internet, The Guns of the South, and The CSS Hunley in quick succession, while at the same time re-playing MechCommander 2), to create a game or story setting for a "steampunk", Victorian- or slightly post-Victorian alternate history.

I started with steam-driven, clockwork tanks (called "armored coaches" or "steamcoaches") and U-boats, but it grew into steam-driven mechs, with Tesla and Edison as scientific advisors on opposite sides of a just-post-Victorian war.

Two possible scenarios for that war developed: a corporate war or a second US Civil war. The corp war (aka "The Steam Wars", or TSW) occured around 1915 between a united Westinghouse/Union Pacific conglomerate (with Edison as the technical advisor) and a TELM/Southern Railway/Central Pacific conglomerate jointly headed by Tesla himself and the head of the Southern Pacific railroad. The dates had to be fudged a bit, as I had a hard time nailing down which of the SP's executives would have had enough guts to pull it off--maybe Stanford.

The other option was to have the South win succession (via British and/or French assistance), then make a "land grab" for the Western states with the help of Tesla and the Western Railroads around 1918-ish (again, I cheated by making TELM a successful Colorado
company, and making the post-civil war railroad situation in the South less dismal that it was historically), thus causing The Second US Civil War, aka T2CW or, in the words of one rabid Northern journalist of the time, "The War of Southern Aggression".

In both cases, I had to remove the assassination of the Archduke of Austria-Hungary from the record books. I wanted the European situation to be simmering but not erupting, so as to free up US energies for internal conflict. I toyed with the idea of making the corporate war occur before 1914, and having its results feed into World War I, but I don't really know enough about European-American politics of that time to stitch it together, and the dates had to be pushed around enough as it was.

The historical (i.e., real) webs of international politics were really interesting but somewhat hard to get a handle on (particularly in the second case), outdone only by the web of inter-corporate controls, holdings, rivalries, etc. between the railroads during the same time. It made for some fun research, including a surprisingly large amount of data and bibliographic pointers from Wikipedia.

Anyway, I got pretty far with it in notes, even writing some vignettes, but it Mr. Blamire has gone much further. He's gone a completely different route, though:
  • In my milieu, Canada was a tangential player in the T2CW setting and unmentioned in the TSW setting; it looks like a Prussian invasion of Canada (?!) is his inciting incident.
  • Blamire's "mechs" are anthropomorphic. Interesting, but I haven't seen much to make me think that a late 19th-century inventor would take that direction, other than a rather fanciful web page I ran across while researching. Mine were of a more antlike design.
  • Blamire's "mechs" are the dominant force during his time period. Mine are just being designed and prototyped during the story arc (and thus form a major part of the story). The real combat is happening between "steamcoaches", horse cavalry (losing badly to the former), and infantry, with a few brave souls experimenting with airships.
  • Airplanes aren't a real factor in either of my settings, because Curtiss is involved in mech design for Edison. The Wrights were technically successful but haven't garnered the amount of attention they did in the Real World--from my research, it appears that much of their fame grew out of the Curtiss rivalry.
Aren't alternate histories fun?

Thursday, August 26, 2004

Can you fly that thing? Not yet...

[republished 1 Dec 2004 from pycs.net]

Every once in a while I notice something that reminds me of a scene from a movie. Generally, if it's a movie that has made me think a bit or consider things in a new light (Fight Club, The Matrix, and Pulp Fiction are a few), it means there's something worth chewing on in the situation.

I'm no Matrix fanboy, but I had an experience that put me in mind of one scene. Neo asks Trinity if she can fly a helicopter. She answers, "not yet," calls up her "operator", and he transfer the appropriate skills to her virtual persona.

Today I wanted to check out something using the ctypes module, so I popped open an interpreter window and typed import ctypes. No dice--I didn't have it installed on my work machine. One quick download and install later, I uparrow+entered in the same interpreter (no restart here!),and had ctypes available. Not bad.

But this could get better. PyPI is gaining traction--it's not CPAN yet, but it seems to be turning a corner. Thinking in terms of yum and apt-get, what would be very cool is to turn this:

>>> import blahdb
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named blahdb
[switch to web browser, hit Google, find the right page, find the download
for my version of Python, download, find installer, run installer,
switch back to console]
>>> import blahdb
>>>

into this:

>>> import blahdb
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named blahdb
>>> install(blahdb)
PyPI: found blahdb (Library for accessing Blah databases)
PyPI: version 1.6 for Python 2.3
PyPI: <blah_author@python.org>: signature OK
PyPI: installed
>>> import blahdb
>>>

or even this:

>>> from __future___ import magic_imports
>>> import blahdb
>>>

Monday, August 16, 2004

The Contractual Obligation Post

It appears that, as it has "Python" in the tagline, this blog is legally required to comment on the current decorator controversy in the Python community.

I think Hans Nowak has the best and most thorough explanation of what the new decorator does (at least in its current implementation), and exploration of how you can use it in interesting ways. Certainly, it's been the explanation that fits my brain best.

Everything I've seen so far, though, has been "this is how it works", plus some "this is cool because it makes classmethod less of a special case". And it lets you extend the language, which is very good, in that Python-as-a-larval-Lisp way.

The next obvious question to me is, which interesting applications of decorators are going to be provided in the standard library? There are a number of "good ideas" (function attributes, synchronized, docstring replacement, PyProtocols implementation, magical hook insertion like atexit and sys.settrace, etc.)

My biggest concern: right now, everyone is caught up in the syntax for the feature, and to a lesser extent, the implementation corner cases. I haven't really seen anyone (and by "anyone" I mean the BDFL) talking about what decorators will exist as part of the standard Python distribution.

I fear that decorators will become Python's equivalent of the "everyone's own favorite homegrown string library" phenomenon we saw in the early days of C++. Everyone will have their own favorite and flawed implementation of @synchronized.