I’m going to piggyback one program onto another today, because it doesn’t really have enough oomph to stand on its own. And in this case, the two titles have their core language in common. Here’s pyro, to start us off.
pyro’s home page says it hopes to be “the first major roguelike game” written entirely in python. Of course, that claim may go back to 2006, and I’m not sure if it made it in under the wire. Nowadays there are quite a few roguelikes that use python2.x and some at python3; I don’t know which ones would deserve the “major” appellation.
pyro does not strike me as particularly innovative in terms of roguelikes, and in some senses seems to be lacking a few important points. If the home page is correct and the game isn’t quite finished then I’m willing to forgive that.
Color use is good, but you must have a terminal of at least 80×25 (not x24) or you’ll get python errors. Character creation is very rudimentary, where selecting a class pins you to a race (or perhaps vice-versa), and classes seem tied to your choice of “god.” There is no chance to tweak ability scores or other statistics, even though the readme files suggest a lot of the game’s mechanics rely on those.
Occasionally there are incomplete screens or placeholders for certain features. pyro’s closing screens mention that there would be a save feature there, at some point. The command key rundown is visible with the question mark key, but there seem to be some points (most glaring is spellcasting) that are missing.
My biggest complaint would just be movement keys, which by default are number pad directions. That means laptop users like me are going to be fiddling with the Fn and NumLk keys a lot. No doubt an enterprising player-stroke-programmer could knuckle down and edit the source files to change those, but I’m not very enterprising, and besides, for what I’ve seen of pyro, it doesn’t really grab me.
Taken as a whole, pyro has the groundwork for a decent python roguelike all in place, and just needs to be updated and embellished. Like so many other programs I see though, it’s fast approaching that 10-year mark where the likelihood of getting that attention is very, very slim.
Now for the second title, as promised: pacman-for-python.
Eugene Antimirov’s Pac-Man derivative is simple and straightforward, and incorporates enough AI to make it a workable clone, even if it does miss big chunks of the original game.
Arrow keys move your atpersand around the screen and clearing the maze of dots (periods) ends the game with a congratulatory message. Touch a ghost and the game ends with a sad announcement.
No power pills though. No multiple lives either. No attract screen or welcome message. And aside from simple direction finding, the ghosts don’t patrol or circle. The maze is determined by the contents of map.dat, which you can edit as a plain text file. So if you want something with more symmetry, you can build it. Or just open the entire field to dots. 😐
I noticed one other thing that pacman-for-python needs to overcome: There’s a blatant discrepancy between the speed of the ghosts and the speed of the player.
Probably just by virtue of mechanics, it’s possible to zip around the maze at a high speed because the key repeat and refresh rates are so much faster for the player than for the ghosts. Ghosts seem to move about once a second; by holding down a direction key your glyph can move three or four times as fast.
Which means even the best AI isn’t going to have much luck in catching you, since you’re five steps away before it gets the chance to make one move. It’s probably a point that can be resolved easily, with a small delay in the player’s movement code.
That’s all for now. I should tie up these games by the end of the month, and we can move back to boring old utilities and system monitors, file catalogs and music clients. Yawn. … 😕