If you aren’t careful (and even sometime when you are) realtime games written in Python sometimes hit speed problems and require some profiling to bring them to a playable speed. Typically, I would use the Python standard library’s “profile” module to find “hot” functions which are stealing all the CPU cycles. Today I discovered another way.

I’ve just been researching Interactive Fiction (aka text adventure) systems written in Python. I’ve always wanted to make an interactive fiction, but never quite got around to it. I even started learning the Inform language a few years back, which can be compiled to run on the Infocom Z-machine interpreters (like Frotz, among many others). Of course, I’d rather write it in Python since there’s more chance I could add some custom features to the game.

As tempting as is it to reinvent the wheel and write my own IF interpretor in Python, I figured it was likely that others had already done this grunt work for me. After a bit of Googling, so far Python Universe Builder (PUB) looks like the best option. Hopefully this will save me from the grue.

Shoodar is a little game I’ve been writing, mostly to learn Rabbyt (although these things tend to grow beyond learning exercises ….. :P). Essentially it’s just a silly vertical shooter, but there is an Ikaruga-inpired twist. It’s in early stages of development, but I’ve put a playable version up in the Games section

No nice installers and stuff yet, but the README in the archive gives some instructions for getting it running under Debain flavours of Linux.

The 400 Project is an expanding list of “400 game design rules“. I suspect the project may have stalled at rule #112 .. still, there’s some juicy stuff in there. I also suspect that for at least half these ‘rules’ there is at least one professional developer somewhere who would say “No ! Never Do That !” or “That’s been overused way too much” … such is usually the case with discussion on game design, and defining absolutes like lists of ‘rules’.

There’s a nice little writeup on Gamasutra describing how the crazy gravity in Super Mario Galaxy was implemented, including demo sourcecode. It’s not ‘real’ physics (no surprises there ….). Essentially, Mario’s orientation is corrected to smoothly align with the surface normal of the closest ‘ground’ polygon.

This is the first in a new series of “Games Demystified” articles on Gamasutra … I’m looking forward to more of these.

It also begins to explain the annoying little bug in one of the boss battles with Bowser, where he can float off and never return:

The final component of the updatePhysics() function checks the planetoidClass list to see if we’re actually closer to some other planetoid. If we are then we switch planetoids so the next time updatePhysics() is called we’ll check with this new planetoid to calculate gravity.

Presumably in Super Mario Galaxy, the planetoid gravity has some sort of cutoff radius. If there is no other planetoid to ‘fall’ to, things just float away (or maybe into a Black Hole) … this is what happens to Bowser if he just happens to launch off the small platform rather than the planetoid surface – he leaves the cutoff radius and just floats away, leaving Mario unable to complete the level. I guess this is the only way Bowser can really win :)